Git mastering 2

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:

we had small dev team
we had good qa team close to dev team
we deployed to qa often an tested quickly
we included small amount of features in release
we delivered good quality and had almost no issues on regression
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

increased dev team but didn’t increase qa team
included on sprint plenty of features (deadlines required to release more staff and faster)
weren’t allowed to run regression on each sprint because of time limit
got longer regression test period but rare
got much more issues on regression
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.