Branching Strategies Explained

let's talk about branching strategies they are very interesting from many different aspects to begin with they are a good indication of the theme structures of the frequency of deployments of technical capabilities of test coverage and many many other different things they can enable us to do things in certain way or disable us from doing some other things more often than not by just looking at the strategy that you are applying when branching is concerned i can guess the size of your team so i can guess how frequently you deploy i can guess many other things but i'm not going to go into the guessing game instead we are going to explore branching strategies and see which one are you currently applying and whether you should stick with it or maybe try to move to something else but i need to make a decision should we go through a chronological order you know what were we doing 20 years ago what we were doing 10 years ago and what we are normally doing today or shall we go through them from the perspective of which one is the easiest one to apply and then move towards the hardest strategies let's do the latter let's start with whichever is the easiest one and then progress towards complex ones and the easiest strategy by far is trunk based development we have a single branch you know the main line or trunk or master or whatever you call it and everybody is cloning that branch making some changes locally and pushing directly to the main line no branches no pull requests none of those things just working on features or bug fixes and as soon as they're done pushing them back to the main line that is the easiest branching strategy there is nothing to do nobody needs to merge anything nobody needs to maintain anything we just push directly to the main line that does not mean that everything else is easy when doing trunk based development as a matter of fact it's not everything else is very very hard we need to have excellent cold call coverage we need to be really proficient in writing tests probably doing some kind of bdd td some type of testing in advance before writing code we need to have a strong automation we need to deploy automatically somewhere and so on and so forth one thing that is indispensable or almost indispensable in case of the trunk based development is that we need to use switcher toggles if we are pushing changes to the main line frequently and that is the most likely reason why somebody is using trunk based development then we need to make sure not only that those changes are tested and that they are valid and that they are working and so on and so forth but also that half-baked features are not visible to users so we need some form of feature flags of future toggles that will disable that half-baked feature from being visible to users even though it is deployed to production trunk based development is the true enabler of continuous deployment i could even argue that if you're not doing trunk based development you're not truly applying continuous deployment you're most likely doing continuous delivery or continuous integration or something else now that does not mean that continuous deployment is not possible without pushing changes directly to the main line it is but in most cases continuous deployment is strongly associated with trunk based development now if you're not sure what continuous deployment continuous delivery continuous integration is or if you would like to see how my definitions of those terms differ potentially from yours there is a video there is a link above my head and in the description so go and check it out if you would like to see more on that subject i will rank all the strategies by the madness level how much we go crazy and insane how much we hate ourselves when applying certain strategies in case of trunk based development madness level at least when branching is concerned is minimal non-existent low there is basically nothing to do i mean there are other things to do outside of how we create branches and merge them but within the context of branching strategy madness level low or non-existent the next one which is slightly more complicated is feature branching or github flow we still have a main line we always have a main line but whenever we want to work on something on some feature or a hotfix we create a new branch we tend to work fast when applying feature branching because features are typically split into very small chunks so that it does not take much time to write code for something and once we're finished we create a pull request we review that pull request we run some automation as part of that pull request and once everything is fine once nobody complains about the code quality the tests are not failing and what's or not we merge that branch back to the main line the important thing about feature branching is that we work on very small chunks of something and we have very short delivery cycles typically a team working with future branches would finish working on a feature within a day or even a few hours sometimes couple of days but anyways let's say it on average within a day and that means that not only code is written and tests are written but also pull request is created reviewed confirmed approved all the stuff that you normally do and then within a day on average that something is back to the main line when using feature branches typically we are doing continuous delivery or continuous integration continuous delivery more often than not if you're not that confident in what we are doing it could be continuous integration but that would already be a smell that there is something wrong feature toggles are extremely useful they're not necessary as in trunk based development but still very very useful pull requests are a must and we create pull requests not only when we are finished working on something but whenever we want feedback so it could be in the middle of development i want feedback from joe or whomever some some colleague of mine and i could create a pull request get the feedback continue working on it push push push push and once everybody is satisfied once i got all the feedback implemented all the feedback it goes back to the main line from the perspective of the amount of work and madness involved in working with future branches it is very low low level of madness there are additional tasks to be done when compared to trunk based development we need to create pull requests we typically need to review those pull requests and merge them to the main line so there is additional work involved nevertheless madness level or the level of insanity that we are experiencing is very low next in line is the forking strategy that one is almost the same as when using feature branches the major difference is that we do not create branches from the main line we fork whole repositories work on something and then create a pull request back to the upstream the most common use case for forking is open source typically in majority of cases actually if you want to contribute to an open source project you do not clone the repository of that project instead you fork the repository create a copy of that repository and then work in your own repository and when you're done you create a pull request and the rest depends on the policies of each project the major advantage of forking repos instead of creating branches is that we do not need to deal with permissions and our back madness only the maintainers her core team you know usually a few people have direct right access to the repo and for everybody else the only thing we can do is either read a repo or fork it and then once we fork it it's ours right there are no restrictions and pores by the team behind the top resource project anybody can fork anybody can read and nobody can do anything else in the original repo except the maintainers usually very small number of them the insanity level or the madness level is the same more or less like with feature branches it's slow there is not much to do beyond reviewing pull requests and approving them then we have release branching unlike future branches releases normally tend to be longer lasting weeks or even months since different teams might be working on different releases then we have a branch for each release release one with these two reduce three one team would be working on one release another team and another release typically we would have additional branches one for each hotfix and that's where situation gets a bit more complicated already because eventually we are merging hot fixes and those releases to the main line and whenever we merge something to the main line we need to make sure that all the currently open branches are also updated that they pull the changes and then bad things happen and then we are not continuously doing anything the work between different teams is very discontinued and disconnected until one team is finished only then the other team finds out hey what did they do how can i integrate my stuff with theirs and so on and so forth release branching is typically associated with low frequency deployments it is often used by teams who deploy once every couple of weeks maybe once a month sometimes even only a couple of times or even once a year if you want a single word that would associate the way how we work with release branching that would be waterfall now i know that many of you are now doing agile this or that but still there are many teams that are faking agile and still doing water foolish things and a very good indication whether you're still locked in that type of thinking and practices is whether you're using release branches we have merge conflicts we have deviation and we have delayed integration there is no continuous integration or continuous anything when you're using release branches the reason is very simple we have different branches and it takes a lot of time until they're merged back to the main line and it takes even more time until different teams or different people get to integrate their code with other people's code generally speaking you should run away from release branches unless you're a software vendor that needs absolutely must support multiple versions good example could be kubernetes kubernetes has different releases and it supports i think up to three previous minor releases or something like that so they need to have different code bases different branches different release branches so they can apply hotfixes you know things that must be done to multiple releases to all the releases of the software madness level or insanity level is already reaching medium release branches already mean that you might need a dedicated person sometimes even a whole team just to create branches and to merge things and to validate things it becomes very complicated it might not sound like that because you might be thinking hey this is so much safer because i have my release branch and you have your release branch and we can work on our own stuff but in reality it is more complicated than any other strategy that we have saw before the only potential excuse for release branches is if you have no automation if you have days weeks or months of manual testing in different departments and moving things from here to there and so on and so forth but still it can get much worse so if you're doing release branches you're in a bad situation but there are people who are in much worse than you and then we get to git flow git flow is when things get really complicated and silly and pathetic in a way typically when using git flow we would create a development branch and from that branch we would create feature branches like feature 1 feature two and so on and so forth and then we would create release branches also from the dev branch and those release branches need to be merged to the dev branch as well so that it's more or less sometimes eventually up to date and release branches are also merged to the main line because mainline is well the reflection of production but i hear that somebody is doing git flow and doing it for real i freak out i really that's where i become very comfortable and start thinking whether it is worth spending time with those teams unless the only reason why they called me is to help them get rid of it madness level can be described as send me to a mental institution if this is what we are doing i would be better off being in a mental institution than being here unfortunately that is a reality for many teams today often when i speak with teams applying git flow they are happy and they are happy because there are usually other devs who do not do any of those things they are just given a branch hey develop here that this is where you push don't think much about anything and then we have release management or release managers who are doing all the heavy lifting and merging and branching and the madness it's a job it's a role in a company and those people are often very happy as well because that's job security as long as this is what we're doing i am going to have a job that's silly of course but hey job security is important for some people let's just hope that that company does not go under because you will not find the job as a release manager anywhere else but it can get worse and i know that some of you are in a worse position than any of those that we spoke about and the worst one is environment branching that's similar to git flow but made more complicated we have a development branch and then we have a branch for every environment like staging integration what's or not we have release branches you know for this one where these two release three and then branches for different environments like development environment and staging environment and integration environment and then everything needs to be merged everywhere and everything needs to pull everything everything is multiplied by the number of releases we have in parallel and that's not all we have hot fixes as well they are like a cherry on top of a cake except that this cake is made of mud and not really anything you want to eat this strategy is silly because it assumes that we need a branch for each environment where we are deploying something you know for testing for integration for this for that that strategy is practiced by teams who do not understand that we do not deploy source code directly to any environment we create releases and releases are created once and then deployed to different environments it makes absolutely no sense it doesn't make sense today it didn't make sense five years ago and it didn't make sense 20 years ago even though 20 years ago that was the most commonly practiced strategy or even 30 years ago the madness level of this one is send me to mental institution because it will feel like i'm on vacations and if that is not an option please open a window and i'm going to jump now the question is which one should you be using and the answer to that depends on quite a few factors but i'm not going to go to all the details you know abc questionnaires and all that stuff i'm going to simplify it for you you should be using trunk based development either if you're a superhero you understand the importance of testing automation your coverage is so high and you trust your tests so much that you can push directly to the main line there are very few of us who can do that and not even for all of those who can do it makes sense to do it there is another group of people who should be using trunk based development and those are people who do not really care about quality hey i do not care what i'm deploying to production and i'm using trunk based development so either you're a superhero you really trust your tests you're doing everything so amazingly well that you can push directly to the main line or you do not care what goes to production so you just push to mainline and then let's see what happens maybe users will complain maybe they will not we'll find out you should be using feature branches if you're working in small self-sufficient teams with potentially small applications and you know how to split work in such small pieces that they can be done fast very fast if you're having an open source project then forking strategy is the one you should be using there's hardly any discussion about that almost every open source project assumes that you will afford a repo simply because they're not going to open it give it right permissions to absolutely everybody and absolutely everybody should be contributing to an open source project so forking is what we all do you should do release branches if you need to maintain backwards compatibility and apply some hot fixes to all the releases for the rest of us you know people who do not fit in any of the groups i already mentioned there are two options switch from whatever you're doing to feature branches or maybe release branches the second option is to run and never come back just leave don't do it it's not worth it life is too short to spend valuable time merging branches and resolving conflicts and all those things that i hope were left behind you

Channel: DevOps Toolkit

Views: 129,378

Keywords: branching strategies, branching startegies, branching strategies in devops, git branching and merging strategies, branching and merging strategies, branching startegies in devops, devops, devops toolkit, review, viktor farcic, trunk-based development, trunk based development, feature branch, github flow, forking, release branching strategy, git flow, gitflow, environment branches, trunk-based development vs gitflow, feature branch vs trunk based development, github flow explained

Id: U_IFGpJDbeU

Length: 18min 18sec (1098 seconds)

Published: Mon May 10 2021