Start a new topic

Control version System Workflow

 1. Get latest version on the working branch:

a. We need to get the latest version before to start a new ticket for Dev branch to avoid conflicts when we push the changes on the server.

b. If your ticket takes more than a day, its recommended to get the latest version in case someone else worked on the same “files” than you are still working.

2. Work on the working branch:

a. Do the necessary changes to complete the ticket

b. Use the available tools to create clean, understandable and efficient code. (E.g.: Resharper)

3. Committing code on Dev Branch:

a. Only commit your changes when you are totally clear and sure that your code its completely done and fully test on your local environment.

b. Prevent to create excessive revisions to make an effective merge on QA Branch and in case some code breaks the application, will be easier to revert it.

c. Check the files that you are committing to make sure that all the files correspond with the changes that you are working on, it means that there’s no missing files, extra files or extra code.

d. Use the correct nomenclature if you are going to commit sql files

  i.  See references on Nomenclature for SQL files.docx

e. Commit message standard:

  i.  Ticket type + Ticket NumberTicket description – Description of the changes that were applied.

  ii.  Example: Task #6042 - MyRegConfig: Add Ability to sort by VAR – Updating the current logic to add new sort option in MyRegConfig Page.

f. Make sure that the code that you are committing it’s the one that corresponded with the ticket that you are working on (don’t mix code from another ticket)

g. Model changes associated with an Redmine should be in a separate revision since that is a heavier, more complex object and this is something that quite often needs special attention.

4. Create a new build on Dev environment using cruise control Web UI

a. Wait until the build its created successfully

b. Check logs if a failure occurred

  i.  Check the different sections in the log file to detect if there’s an issue (DB, code, or network related)

5. Assigned for a code review and get your code review revision.

a. Apply changes in case are necessary and reassign back for another code review

 

 

6. Merging code on QA Branch

a. Get latest version of QA Branch before merge any code

b. Keep you QA local branch always clean without any change (green check)

c. Select all and only the revisions that belongs to the ticket that you are working on

d. While merging, use only compare whitespaces option

e. Resolve any conflict manually and make sure to not remove working code and you are adding the right code that you worked.

f. Report any conflict into the ticket or any documentation source.

g. Start up the application locally to make sure the code its fully working with no issues

7. Committing changes on QA branch

a. Use the same description that SVN creates when it does the merge.

8. Create a new build on QA environment using cruise control Web UI

a. Wait until the build its created successfully

b. Check logs if a failure occurred

  i.  Check the different sections in the log file to detect if there’s an issue (DB, code, or network related)

9. Assign ticket to the reviewer for testing.

Login or Signup to post a comment