

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. Production environment is the environment that our final users will see and use. This environment is also known as Pre-Production, Release, QA, etc.

In Test environment QA’s will have a very relevant role. In test environment, we should execute more intensive testing and fix the issues we find to make this release stable for production. Test environment is used when we have a particular version, which we are planning to release. Normally, in Dev environment we can deploy and test functionally that we are currently developing for next version. If we are using CI/CD, each commit should be automatically deployed here. I will call those environments “Dev”, “Test” and “Production” (although there are other conventions like “Dev”, “Staging” and “Stable”).ĭev is the environment for development. These can be more than three, but lets focus on the basic pipeline.
#Gitlab branching strategy software
Normally, in software development, we can find three environments, where we will be deploying our versions for different purposes. Environments and software life-cycleįirst 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. 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. In this article, I will try to introduce them and analyse pros and cons for each one.

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. When you are working in a software project, one of the most important aspects is your branching strategy.
