--- title: "Branch per Promotion" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branch-per-promotion.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branch-per-promotion/" tags: [] author: "Roy Osherove" description: "Lesson 12 of 17 in Beautiful Builds and Continuous Delivery Patterns (Branching Patterns for Continuous Delivery), 3:16. 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/" --- # Branch per Promotion 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 12 of 17 Duration: 3:16 [Watch on YouTube](https://www.youtube.com/watch?v=2Gl9eMi5q10) ## In this lesson With promotion branches, or environment branches, code must be merged into a specific branch to get closer to the customer, so the branches act as gates on code quality and on who may deploy. Roy Osherove counts the human steps from a work in progress branch through main to prod, with merges done nightly or by hand and permissions needed to deploy to staging and production. He concludes that this approach requires manual work and slows feedback from the customer, and points to the parallel fire hose for the case where people are using the test or staging environments. ## Transcript 552 words [\[00:03\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=3s) Let's talk about branch per promotion or promotion branches. The idea with promotion branches or some people call them environment branches is that the more stable the code the closer it can get to the customer. And to get closer to the customer, you have to merge code to a specific branch. And in this case, the branches are literally acting as guarding gates. sometimes about the quality of the code, sometimes about the permission of who can deploy and develop. And the idea a lot of it is about segregation [\[00:35\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=35s) Of code that is still not either valid or developed fully developed or or code that is known to be stable. Now the problem with this is that well there is no problem with this unless you're trying to do [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") and then there are a bunch of problems with this. And here again, the problems are all about people. Let's take a look at how many human actions it takes to have to deploy a piece of code from developer all the way to the customer in a continuous delivery fashion. [\[01:10\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=70s) You see developers here on the left develop code, they check in stuff to the WIP and then to actually you have an automated deploy. That's great. And maybe you run a bunch of tests in the build. But then if you want to move to the main branch where maybe QA might be working on something then you have to merge and maybe the merge is happening nightly in an automated fashion. Maybe sometimes somebody has to manually merge stuff. Either way it doesn't just happen immediately. [\[01:42\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=102s) We have to wait. Now if we want to merge from main to prod so that we can deploy the staging again someone has to do this. The idea is that we cannot get specific permissions to do something unless we absolutely need to do that something. So in this case, we're actually being guarded away from deploying to staging in production so that it happens the as least as possible. And one of the reasons is sometimes because people are using staging or production or they're using the test test environment or staging environment by QA [\[02:17\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=137s) And so it kind of seems like it makes sense but in this case a parallel fire hose will actually work wonders and I'm going to explain how parallel fire hose can help with that. But usually this approach is not really conducive to a continuous delivery mechanism because we still have to do all those manual merges. So this is kind of this is a different way of looking at it. We we have WIP or work in progress and we merge to main we merge to prod and sometimes we even have one extra branch to to have the previous release so we can always get back to it. [\[02:51\]](https://www.youtube.com/watch?v=2Gl9eMi5q10&t=171s) All these things are humans and things that we have to wait for. So in terms of continuous delivery, we require manual work. We team usually doesn't have a lot of permissions. So we can't automate a lot of that stuff. We don't have permission to deploy to production. So we cannot really get feedback as close to the customer as possible. Unless it takes a really long time to get it. ## Related - [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 teams that use branches to promote code to the next stage of stability, and the time those merges cost. - [Time to Main - Measuring Continuous Integration](https://pipelinedriven.org/article/2015/5/15/time-to-main-measuring-continuous-integration) · pipelinedriven.org Roy's 'time to main' measure of how long code takes to reach the main branch, which promotion branches lengthen. - [Human Bottlenecks](https://leanpub.com/pipelinedriven) · pipelinedriven.org Section of Roy's Pipeline Driven book on human bottlenecks, like the manual merge and permission steps counted here. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) [Previous lesson Branching Strategies](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branching-strategies/) [Next lesson Single Branch](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch/) --- ## 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/