Continuous Integration vs Feature Branch Workflow

when writing code how do you organize your work so that it's compatible with that of your team do you create a feature branch work until the feature is complete and then issue a pull request for the feature to be merged if you do then this isn't really continuous integration in this episode i want to talk about feature branching and continuous integration hi i'm dave farley of continuous delivery welcome to my channel if you haven't already please hit subscribe and if you enjoy the video hit like at the end continuous integration is something very specific here is the description that first introduced continuous integration and was published on the c2 wiki they described it in the following terms development teams use code ownership to minimize conflicts among people editing the longer engineers hold on to modules the more important it is to minimize conflicts what if engineers didn't hold on to modules for more than a moment what if they made their correct change and presto everybody's computer instantly had that version of the module you wouldn't ever have integration hell because the system would always be integrated you wouldn't ever need code ownership because there wouldn't be any conflicts to worry about the fundamental assumption of continuous integration is that there is only one interesting version of the code the current one i think that's a really nice description i've actually spoken about that before on my channel but what it means is that continuous integration is not about the tools it's about the thinking the way in which we think about change and that we should think about change differently continuous integration is about working so that our changes are always visible at least to our teammates this presents a problem when we start to think about branching because branching is exactly the opposite of that branching is about isolating change by definition we create a branch to hide changes in one part of the code from another as a result i have been known in the past to offer the following advice on branching don't branch don't branch don't branch i do that something as a something of a joke it may not be very funny but in information terms a branch is the same as that kids game where you fold a piece of paper and then draw funny pictures you each person takes a turn at drawing a part of the picture they don't get to see the other part of the picture and you end up with a funny result each person draws a separate part of the picture and then we all laugh at the results if we all get together and can see what everybody else is doing then drawing a nice picture is really easy but if we each work independently of one another then we may end up with a funny if you're playing a game or an unfortunate if you're writing software result this is the problem that continuous integration was invented to solve continuous integration is like everybody seeing everybody else's drawing as it evolves the subtitle of the book that popularized continuous integration was embrace change not hide change branches used to be costly they were badly implemented in most version control systems so there was a natural pressure to avoid them because they were a pain in the neck to create modern distributed version control systems changed all of that git in particular made branching really easy it really vastly improved the merge tools too the tools that allowed us to recombine separate branches at the point at which we wanted to this made branches feel cheap unfortunately while branches are cheap to create they can become quite costly in other ways very quickly the problem is that whenever we have a branch we have two different versions of the truth so how do we tell which one is the real truth often to be honest it's neither it's usually a some combination of the two versions that form a truth in the form in the sense of code that's going to make it into production let's look at this from the perspective of testing for a moment if we want to test our systems what we're trying to do is that we're trying to evaluate some kind of idea to a standard where we're comfortable with releasing that idea into production so we'd like to be able to evaluate our ideas quickly and efficiently on the route to production we're going to inevitably create branches of some kind we're going to as we're working on the code there are certainly going to be times when we we don't want to share the code that we're working on with everybody else my argument is going to be that those times should be very short but we'll come to that so we're going to create these branches now how if we want to be definitive if we want to really control the variables if we want to really understand whether our changes is correct or not safe or not to release into production then where do we test those those changes if we've got these separate branches then clearly we must consider the points at which we merge the changes back into the line of code that is going to end up into production master trunk head whatever you want to call it certainly we must be writing tests at these points to be sure confident in our changes if that's the only place though where we run our tests there's a problem because if that's the only place when we run our tests what that means is that if i'm working on a branch and my branch lasts for a long time i don't get to know whether my changes are good safe alongside everybody else's until i merge at the end at the point at which i think i'm finished that's much too late for me to find out that i've been doing something stupid i want to find out that i'm doing something stupid much sooner than that so that i can stop myself doing stupid things what some teams do is that they will run what they call continuous integration on their feature branches the downside with this is that they are now testing a version of the code that is unlikely to ever be the version of the code that will go into production so we're spending time and effort and money on evaluating code that isn't the truth we're evaluating a different version of the truth in some way so a better strategy is to essentially eliminate those branches and always work on the line of truth in the code that and that's what continuous integration is as i said there are always versions of the code on you know at the point at which i'm making local changes uh they're going to be local and so what we are really talking about is shrinking those branches down to their absolute minimum typically when i'm working in continuous integration i'm going to write a test run it see it fail write some code run it see it pass refactor the code and the test and at that point i'm going to commit so if i'm doing well i'm probably committing every 10 or 15 minutes throughout the working day that means that i'm only ever 10 or 15 minutes away from the truth of master head trunk whatever you want to call it that is continuous integration that means we still evaluate every time we commit our change to master but that keeps the changes flowing it allows us to get much deeper insight into what our teammates are doing and more importantly what what our change how our changes work with their changes the definition of continuous integration says that members of a team integrate their work frequently usually each person integrates at least daily so if you are not integrating at least daily it doesn't really count as continuous integration the devops handbook says the data from the puppet labs 2015 state of devops report is clear trunk based development predict that is continuous integration predicts higher throughput and better stability and even higher job satisfaction and lower rates of burnout the man who invented git the version control system that nearly all of us use these days says if you merge every day suddenly you never get to the point where you have merge conflicts that are hard to resolve so all of this points in the same direction we should work in tiny steps we should commit those steps often and we should at least daily and we should by preference prefer to do a lot more than that we want to commit many times many small changes every day as one of my friends once said when describing continuous integration continuous is quite a lot more often than you think inevitably this way of working implies a trade-off we can't afford to wait until our feature is complete before we commit that represents a significant change to the way in which we organize our work it means that we need to become comfortable with the idea that we can commit partially complete features if we're practicing continuous delivery it gets worse not only do we need to feel comfortable committing partially complete features we need to be comfortable with them being deployed into production too continuous delivery is working so that as software is always in a releasable state so that means that any of our changes may end up in production so how do we do this how do we organize to to work in this way the jargon in continuous delivery parlance is to separate deployment from release the idea is that we are happy to deploy a partially completed feature into production that is not yet released in the sense of being available for people to use there are three common strategies there are more than this but there are three common strategies that i want to talk about today the first is dark launching we deploy something that people can't see yet it's not wired into the production system in a way that's useful or available to the people using the system it could be some code and a test that isn't that isn't connected up anywhere else it could be that the code the code just isn't used yet or maybe we build the back end of some feature before uh adding the ui at the end or not connecting up the ui to the rest of the ui so people can't find it or this is an excellent strategy and allows us to do some really quite sophisticated things i once built a very high performance messaging system which involved clustering and failover and distributed asynchrony using this strategy step by step by step and putting that into production step by step by step the next of these key strategies is branch by abstraction this is a great technique for allowing us to release big changes incrementally we improve the abstraction in our existing code step by step um allowing cleaner interfaces evolving clean interfaces over time to improve its modularity then we can start to replace small components of the system with new ones over many deployments and releases potentially we can use this in combination with dark launching to really good effect we can even run old versions of a module in parallel with the new so that we can figure out whether the new one uh fulfills its its intended behaviors finally the strategy that everybody has heard of is feature flags we hide a new incomplete feature behind a software switch a flag we continue to develop the new feature over time over many different deployments perhaps behind the flag until it's ready for release and then we flip it make it available by flipping the flag again this works really really well in combination with the other strategies i would recommend that you adopt these approaches pretty much in the order that i've mentioned feature flags is often the first thing that people jump to i would suggest that dark launching is probably a little less risky in some ways feature flags has the downside of which version of the code do you test but but all of these strategies are really useful if you've been thinking carefully about what i've been saying as i've been describing this maybe you're thinking of of this question isn't this just information hiding the same way that a branch is well yes this is all of these strategies involve a form of branching but they are quite different in an important aspect and have different properties as a result imagine for a moment making a big change in your code base if you're working a team working with feature branches imagine making that change replacing a widely used function or class with something a little different perhaps if i work on a team where every developer has a long-lived uh that is longer than a day feature branch then my options to uh are to race them to try and get my committing before they do so that they don't force on me some horrible merge as a result of the widespread changes that i've just made if i do that then really what i'm trying to do is that i'm trying to give my colleagues the pain rather than i have the pain my colleagues are going to have an unpleasant merge when it comes time for them to merge or i wimp out and i don't make the change at all because it's too hard that's pretty much the choice that i have the ci strategies branch but they branch on behavior not on code and behavioral branching is different we can have multiple behaviors in our committed set of code that we can all test in parallel with each other and evaluate in parallel with each other and change in parallel with each other but they're not all available for use at runtime so if i create a merge problem for my colleagues by doing the same kind of refactoring in a ci world then at worst i've cost them a few minutes worth of merge pain or work in the very worst case if they had to throw away their changes and redo them maybe it's 10 or 15 minutes worth of work if they're working in the way in which i described because if you're committing regularly throughout the day your changes will be small and simple and so the amount of investment in those changes is small and simple version control is a foundational idea in continuous delivery our aim should be to ensure that every bit and bite that ends up in production is the one that we intended it to be and to a large extent the one that we tested thank you very much for watching you

Channel: Continuous Delivery

Views: 187,187

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: v4Ijkq6Myfc

Length: 17min 31sec (1051 seconds)

Published: Wed Jan 06 2021