Thursday, March 14, 2013

Git working process with QA

Lately we switched our version control (GIT) workflow to better control our QA, and each phase of it, in our regular development / code-deployment process.


  1. Version control system (GIT).
  2. Task management (redmine).
  3. Remote server assignments (Jenkins).

Task Types:

  1. Hotfix - Short term task (no more than a few hours), with a single developer.
  2. Release - Long term task (usually a few tasks with the same theme), with multi developers. Or just one of the two.


  1. Master branch - is the stable branch, which acts as feeder to all of the developers’ feature branches. Updated only by the QA guy with approved production tags. Master is updated with the current production tag.
  2. Feature branches for release-type tasks - remote gets updated.
  3. Feature branches for hot fixes - remote does not get updated, local branch only.


  1. Local - developers’ local environments.
  2. Development (multi) - for pre QA testing and sharing. Updated using GIT tags.
  3. Stage/QA (multi) - updated only by QA with GIT tags.
  4. Production - updated only by QA  with approved GIT tags.

Developer rules:

  1. All work is done in feature branches.
  2. Never update Master branch.
  3. Master branch will be updated only by QA from approved GIT tag.
  4. Feature branches are updated (merge) frequently from Master branch.
  5. Done tasks will be committed and tagged, e.g. q-1.1, and pushed to remote.
  6. Feature branch gets deleted once it’s no longer needed.

QA Rules:

  1. Tags are tested one at a time. A new tag gets tested after the previous one has finished the cycle, and has been updated on Master branch:
  2. The new tag is checked out and merged-to from Master (with the latest approved features in it).
  3. Stage environments are updated with testing tag, e.g. r-1.1, which contains Master branch (equal to prod) with the new feature.
  4. Approved tags are re-tagged, e.g. p-1.1, for production update.
  5. Approved tags are merged into Master, for feeding all developers and next tags.


for developers

    1. Create a new branch updated and equal to Master.
    2. If it’s a release task, push the branch to remote.
    3. Perform the task, in the best way you can, and commit.
    4. Merge from Master (git pull to update local Master from remote Master, and then git merge to your branch from local master).
    5. Tag the current state for QA testing, e.g. q-1.1.
    6. Push the tag to remote and assign the task as QA in the issue tracking system.

for QA

    1. Fetch the tag and checkout to be on it.
    2. Merge from Master branch, to get the latest approved features and updates.
    3. Create a new tag for a stage test, e.g. r-1.1, which contains Master branch (equal to prod) with the new feature.
    4. For approved tags, re-tag for production, e.g. p-1.1.
    5. Update production with the new tag and test the environment.
    6. Merge to Master the latest tag and push Master to remote.
    7. Close the task in the issue tracking system.

In GIT language:

For QA guy:

Get all tags
git fetch --tags
Move to the tag
git checkout q-1.1
Update from Master
git merge master
Create new tag for testing
git tag r-1.2
Push the tag to remote
git push origin r-1.2 / git push --tags
Test on stage and approved

Move to the approved tag
git checkout r-1.2
Create new tag for update production
git tag p-1.1
Push the prod tag to remote
git push origin p-1.2
Update Prod test and approve

Move to Master branch
git checkout master
Merge the approved prod tag to Master
git merge p-1.1
Push updated Master branch to remote
git push

For developers:

Create new feature branch up from master
git checkout -b f1234
Commit changes
git commit -am”message”
Update local master from remote
git pull origin master:master
Merge feature branch from master
git merge master
Make sure nothing break

Create tag for QA testing
git tag q-1.1 -am”message”
Push the tag to remote and QA
git push origin q-1.1 OR git push --tags (for all)
Coming back to master
git checkout master
Delete feature branch
git branch -D f1234
Start over

* Sometimes it’s make sense to stay on the local dev branch for few task and reset the branch to master between each task using git reset --hard master

Git Workflow Diagram:

No comments:

Post a Comment