Lesson 12 of 17
Branch per Promotion
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
[00:03] (external link, opens in new tab) 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] (external link, opens in new tab) 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 (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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.