--- title: "Release Branches" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/release-branches.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/release-branches/" tags: [] author: "Roy Osherove" description: "Lesson 14 of 17 in Beautiful Builds and Continuous Delivery Patterns (Branching Patterns for Continuous Delivery), 5:23. 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/" --- # Release Branches 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 14 of 17 Duration: 5:23 [Watch on YouTube](https://www.youtube.com/watch?v=MJqtHtOsXYo) ## In this lesson Release branches keep a single mainline branch where everybody checks in and add a branch for each release that has to be tested separately or maintained, usually keeping only the last two or three. Because developers' check-ins to main and the release under test can interfere in the same environments, Roy Osherove combines release branches with a parallel fire hose for main and a staging environment dedicated to releases, ideally virtual, for example with Docker. With more stakeholders such as QA he adds a human environment that main deploys to on a schedule, while only release branches reach production, and he encourages more identical parallel environments for more types of users. ## Transcript 879 words [\[00:02\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=2s) Next, let's talk about the release branch. Now, what's nice about release branches is that they fit the model where you kind of want a single branch, but you have to deal with multiple releases or whenever you release it's like a big deal, so everybody has to do a code freeze. So, branch release branches are great for that kind of stuff. You see, with release branches, you still have a baseline, a single mainline source branch, and that's where everybody checks in. But whenever you do a release and release has to be tested separately or you have multiple releases that you have to maintain, you just do a branch per big release and then you maintain the last x releases usually just the last two or three so that you kill all branches. [\[00:46\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=46s) But then what's nice is that you you deploy you create a new branch when it's time to do a release and then developers are can just continue to check in source into the main line source control without worrying about breaking the release that's currently being tested in different environments. So this is an example of kind of where we want to go, right? We have a main branch and then we branch it h into release 1.1 and then [\[01:19\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=79s) Release 1.1 source code gets run and tested on tests and staging and production. And that's kind of it seems like that would be a perfect match but in real life it's not as easy because in real life we also have developers on the left that are checking in on code the main branch and then the main branch on the left also runs tests on test and staging and so those environments might actually interfere with each other. the release stakeholders might be waiting and while developers are checking in they might actually break or change the current release and that means that we have to go back and start using again the parallel fire hose idea and in parallel fire hose idea right here we have a main branch for the developers and under it we have a [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") or parallel fire hose mechanism where developers don't care about the existing environments and the [\[02:19\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=139s) Release branches whenever there is a release there are special staging and produ staging environment that's dedicated for releases. So here we'll have I'll just call I uses just call them rail human whatever. So we have a real staging environment and just a production environment and when release 1.1 branch is created then its tests are being run on rail staging. When release 1.2 two is run then its tests are run on rail staging as well and usually especially in the places I've been you don't have two releases happening at the same exact time so it's okay for them to step or even just create a new version or virtualized version of the staging environment [\[03:04\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=184s) To run the tests on but then the developers don't have access they don't they don't care about it they just happily just continue checking code to the main branches now we're not losing feedback here because we do have dev test and dev staging and devstaging and rail staging are basically the same look exactly the same should look exactly the same and I would recommend a virtual environment or using something like docker so that the environments are completely blank or they look exactly the same when the tests are starting and then just recreating the environments. [\[03:42\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=222s) But it can become a bit more difficult than this because we might have even more stakeholders. Here we have the release stakeholders that so they need their own environment here. But we can also have QA and others that also want to check the current environment. So we can have two parallel environments or two parallel branches. So now we have two parallel envir parallel environments to the to the main one. So we have a main branch and we have a parallel fire hose environment, a human environment and a and a release environment here. [\[04:17\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=257s) And the main branch can deploy to dev test and dev staging of course but it also deploys on a schedule to human QA and human analyst whatever it is and those users can actually see the latest fresh cuts from the source even if we don't have a release but when a release when a release is happening release is deployed to rail staging and those same users have as have access to production and rail staging you can only get to production from release branches. is. [\[04:48\]](https://www.youtube.com/watch?v=MJqtHtOsXYo&t=288s) So hopefully that clears up the idea that we can have multiple environments in parallel running and that means virtualization is really our friend here. Don't be afraid of creating multiple environments in parallel that look the same. The more users you have or types of users you have, the more parallel environments you're going to need if you truly want to be dedicated to the idea that continuous delivery can happen and we can get the feedback as quickly as possible in these environments here at the bottom without worrying that we'll interfere with these people's schedules or the release environments. ## Related - [Ephemeral Environments for DevOps: Why, What and How?](https://pipelinedriven.org/article/ephemeral-environment-why-what-how-and-where) · pipelinedriven.org Roy on ephemeral environments that pipeline stages spin up and down, like the virtual staging environment suggested for releases. - [The four biggest issues with having static environments](https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments) · pipelinedriven.org Roy on the problems of shared long-lived environments, the interference between main and releases this lesson avoids. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) [Previous lesson Single Branch](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch/) [Next lesson Single Branch with Feature Flags](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/single-branch-with-feature-flags/) --- ## 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/