Times are challenging and many Organizations are taking the momentum to re-think their processes and working strategies. Teams must be Collaborative. Now more than ever, choosing the right collaboration model is imperative to create Automation procedures, and technical teams are responsible by evaluating and propose the best approach.
The market is competitive but there are some more “resilient” collaboration tools than others. In 2005 Linus Torvalds presented to the world a new distributive source-control management (SCM), which he named git. A few years later it has become the most adopted SCM in the world, dethroning some of the most popular ones, such as SVN or CVS.
Nowadays, git is primary a hosting provider for large companies like Microsoft, GitHub, Gitlab, Bitbucket and it is used by millions of users every minute. This video series from Scott Hanselman is very complete, if you have a chance, watch it.
There are tools and Git Workflows.
There are several collaboration strategies; from the simplest one where every member of the team commits to the same branch, to a more structured workflow approach, such as the notorious Gitflow.
Most community collaboration projects follow a Fork and Pull Request (PR): the user creates a copy of the project to themselves, implementing the fix or adding a feature, to finally create a PR to the origin repository that the owner(s) can accept, request changes or reject.
But the GitLab flow and the GitHub flow are both intended to simplify the workflow, making it more “agile” in continuous deployment models. Atlassian has a nice article comparing several models, including the Centralized Workflow, Feature Branch Workflow and the Forking Workflow.
Go with the Gitflow.
The Gitflow workflow model was proposed by Vincent Driessen in 2010 and ten years later it is one of the most used models by development teams. Its core resides on multiple branches with suggestive naming and semantic meaning.
Image from nvie.com
Main and Supporting Branches.
There are two main branches In Gitflow: master and develop. The master branch is considered when the code is ready-to-go to production and it’s the root of all truth. As to the develop branch, it is considered as the current state of the project development.
When the release management establishes that development is finished or the developed features are Done (i.e. respects the project definition of done, passes the tests, etc), a new Release should be made by merging the code from the develop branch into the release branch, do some maintenance task and then merge into master branch, usually through a pull request.
There are three more supporting branches from the original model, like Feature branches, Release branches and Hotfix branches:
Feature branches are the ones that reflect the application development features, like bug fixes or project work items, that will not break the application day to day activities. If it is something with serious impact on production, you should consider using the Hotfix branches. Once the feature is done the code is merged into the develop branch through a pull request and all remaining feature branches should sync with it to import the latest changes.
Released branches are created from the develop branch and reflect a new release version to be prepared. Within this branch, several activities like bumping the release version are in order. Once the release is closed and considered done, the code is merged into the master branch as this version is on production environment.
Finally, the Hotfix branches is where critical application errors or bugs are going to be fixed. Once implemented the are merged into the master branch so they can be deployed into production environment and then into the develop branch, so the fix would be integrated into all in progress developments.
Vincent Driessen also makes available in his GitHub repository a collection of git extensions to provide repository actions to relate to Gitflow mode.
Why using a Collaborative Model?
Choosing your team collaborative model should be a thoughtful decision that needs to also consider the release management model. But most important, this model must adapt to the project needs, always having in mind that there is no such thing as a model that fits all.
A structured and defined released model makes any collaboration model simpler, turning CI/CD pipelines more effective. The more chaotic the release model you select, the more complex it will be the collaboration flow model, and in these cases I recommend an extra branch called prerelease branches.
These prerelease branches are created from develop branches and merged from feature branches as pull requests. This way you can combine features into new branches to be “deployed” and “tested” in user acceptance test environments, validating any feature that may not be approved right away.
If you’re are still in doubt about the best Collaboration model for your project, I hope this article brings some clarity: the Gitflow model can be adapted to your’s and your team’s more complex needs, having some automations that can be made like automatic semantic versioning through gitversion or through git TAGs.