Branching Strategy to organise diverse projects

Posted

At Zattoo we have multiple projects with different complexity and various amount of people working on them. From internal sandboxes with the interest of 0.3 developers to Emmy award winner applications with contributions from the whole frontend team.

Such projects eloquence requires a flexible approach to work with repositories from one hand, and there should not be a difference in processes from another. Something that scales with raising complexity.

So here I will try to explain, how our release cycle is made and how we came to such a solution, from the simplest case to hardest, stage by stage.

Stages

Stage referencing to some branch or branches group connected by a single purpose.

Main

purpose
aggregates development
branch name
main
lifetime
constant

If you work alone and own your changes, you might not need anything else. Direct contributions, deliveries, single source, sounds good.

Main stage when your working alone

But what if you work not alone?

Main stage when your working with team

Here might come troubles, endless updates, and incompatible conflicts. So we might need another stage, something that can isolate feature development.

Laboratory

purpose
isolated development and QA
branch name
[issue-code]-[title], for ex. web-113-picture-in-picture
branched from
main
lifetime
temporary

Here contributors can branch from main, develop features, test them in isolation and create PRs back.

Laboratories

So the main became a more stable place... But what gonna happen if we want to create a release, seal it and test how all features integrated together?

Frozen Main

Some contributors could be blocked, sounds not something we want. Delivery should be continuous, we don’t want to stop or communicate freezes.

An additional release stage could help with that.

Release

purpose
release candidate
branch name
release
branched from
main
lifetime
temporary

Release

This branch created from main when we have enough changes for the next release candidate, it seals project state, only fixes accepted.

When QA is passed release candidates became an official release, it receives a unique tag and version.

And here we come to another question: where to keep releases? Shall we use the 🌵 cactus model and always keep release branches? Or better aggregate all releases under another stage...

Production

purpose
aggregates releases
branch name
production
lifetime
constant

This stage is the final destination for any feature contribution, it keeps all releases together.

Production

Looks good so far. We deliver releases to production, are we done here? Not really, because we forget about our fellows… bugs!

Production with bugs

When bugs found in production, and we want to deliver a fix, starting release cycle over again could be not the best idea: main could have new changes, the next release candidate could be sealed. So we need an extra stage.

Hotfix

purpose
bugs busting
branch name
hotfix
branched from
production
lifetime
temporary

So we do hotfix to deliver quick and gradual change.

Hotfix

Syncing

You can notice that production after receiving changes from release or hotfix goes ahead of main, so we might want to receive these changes back. So as soon as production receives an update, it back-merged to main.

All branches together

In the end, an attentive reader could spot that our strategy is very similar to GitFlow and going to be totally correct.

Scaling

We embraced GitFlow workflow and took it as the basis for scaling to multi projects handling

Multi Projects Branches

and multiple brands delivery

Multi Brands Branches

Afterword

Handling different process models is pain and the amount of manual effort spent on covering such differences often underestimated.

It's important to have automated and intuitive processes, so developers focus can be shifted from routines to development.