Branching Strategy to organise diverse projects

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 contribution 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

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

total control

But what if you work not alone?

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

Lab

purpose: isolated development (and QA)

branch name: [issue-code]-[title], for ex. web-113-picture-in-picture

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

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?

code freeze

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 in that.

Release

purpose: release candidate

branch name: release

main unblocked

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

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

only one release can exist per time

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

yes, we do mistakes

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

So we do hotfix to deliver quick and gradual change.

once we had 7 hotfixes in a row after a major release of our application, it’s important to have possibility deliver hotfixes quick

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

hm… it looks like Git Flow

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

Scaling

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

some of our repositories are home for multiple projects

and multiple brands delivery

our projects are actually multi-brand platforms, each brand baked with individual design and amount of features

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.