The Dev World – Sergio Lema

For months, I’ve been thinking about stopping to use Gitflow on the project.

The Problem

There are too many requests that I can’t do with Gitflow, such as:

• deploying a single feature
• or rollback a single feature

To do so, I had to spend days separating the code to deploy (or rollback) from the rest of the project.

Feature toggles

The first solution I’ve chosen was the feature toggles. Surround every feature with a single boolean.

This way, I can deliver all the features in production and turn them off if needed.

What’s the problem?

I must add the feature toggles to every single feature developed. Even if I think it’s too small.

What about the refactorings or bug fixings? I must maintain both versions. This can lead to a lot of complexity (and I don’t wanna think about testing all the scenarios with all the toggles activated or deactivated).

And finally, when I deploy the feature and it’s stable in production, I must remove the toggle and the old version.

A lot of work.

Advanced Feature branches

I’ve been studying another solution. It’s a different strategy of feature branches.

I’ve read a lot of blogs and articles:

• https://octopus.com/blog/rethinking-feature-branch-deployments
• https://jp-lambert.me/continuous-isolation-freely-choose-the-next-feature-to-push-to-production-4ac0079b97c5

But some may need a separate environment for each feature. Too expensive.

Another problem I face was with features which imply modifications to the database.

Let’s say I implement a feature A which needs a new column on the table in the database. When deploying the branch associated with the feature A, the database migration tool will update the database schema by adding the new column.

The problem comes when deploying another feature branch, feature B, which doesn’t have the previous column. I deploy it to an environment where the column is already created.

Depending on the ORM used, this can cause problems. But it surely will cause a problem if the modification on the database is a rename of a column.

So, this option was also discarded.

My Advanced Feature Branches

My solution is to pick a part of the solutions and compose one adapted to my case.

Every feature must be in a separate branch. Starting from the main branch.

I then have different branches per environment:

• alpha which will be deployed to the development environment;
• beta which will be deployed to the test environment;
• rc (release candidate) which will be deployed to the pre-production environment;
• and main for the production environment.

Then, I merge each feature branch on alpha, beta or rc depending on the environment I want to deploy. Never merge directly to the main branch.

This means that I don’t deploy a bunch of features to an environment, but I add single features as needed.

I don’t need to merge a feature to all the branches before deploying it to production.

What will go to production? Only the rc branch. All that’s deployed on the rc branch and pre-production environment. This let me test the complete set of features together before deploying to production.

What happens with the alpha and beta branches? I update them with the main branch after the rollout.

And finally, the rc branch will be backup and recreated from the main branch. To be sure I start again from scratch.

What if I want to rollback a single feature from alpha or beta or rc? I recreate the branch from the main branch, and merge again all the features needed.

The problem with the database migration is still here. But I use to develop with each feature which needs a database migration, also a rollback script. This way, when a recreate a branch without a migration, I can easily find the rollback script and apply it.

Conclusion

After using this framework for almost one year, here are my feedbacks:

• Never delete a feature branch, as it will be merged to alpha, beta or rc later;
• Solving the conflicts can’t be done with a rebase. As I must always start from the main branch, if there are conflicts to merge on alpha, I can’t rebase over alpha, otherwise I take the complete history of alpha into my feature branch (which will be later merged on rc);
• The release notes can be done just be watching the merged branches. I use to name the feature branches with the ID of the Jira ticket;
• Long features and small features can be deployed whenever I want. They can be moved from sprint to sprint without impacting the rest of the features.

If you want to learn more about good quality code, make sure to follow me on Youtube.