Whether you are working on a small prototype or a big enterprise product, having a workflow for code releases is very important and fundamental. It just makes our life much easier and saves us from nightmares like prod rollbacks and code reverts.

And before we talk about the elephant in the room. Here are some obvious things from our dev workflow

• We use GIT on local for source control
• GitHub on the cloud for central source control
• Heroku for deployments

Our old release strategy

1. dev was our source of truth and base for any new task/feature/topic
2. We use to create a new branch from a dev for this new task/feature/topic

• git checkout -b feature/new-feature dev

3. We would work on the changes for the task and upon task completion, we would raise a PR against dev
4. This new feature would undergo QA testing
5. And would get merged in dev on QA sign-off

• git merge --no-ff origin/dev on branch feature/new-feature

6. Finally, it would get deployed on prod via dev branch

Pro

• Easy to understand and with fewer checks involved in prod release

Con

• There was a high possibility that a change that was merged was not ready for prod deployment/release and now because of that dev branch becomes
  • blocker in releasing an urgent hotfix/priority change
  • as any new change released directly via dev→ break the prod because of dependent change from the BE

• Creates a revert situation and possibility of code loss in the process of reverting the changes
• Creates diverged history and code conflict situation, for other people's from the team if they have taken a pull from dev prior code revert
• now they have to revert the changes in their respective branches, accidental loss of unpublished code viz hard to recover

So as a solution, we came up with the idea of sprint branches for every sprint release

Release strategy with sprint branches

Pro

• All the benefits as before and this solved most of the cons mentioned earlier

Con

• As we tend to decide in advance, in every spring meeting - what features will go in the sprint. There is a high possibility - TBH it was 9 out of 10 times that, some feature would delay the sprint and we won’t merge/release the sprint branch on decided date and time.

This created another set of issues,

• We put a hold on creating any branch for the upcoming sprint
• people are not sure where to point new features as the old sprint branch is still hanging in the middle of nowhere
• some features/fixes get directly merged into dev meanwhile which can be missed if not tracked carefully

With all this, managing the sprint branch becomes a task on its own that -

• It has not diverged from dev
• It has correct changes
• It doesn’t have any new changes which got merged recently to name a few

Solution and new release workflow

By adding a few simple changes which are as follows,

• For prod releases main will be used
• Every feature must branch off from the dev
• Every feature must get merged back into the dev with PR to dev
• Every feature will be merged and released in main via release/feature release branch with only one condition
  • They are tested by dev and QA
  • verified End to end
  • 80% stable
  • And has no pending BE dependency (the only exception is where, both FE and BE will go at the same time)
• Naming convention: feature/feature-name
• Flow: feature/cart-ux → dev → release-12-12-21-00 → main → merge main to dev

With this new change now we will have mainly three types of the branches -

1. Main branches
2. main
3. dev
4. Supporting branches
5. feature branches
6. release branches
7. hotfix branches

To expand these branches, see the following git flow graphs

Main branches

main

• Point of source for Prod releases

• Point of source for Prod hotfix branches (more on this on hotfix branches) dev

• Dev always have the latest development changes (QA verified and approved for prod deployment) for the future releases

• Every new feature should branch off from the dev → (git checkout -b feature/new-feature dev)

• After completion feature must merge back into → dev → release-branch → main → merge

Supporting branches

Feature branches

Point of source for feature development

• Every feature must branch off from the dev
• Every feature must get merge back into the dev with PR to dev
• Should be released via release branch to the main
• Naming convention: feature/feature-name
• Flow: feature/holds → dev → release-12-12-21-00 → main → merge main to dev

Release branches

Point of source for feature release from dev to main

• Every release must branch out from dev
• Must get merged into main
• Naming convention: release-dd-mm-yy-xx
  • xx is no of releases done on same day
  • e.g. release-12-12-21-00 is first release on 12th Dec, whereas release-12-12-21-01 is 2nd release on 12th Dec
• Git Flow : git checkout -b release-12-12-21-00 dev → merge release-12-12-21-00 → main → merge main to dev

Hotfix branches

Prod hotfix release branch

• Hotfix must branch off from the main
• Hotfix branch must get merged back into the main
• The Hotfix should be verified on pre-prod (alpha) → then only it should get deployed on main (prod)
• main should be merged into dev for syncing the history back

---

It’s not the thing itself, but how you use it — A.D. Aliwat, In Limbo

---

This workflow is not a rule of thumb that one need to follow. This is like a simple guideline if followed will make the team collaboration smooth and more like a simple routine.

So discuss with this among your team and see if this make sense for your need. And as always for more interesting reads keep an eye for future updates.