Why CI is BETTER Than Feature Branching

i'm a very strong believer in the value of continuous integration i've been using continuous integration in some form for a very long time i believe that feature branching doesn't fit into a continuous integration based approach though i've talked about this before but this time let's look at it from a slightly more technical perspective what does integration really mean and how do we manage it when working as part of a team [Music] hi i'm dave farley of continuous delivery welcome to my channel i'd like to thank everybody for watching we're rapidly approaching 1.5 million views and 50 000 subscribers i get a lot of pleasure from making these videos and i particularly enjoy reading the comments section and learning from other people's experience and ideas so if you haven't already please do hit subscribe and join us and like if you enjoy the video and do add your comments let's keep the conversation going i'd like to also add my thanks to our sponsors harness equal experts octopus and spec flow they're all helping us grow this channel and so please do support them by checking out their links in the description below if you'd like to learn more about continuous integration branching and deployment pipelines check out my online training course anatomy of a deployment pipeline my views on continuous integration and feature branching are probably the most contentious things that i tend to talk about there are many things that i talk about that are only my opinion but i don't think that this is really one of those type of things let me explain a little bit what i mean i spoke about continuous integration and feature branching in a previous episode and got lots of comments so in this episode he's really focused on looking at what i think some of the misconceptions of feature branching really are based on some of those comments and based on other discussions i've had with people over the years i should begin by saying that of course it's possible to do development using feature branching of course you can even do a good job my argument though is that if you want to do the best job rather than only a good job then i think you need continuous integration the other aspect of feature branching is that when it does go wrong the downsides are extremely severe the hp laserjet team used to spend five times as much effort on managing branches as they did writing new code before they adopted continuous delivery and with it continuous integration my aim for this episode though is to look at this primarily from the perspective of change and managing change let's begin by imagining a single developer working alone they need version control too it allows them to step back to a secure position when they make a mistake how they organize things though is entirely up to them the simplest way is just to maintain a stream of changes that build upon one another trunk based development after all why would you feature branch if you were working alone what does it give you that you don't already have with less typing developers working alone though still benefit from feedback that tells them that each of their changes works and that everything else works afterwards too so continuous integration let's imagine now two developers first working independently of one another if their code never touches the other person's code never interacts in any way then clearly there's no integration required ever except for integration within their own personal stream of changes as before but it gets more interesting when their code is part of some bigger shared system here each developer is making changes in parallel with the other at each step they add a change so at each step the total amount of change increases it creates this kind of expanding code of change into the future the longer the time period the wider the cone if you wait long enough at some point the cones are going to intersect that is the changes will clash and at that point you may have a problem of course you may not know it yet continuous integration works by limiting the time period and so limiting the fan out of the cone of changes this reduces the risk of a clash of course there are things that you can do in design that reduce the chances of one developer's code breaking another's but if there is anything anything at all that is shared between the two developers work then they are coupled to a greater or lesser degree and so at some point their changes will interact one developer's change may affect the other you can only find out if my changes affect yours when you see them together when they're integrated and not before let's just think for a moment in abstract terms about those changes as time progresses the quantity of change expands eventually it's inevitable that the change in one place will overlap with the changes in another a few people suggested in the comments to my previous video that if you have an idea of the course of the other people's work will take then you can steer your work to avoid theirs this is of course true but also quite tricky to get right it's also severely limited in terms of the size of the code base that you can work with in this way because it relies on you understanding not just what you are doing but also what everybody else is doing and is what they're going to be doing too plus this is stuff that's going to happen in the future so this is a guess and it's bound to be wrong at some point we can limit the risk by changing how we organize our work instead of buying into this complexity we simply shorten the time horizon during which changes can expand sure our changes may still overlap but the worst case is with a short time horizon is that we're going to lose that time horizons amount of work a few minutes or at most a day's work perhaps i once worked with a team that hadn't been able to even compile their whole system for over 18 months because of the branches of work had diverged so much that project wasn't savable so 18 months worth of work for every individual on the project about 250 people on this project was lost this is expensive small time horizons matter a lot when trying to limit the risk of guesses about the future the most common are comments that i got to on my previous ci versus feature branching video was i can regularly pull changes from trunk or origin master to my feature branch so i'm continuously integrated well i'm afraid that you are not let's look at that idea in a bit more detail we have a team of three developers here each making changes on their own local feature branch in this little animation i'm trying to visualize what each developer can see as they make progress and the current state at each stage of the release branch whatever we decide to call that each developer is working on their own changes to keep things simple let's just assume that they pull a copy from trunk every time they make a local change what can they see initially the developers are working blind however many times they pull changes from trunk all they see is what they already have because nobody's committed any changes yet as obviously as long as no one commits no one sees changes from anyone else now developer c pushes their finished feature c's view of the changes are now accurate compared to trunk they are in step but still has no visibility at all of a and b's changes c may have committed something that breaks a and b no one knows that yet a and b continue making changes they pause c's changes but now everyone has a different view of reality c never even knew about a and b b c c's changes but not a's a c c changes but not b's next a pushes their finished feature now you may have noticed that i haven't said anything about time scale here this is always true feature branching or continuous integration until you integrate your changes you can't be sure that they will work if you think that you can be sure then i think that you're fooling yourself it may be a risk that you can get away with but there is never any guarantee that someone else's code won't break yours so if this rich is always there what can we do well the interesting part is really this first period where no one knows what anyone else is doing as soon as someone commits something we get a chance to see what's going on we get greater visibility even if we are only pulling changes from trunk to our own local copy but until that point you're working completely in the dark so the best plan is to make the period when we are working in the dark as short as possible and so the risks as low as possible if you're working on a feature branch team you should certainly pull changes regularly from trunk just in case someone else pushes a change but this works best when everyone else is pushing frequently practicing continuous integration even if you are not and that's not a terribly team-centered approach is it presumably if you work on a team that practices feature branching then you're all pushing roughly as often as each other so you're all working in the blind to some extent during the period where nobody is yet got far enough with their features to be able to commit anything continuous integration is all about the shortness of the cycle it's all about shortening that period when everyone else is in the dark so okay it's not really continuous but that word is in the name for a reason ci is about integrating as close to continuously as we can sensibly get as i said in my previous video on this topic continuous integration comes at a cost it means that we need to adapt the way that we work to achieve it i spoke last time about ideas like dark launching branch by abstraction and feature toggles but it's not some lunatic fringe idea this is how many companies many that you have heard of some of the kinds of companies that you probably aspire to work in one day organize their development it not only works but the data says that it works to produce measurably higher quality software more quickly than other approaches including feature branching as i said this is the most contentious idea that i talk about it causes emotional divisions between people i'm trying as far as i can to make a less emotional argument here this is not really about what i think or about what you think it seems to me about something a bit more fundamental than that it is an incontrovertible truth that if we have information in two or more places and that information is being modified in each place then the longer the time the more those copies will diverge from each other that is not for debate that is only fact as the amount of divergence increases then the amount of work to reconcile those copies to bring them back into something coherent increases too yes we can alleviate the risk by informally imagining them merged together at some point in the future which is what the plan to allocate work so that it doesn't clash does but that too is down to our guesswork our predictions of the future and we're not good at making predictions like that with any great precision so the only answer that deals in truth in fact rather than in our own guesswork is to try and bring the different copies together more frequently to work in smaller steps and to integrate those steps more frequently without the continuous bit we only have integration integration continuous or not comes at a cost there is always the risk that we have made a change that can't be integrated so ultimately whenever you do work separate from others you're taking the chance that your work won't merge at that point you may have to discard the work so continuous integration reduces the risk of that happening by reducing the time scale of our work and so the amount of change that can happen prior to the merge it also reduces the cost of failure because if it does happen and you only and you can't merge your results you only lost a small amount of work my friend and co-author of our book continuous delivery has a take on why this idea is so contentious jess says that he thinks that it challenges some pretty fundamental ideas about how we think about software development and i think he's probably right feature branching plays to the image maybe even the self-image of lone programmer social introvert heroically doing great things in the code base as soon as we begin to write code with other people though this model really fails software development in teams is a social activity like it or not the best teams based on what i've seen personally but much more importantly than that based on the data are effectively promiscuously continuously collaborative they make progress as a series of small frequent steps continuous integration facilitates and reinforces that collaboration i hope that this video may show you why that is the case if you've got any thoughts on any of the stuff that i've talked about today please do add them in the in the comments particularly if you think that my reasoning is flawed in some way explain to me how i'm wrong thank you for watching [Music] [Music]

Channel: Continuous Delivery

Views: 72,373

Keywords: continuous integration, ci deployment, cicd, continuous integrations vs feature branching, feature branch, feature branching, feature branch workflow, git feature branch, software branching, devops, software engineering, modern software engineering, software development, Dave Farley, what is continuous integration, continuous delivery

Id: lXQEi1O5IOI

Length: 16min 8sec (968 seconds)

Published: Wed May 26 2021