Git and branching workflows




Introduction

When you are working in a software project, one of the most important aspects is your branching strategy. If you are using GIT (and if don't, probably you should consider it), there are several strategies, such as Gitflow, Github flow and Gitlab flow, etc.

In this article, I will try to introduce them and analyse pros and cons for each one. Spoiler alert, there are advantages and disadvantages for all of them, so taking that into account, you should consider which one fits better for your project and team.

Environments and software life-cycle

First of all, in order to understand why we need a particular branching strategy, we need to have clear which is the relationships between versioning, environments and software life-cycle.

Normally, in software development, we can find three environments, where we will be deploying our versions for different purposes. These can be more than three, but lets focus on the basic pipeline. I will call those environments "Dev", "Test" and "Production" (although there are other conventions like "Dev", "Staging" and "Stable").


Dev Environment 

Dev is the environment for development. If we are using CI/CD, each commit should be automatically deployed here. Normally, in Dev environment we can deploy and test functionally that we are currently developing for next version.

Test Environment

Test environment is used when we have a particular version, which we are planning to release. In test environment, we should execute more intensive testing and fix the issues we find to make this release stable for production. In Test environment QA's will have a very relevant role. This environment is also known as Pre-Production, Release, QA, etc.

Production Environment

Production environment is the environment that our final users will see and use. For this reason, if we find a bug in this environment and it is really critical for our users, we should hotfix that bug to sort it out as soon as possible.

So all versions that we deliver follow the flow Dev -> Test -> Production.

Gitflow


Gitflow is the most known branching strategy, which tries to cover all the scenarios that we can find during our software life-cycle.

In Gitflow there are two branches with infinite lifetime:

  • Develop: in this branch, the team integrate all new developments and fixes for future versions.
  • Master: this branch contains the versions which are ready to deploy to production.


And there are also some temporary branches.

  • Release: this branch will contain new Releases in order to make it stable before going to production. When a new release is stable, we destroy release branch, merging the changes (if any) to master and develop.
  • Feature: when we start a new development, we create a new feature branch and we destroy it when we merge it to Develop.
  • Hotfix: if there is a critical bug in production, we create a temporary hotfix branch and we destroy it when we solve it, merging the changes to master and develop.

Advantages

  • There is a clear and well defined way to proceed, which cover most of the situations that we will find during our software life-cycle
  • There is a clear mapping between environments and branches:
    • Develop -> Dev Environment
    • Relese -> Test Environment
    • Master -> Production Environtment
  • It is a well known flow broadly used.
  • Some tools allows you to automatise the flow configuring gitflow branches (for example SourceTree).
  • You are sure that your versions are following a quality process as they progress through the workflow.

Disadvantages

  • You need to educate your team to use branches properly.
  • Sometimes to you need to merge into two branches (Releases and Hotfix).

Github flow

Github flow is a simplified flow, which only two kind of branches:

  • Master: this branch has infinite lifetime and always there is a change on Master, this should be deployed. 
  • Feature/Bugfix branch: This branches are created to add a modification, and they are destroyed after merging to master.

Advantages

  • Really simple flow, which works really well for open source projects.
  • CI/CD friendly, as you deliver each change as soon as it comes to master branch.

Disadvantages

  • There is not a quality assurance stage for new releases, which can be not realistic for enterprise projects.
  • It doesn't allow to hotfix a production version without delivering a new version from master. 
  • There is not a clear matching between environments and branches, which can lead to misunderstandings.
  • Assuming master is free errors is not realistic and it can be risky.

Gitlab flow

Gitlab flow is a branching strategy which tries to combine the simplicity of Github flow with the environments-oriented branching strategy of Gitflow. As a result, there are several workflows, depending on the needs.


Production branch with GitLab flow: it is the result of adding a production branch to Github flow.

Advantages

  • You don't need to deploy each merge that is completed on master, which gives you more control over the delivery.
  • You always have a snapshot of what you have in production in production branch.
  • There is only one way for merges.

Disadvantages

  • There is not a ¡release validation stage to make stable in isolation what you are going to deliver to production.
  • There is not a way to hotfix production branch without delivering all the changes you have on master, which can be a big limitation, depending on your delivery pipeline.
  • As for Github flow, you have to assume that master is free of errors, which can be not realistic.
Environment branches with GitLab flow: this flow proposes to have an infinite life-time branch per environment.

Advantages

  • There is mapping between branches and environments. 

Disadvantages

  • Same disadvantages as for the previous approach.

Conclusions

Now that you know the most relevant git branching strategy, you might know which is the one that fits for your project.

Based on my personal experience, simple approaches like Github flow or Gitlab flow are cool for open source projects or when there is not a third party client. However, I think in those approaches there are gaps and more risk involved when it comes to enterprise projects. Even when you have a decent set of automatic testing, for enterprise projects we normally have a QA stage in order to ensure that the new release that you are delivering to your clients is stable.

In addition, if you are not in charge of delivering timelines or you have several production clients, the concept of CI/CD per each PR will be problematic as you cannot decide what you want to deliver and when you are going to deliver a new version.

Finally, your clients might require a hotfix for the current production version, but they don't want any new functionality. For this scenario, Gitflow is the only one which can support this by definition.

Comments

Post a Comment

Popular posts from this blog

Building Micro-Frontends with Single-Spa

Image
Introduction Micro-services architecture is becoming trendy since it is a suitable option many projects, specially those that are complex and we want to be able spilt our business logic into different services that can be built and deliver independently. In spite of the fact that micro-services architectures are more complex, they increase the resilience of your system and increase the time-to-market delivery, which can be crucial for many companies. But it is not all about services and backend. With the introduction of single page applications (SPAs), we can build fully-functional user interfaces that can work independently in the browser. And here we should ask ourselves the same questions as for backend applications: Is my SPA becoming a huge monolith? Would I like to deliver functional modules independently? If you using micro-services, is there a relation between my services and your UI? Do we want to have functional teams that can deliver new features (frontend+backend) independe
Read more

Why you should migrate your old csproj to SDK format

Image
Introduction  With the introduction of Visual Studio 2017, the format used for csproj was updated including several advantages. This new format will be used when you create a new .Net Core project or .Net Standard library. In spite of the fact that VS2017 continues supporting old csproj format, you can migrate your old projects to SDK format. As a result, you will have the following benefits: Cleaner csproj files. With new format, a lot of things can be omitted, so your csproj files will be cleaner. Files are included using a wildcard , instead of including every single file.  Solution project references are simplier . NuGet reference packages as PackageReferences , so you won't need packages.config and you will be able to use wildcard in your references (for example, 1.0.*). NuGet package definition as a part of the project file. You won't need more nuspec files. Definition of AssemblyInfo attributes in csproj , you won't need more AssemblyInfo.cs files. In ad
Read more

AWS assuming role + MFA with pulumi (and other applications)

Image
Introduction In AWS, managing your IAM in a centralized account is a good practice, so then you can assume a role to access to other accounts without need of duplicating users. You can find more info about this approach in this article . In addition, for security reasons, it is highly recommended to enable MFA (Multi-factor Authentication), so you need a device to generate a temporary code to get access. In the image below it is showed how assume role with MFA works, but you also have an article about MFA in this link . This approach is really useful and most of the configuration can be automated with pulumi (or other providers like terraform or CloudFormation). And once it is configured, you can switch your role and get access to other accounts with a few clicks.  However, when it comes to external software such us pulumi, getting access assuming a role and using MFA might not be too straightforward. In this article we will see how this can be configured and how we can easily refresh
Read more