Building a DevOps pipeline for your App: Git Strategy
When thinking about a DevOps pipeline the first thing most people think about is where am I going to host my build server? This infrastructural discussion is important but thinking about your day to day work and how your app will get released is just as important. This is where git strategies come in.
These are normally approaches that development teams use to collaboration on a single code base but is also to releasing software from a development team or an individual.
PS: This series of blogs assumes you are using git.
Two of the most common strategies that many development team use is either GitFlow or Trunk based development.
Let’s dive into these two branching strategies.
GitFlow
The GitFlow branching strategy is designed around development teams working on large projects that are focused on scheduled or continuous releasing. This blog explains this model really well but below i’ll explain a few key concepts that is needed for our Pipeline.
The most important parts about this branching strategy is that there are two main branches, Develop and Master.
Develop : This is the branch where all development going into the next release lives. This is the active development branch that developers will merge their code into on a daily basis.
Master : This is where the most recently released code that is in the users hands lives. Any code that is deployed to any app store should come from this branch.
Two other branches that are important to making this strategy work is feature branches and release branches.
Feature: This branch help developers to work on different features in isolation and give them the ability to then merge their features back into the develop branch which is the active development version of the applications.
Release: This branch is a branch you create off develop when you are really to release your code to your users. This branch is also used for acceptance or regression testing before being merged into our master branch and gets into the hands of users. Hot fix’s or bug fixes are also done off this branch and make there way back into develop when master is pulled into the develop branch.
What makes GitFlow a really awesome strategy to follow is that everything you do is prefixed with some kind of branching label. This adds visibility to what is being done on that branch and help us in determining what kind of CI workflows to run for a particular branch. A difference this strategy has that trunk base development doesn't have, is no long running release branches.
PS. I’ll speak more about CI workflows in later article about different CI servers.
Some disadvantages for using GitFlow would that it is a really long process from writing a few lines of code to getting your new features in users hands. This sometimes can also become confusing to know where you should be branching off of. It can also get really messy if the process is not automated correctly.
Trunk base Development
The Trunk based development strategy is a much simpler strategy. We only have one main branch that we need to think about. The difference here is that we would branch off master when doing any features and anything that gets merged into master should be ready to ship to users.
Release branches come from master, and they are tagged with a specific version. Bug fixes can be done on these branches, but as you can see above, those commits on the release branch don’t get merged back into master. This can cause inconsistencies in what the user has in their hand and what is in the development code base. Git does have some ways for us to deal with this issue such as cherry picking but it can be a more difficult thing to get right.
I would say that trunk based development would work really well in small teams trying to get their app to the users as fast as possible. However, without the defined labelling style for branches, it’s hard to create different workflows that could do different operations. With this being said, their is less workflows to create which is a bonus as this streamlines the process of getting your app into your users hands.
Protected Branches
Protected branches is not really something that is important to our pipeline but I thought I would mention it anyway. When I previously spoke about having main branches such as develop and master, these are normally branches we don’t ways want everyone to have the ability to commit to. We would rather make sure that code reviews are done and code is merged into the branch via a pull request. A way for us to in force this is by making your develop and master branches protected.
Protected branches help us with protecting specific branches for authorised changes. This is something to consider having on these main branches.
Final thoughts
So… how does this help in creating our DevOps pipeline? Well this is the start of our CI process as this is how we know what workflows to run on what pieces of code. Having a git strategy in place helps streamline your process and creates visibility of what’s happening at what point in the CI process.
This is probably the most important part of our DevOps pipeline.
In the next article in this series, we will look into different CI/CD platforms and what they can do for us to fully automated our pipeline.
Building a DevOps pipeline for your App: Choose a CI/CD server
Let me know your thoughts in the comments below if you are using any of these strategies and they compliment your development pipeline.
Get in Touch!
Thanks to Ashton Welcome for reviewing this post.
