Branching Strategies

[00:02] (external link, opens in new tab) Okay, let's talk a little bit about branching strategies (external link, opens in new tab) for continuous delivery (external link, opens in new tab). 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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] (external link, opens in new tab) 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.