/CTO @Software Service and Innovation /JUGLviv leader /JDayLviv co-organiser


Git mastering 2

Andriy AndrunevchynAndriy Andrunevchyn
Some time ago I described how we migrated from SVN to GIT. As usual when somebody migrates from one to tool to another, also they bring their previous experience (good or bad). So we did the same.  We used the following approach  Everybody developed on their own branches then merged on dev branch, that branch we use for deploying on dev server and testing some features which we were not able to check on local machine. Then all changes during current Sprint were pushed to qa branch and deployed on qa server where QA engineers tested features. Before release we announced code freeze for a day just to run regression testing.  Once regression were completed we merged from qa branch to prod branch, created release tag and deployed on prod server. We used Jenkins with separate jobs for dev/qa/prod environments. Dev/QA/Operation team had corresponding access only to required jobs hence everything were secure and strict. Such setup worked pretty fine for us because:
  1. we had small dev team
  2. we had good qa team close to dev team
  3. we deployed to qa often an tested quickly
  4. we included small amount of features in release
  5. we delivered good quality and had almost no issues on regression
  6. we didn’t develop different version simultaneously

New Project

But then we started another kind of project… we were short on time and budget so we
  1. increased dev team but didn’t increase qa team
  2. included on sprint plenty of features (deadlines required to release more staff and faster)
  3. weren’t allowed to run regression on each sprint because of time limit
  4. got longer regression test period but rare
  5. got much more issues on regression
  6. got more requests to hotfix something on prod
So with existing git process described above we faced next issue – from time to time we required two “qa like” branches and then heavy conflicts on merging to prod branch.  The only thing we wanted to keep was Jenkins with separated jobs for dev/qa/prod versions of source code and secure deployment procedure.

New Approach

I tried finding help on Facebook(Ukrainian only). As a result of 161 comments we built new git procedure We have dev as default branch. On the first day of Sprint we create new release candidate branch with strict pattern “rc-{expected release date}“. Those rc- branches we use for deploying on QA environment. Our Jenkins recognizes pattern rc- and suggest only them for deployment on QA server. During Sprint once or twice per day we merge changes on qa branch and then deploy. Two days before release we announce code freeze only on qa branch. In case QA team finds some issue DEV team fixes it on dev branch and cherry-pick to qa branch. As soon as rc-* branch are tested we create release branch with naming  “re-{expected release date}”. Jenkins job for production recognizes only branches with name re-. After production deployment we run smoke testing, create release tag and delete outdated rc- and re- branches (usually we keep last rs- branch and two last re-* branches).  Dev, all rc-/re- branches and release tags are GitLab protected just prevent removing branch/tag by mistake. With new approach we could easily develop two versions simultaneously or deliver hotfixes without burden on merging different branches. I hope this article will be useful for you. If you have some suggestions or comment don’t hesitate to let us know.

/CTO @Software Service and Innovation /JUGLviv leader /JDayLviv co-organiser