Parallel Firehose

[00:02] (external link, opens in new tab) Now, we're going to talk about another problem that happens a lot when you try to do continuous delivery (external link, opens in new tab). And that is people, human beings. You know them, right? They're everything that's not a machine. You see, you want to do this. You want to deploy from test to staging to production. But, you know, you can't really run all the tests because the QA folks needed the test environment between 9 and five and you don't want to burden the CPUs of the machines. You want a staging environment but the business analyst or someone like that is using the staging environment and of course you don't want to deploy to production because the customers are using production.

[00:38] (external link, opens in new tab) So you can't really do continuous delivery in this situation. So one way to avoid this is to just think in parallel. what if we had an environment that we can just automate at will and we won't bother all these people and that's what we did in several se several projects that I was in. You see we created parallel and we I call it a parallel fire hose because in the parallel fire hose machines everything would be automated. It's like drinking from the fire hose. There would be many releases basically on every every check-in of the code.

[01:14] (external link, opens in new tab) There would be many releases between to dev test and to dev staging and no one is supposed to be using these parallel machines. They look exactly like test and staging but they are not burdened by the use of humans. So we can run continuously towards them and deploy at least if we don't have access to production between 9 to 5. We can at least deploy to dev staging hundreds of times a day if we need to. And then we would have automatic scheduling between dev test and the human test environment.

[01:51] (external link, opens in new tab) So it kind of looks like this. You see we would auto deploy from dev test to dev staging and between dev test like every day we would deploy to test environment staging environment from dev staging etc. And we could by the press of a button deploy between devstaging and production environment and this would be the fire hose environment. It's fully automated. Now if we look at the big picture, this is basically what we we had.

[02:23] (external link, opens in new tab) We had on the left you can see the small build configurations. There are API dependencies and there are tip dependencies and there is a snapshot dependency between all of these and the special a special build configuration called trigger everything or all tip artifacts. And in this build, this is the master resource. From this build, we would have two extra chains in in TeamCity in our case.

[02:57] (external link, opens in new tab) We would have deploy chain that would use those artifacts and deploy to the fully automated fire hose at the bottom and also with a click of a button to the production environment. And here we would have a stakeholder chain that would automatically deploy based on a schedule once a day or in the morning and in the evening. Would deploy to test and the staging environment. So that's the fully

[03:28] (external link, opens in new tab) Full overview of the picture of what something might look like with all the dependencies hooked up together for a project with multiple components, multiple teams.