--- title: "Branching Strategies" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branching-strategies.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branching-strategies/" tags: [] author: "Roy Osherove" description: "Lesson 11 of 17 in Beautiful Builds and Continuous Delivery Patterns (Branching Patterns for Continuous Delivery), 4:14. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Branching Strategies 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Branching Patterns for Continuous Delivery Lesson 11 of 17 Duration: 4:14 [Watch on YouTube](https://www.youtube.com/watch?v=Ch1s-kuWaDQ) ## In this lesson Roy Osherove restates the aim of [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") as getting every level of feedback, from compilation and tests to environment requirements and what the customer wanted, as close to the customer and as fast as possible. That means [taking humans out of the loop](https://leanpub.com/pipelinedriven "Human Bottlenecks (pipelinedriven.org)") through automation and permissions, and keeping the code to customer loop short. He then lists reasons for branching, promotion branches per environment, release branches, feature branches, isolated components and different platforms, and says he will cover the first three. ## Transcript 682 words [\[00:02\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=2s) Okay, let's talk a little bit about [branching strategies](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture "BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture (pipelinedriven.org)") for [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)"). First I want to talk about the different what's the point of continuous delivery so that we can focus on it again and see which branching models can actually help that point rather than hurt it. So here's the strategy for continuous delivery. The way I see it, the idea is that we want to get feedback as quickly as possible and as far away from development as as possible or as close to the customer as possible. [\[00:33\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=33s) So production, staging machines, etc. Now the feedback levels or there are several feedback levels and we want all of them. We want to know compilers are that the code compiled okay that the tests are running and that the in the environments that the code is living up to the environment requirements such as permissions and performance scalability and that the code is is what the customer actually wanted. And all of these things are different types of feedback. [\[01:04\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=64s) So to do that we want to to to achieve that to get that to run in a continuous way we want to get rid of humans in the loop. That means that if developers don't have permission to move code around that we give them permission. We want to automate it as much as possible so that we don't need human beings doing things that take that the machine could do. So the more we do that the the faster we can get that feedback loop. [\[01:36\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=96s) Now to achieve being as close to the customer as possible we want to deploy to production as much as possible. So we want the feedback as as close to the customer as possible. So we deploy there as much as possible. But we also want to get it in the in the in the fastest time. So we want code to customer loop to be as short as possible and that means that code should not wait [\[02:06\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=126s) For a long time before a customer sees it or that it gets the feedback levels all the feedback levels in the closest point to the customer. So I would rather wait one minute than wait a week to know if my code passes all the feedback levels. Now that we know kind of some of the tactics, how do branching strategies actually help us or hurt us in those things? [\[02:41\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=161s) Well, when we talk about the branching, usually we need to understand why branching happens at all. Right? We use source control, we have branches, but why? Well, there are several reasons here. For example, a lot of people use basically create environments and only code in specific branches is allowed to go to a specific environment. This is called promotion branching or promotion branches. And the idea is that code gets becomes more important and as it becomes more stable, you develop it and you deploy it to a new to a more stable environment that's closer to the customer. [\[03:16\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=196s) Another option is that you might not have promotions, but you would like to create a new release. So, create a branch for each release that you have. And that's probably going to be one of the things we're going to use that I like to use to achieve continuous delivery. And you'll see why. Another option why people create branches is when they create new features. Now, if you're working with git that might be very very easy to do. If you're working with something like TFS might be very timeconuming to do. But that's not the reason why I think that actually hurts [\[03:49\]](https://www.youtube.com/watch?v=Ch1s-kuWaDQ&t=229s) Continuous delivery, but we'll talk about why I think that doesn't really work. Creating isolated components. So, a component per branch can think of it as kind of a variation of feature branches. Is the fourth reason. And the last reason is when you're working on different platforms. I'm not going to touch on the last two, but I'm going to touch on the on the first three of these. ## Related - ["Pipeline Driven" vs. "We have Jenkins Jobs"](https://pipelinedriven.org/article/pipeline-driven-vs-we-have-jenkins-jobs) · pipelinedriven.org Roy on letting pipelines rather than humans approve merges and deployments, the lesson's aim of taking humans out of the loop. - [BBBCTC - Branching, Binaries, Builds, Coding and Testing Culture](https://pipelinedriven.org/article/2015/5/30/bbbctc-branching-binaries-builds-coding-and-testing-culture) · pipelinedriven.org Roy on branching culture: branches mean merges, and fewer branches mean less time to main. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) - [Human Bottlenecks](https://leanpub.com/pipelinedriven) [Previous lesson Parallel Firehose](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/parallel-firehose/) [Next lesson Branch per Promotion](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branch-per-promotion/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/