Lesson 14 of 17
Release Branches
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
[00:02] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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 (external link, opens in new tab) or parallel fire hose mechanism where developers don't care about the existing environments and the
[02:19] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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.