Single Branch

[00:03] (external link, opens in new tab) Okay, let's talk about single trunk or no branching strategy (external link, opens in new tab). Basically, no branches, right? Your life is a big nice single branch. So, you want to deploy, you just deploy everywhere. And in a way, a single branch development strategy is the ultimate the perfect match for continuous delivery (external link, opens in new tab) because there's nothing that's stopping you from deploying to staging or even production. Or you can if you want to and you have permission to you can automate deployment everywhere to as far as you need to all the way to the customer because you don't have to wait for humans on the way.

[00:42] (external link, opens in new tab) So there's no branching that's currently needed. Now this is not always true, right? you have a main but sometimes you might want to actually label or tag whenever you have a release and sometimes your organization wants to create multiple releases. So in that case release branches might be needed. But if you don't need that if you don't need release branches because you only have a single release and you're working in a small team then there is no sense in creating new branches at all.

[01:15] (external link, opens in new tab) You can just work on the single branch and just label every release. And of course, you're going to ask, well, what happens if I have a feature that's not done yet? I don't want to merge it back in. It will break the current feature. And this is what feature toggles (external link, opens in new tab) are for. And we'll talk about them in a separate video. But assuming that you could actually solve this problem, then a single branch that just deploys everywhere is the is the thing that you can automate in the easiest way. And it's kind of the perfect match.

[01:46] (external link, opens in new tab) And of course it also means that that you can deploy multiple times a day and you can also make things a bit dirtier multiple times a day. So you can actually break staging multiple times a day etc. And that's either good or bad depending on if you have current if you currently have users or not because if your project is in a very very early stage nobody cares yet about staging or production. You can just deploy to these empty environments and nobody cares. But if your project already has users, it has or maybe there's a QA department just waiting to get their hands on staging or they're using staging between 9 to5 or anything like that then we have to move to a different strategy which we talked about before and that is the parallel fire hose.

[02:28] (external link, opens in new tab) So here you can see that we have QA and analysts and they're using production we have users. So now we still have a single branch but we have at the bottom we have a parallel fire hose. So we have a parallel environment for development and and it's fully automated and we have a human test and human staging that gets deployed to maybe on a schedule and then deployed to production which can get deployed on a schedule. But at least we get the feedback as close to the customer as possible in something that looks like staging

[03:03] (external link, opens in new tab) Multiple times a day. And we don't care because we we will not break the user's environment because we have our own environment. And we'll only deploy to the users once or twice a day whenever they need to. Or they can just pull a button, click a button, and pull the latest stable version when they choose to. Either way, life is much easier because there's no no merging involved and if we want to, we can get feedback as close as possible. U the only thing is that now we might need humans to say yes, it's okay to deploy to production, but it's still less

[03:38] (external link, opens in new tab) Troublesome than also waiting for merges, etc.