Let's talk about releases...

#gitflow #git #devops #cicd

Releasing can be considered as the continue exposure of your project to the real world.

What you have been working on is about to be tested and used by people. Therefore it's really important that you have a good process on how you are going to deliver new features and bug fixes to your end users. Let's start by describing from a high level what is a release.

Following the diagram showed above, releasing is simple, right? Well...

There are certain pieces that are not described in the high level diagram, as:

Multiple browsers/OS
Screen sizes
Accessibility
Compatibility with different languages
Different type of users (roles)
Variation in configurations
One module affecting another one
Having some issues in production that block users from using important flows in your App
An assumption that turns out is affecting the performance (A/B Testing?)
Etc

Since any of the previously described scenarios can cause issues while releasing, there's the need of more than 5 bubbles/steps (described before) to act accordingly and prevent or address any disasters in the release process.

When you release your code to production unexpected behaviour can happen, the local simulation/test is never enough.

There are some techniques that have been applied by different companies trough the years. One of the most common is GitFlow. Which has the following high level structure:

GitFlow

High level explanation of GitFlow (here you can see more details)

Process:

Master branch (production ready state)
Release branch (the code to be released)

a. The release happens periodically (it can be every sprint, every X weeks, etc)
Feature branches (each developer creates a branch and merge to develop when ready)
Develop
HotFix (fixes that need to go to production as they are blocking some important functionality)

Keys:

Testing phase - A defined time to test and stabilise the code to be released
Master, release, hotfix, feature and develop branches
Tagging your releases (Git tags)

In this approach the release happens periodically, it's more in control and there's some period of code-freeze where the release candidate gets tested to be released. If something weird happens in the middle or after the release, bugs can be fixed as a hotfix or as part of the testing phase.

Trunk based development

High level explanation of Trunk based development (here you can see more details

Trunk based development will always be release ready

There's only one main branch
All the branches are feature branches and live max 2 days before they get merged into the trunk

Keys:

Continuous Integration (CI) - Is a technique to automate analysis in the code to be released
Continuous Delivery (CD) - After running the CI the new release gets deployed to either Staging or a Sandbox environment
Staging - It serves as a sandbox environment where the code can be tested before promoting it to production
Semantic versioning - Automatically calculate the version depending on the commits
Code Review - It's important that some guidelines and best practices are set in the project, so it can easily get reviewed by the team members, code review includes: reviewing the code to follow the those practices as well as checking it to be maintainable, readable and scalable, as part of a code review a Pull Request Template can help in speeding up the process
Short lived feature branches - Max 2 days living branches as they need to be merged quickly, less code, better reviews less impact/change of regressions
Tagging your releases (Git tags)

Not because there's only one branch that means that you will blindly commit and merge code. There are some principles that need to be followed.

As there's only one main branch it should be production ready state, to guarantee that or to minimise any side effects, more automation is required, where the effort is to verify as much as possible before releasing, to accomplish it there are several levels of automation: