--- title: "Parallel Firehose" url: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/parallel-firehose.md" canonical: "https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/parallel-firehose/" tags: [] author: "Roy Osherove" description: "Lesson 10 of 17 in Beautiful Builds and Continuous Delivery Patterns (Other Stakeholder patterns), 3:42. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Parallel Firehose 1. [Courses](https://courses.osherove.com/#courses) 2. [Beautiful Builds and Continuous Delivery Patterns](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/) 3. Other Stakeholder patterns Lesson 10 of 17 Duration: 3:42 [Watch on YouTube](https://www.youtube.com/watch?v=o8BeaBjBu28) ## In this lesson Roy Osherove looks at [continuous delivery](https://pipelinedriven.org/article/continuous-delivery-values "Continuous Delivery Values (pipelinedriven.org)") blocked by people: QA uses the test environment between 9 and 5, analysts use staging and customers use production. His answer, the parallel fire hose, is a set of fully automated dev test and dev staging machines that look like test and staging but are not used by people, so code can be deployed to them on every check-in, hundreds of times a day. In the full picture for many components and teams, a build that triggers all tip artifacts feeds a deploy chain to the fire hose and, at the click of a button, to production, plus a stakeholder chain that deploys to the human test and staging environments on a schedule. ## Transcript 561 words [\[00:02\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=2s) Now, we're going to talk about another problem that happens a lot when you try to do [continuous delivery](https://leanpub.com/pipelinedriven "The Holy Grail of Continuous Delivery (pipelinedriven.org)"). 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=38s) 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=74s) 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=111s) 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=143s) 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=177s) 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\]](https://www.youtube.com/watch?v=o8BeaBjBu28&t=208s) 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. ## Related - [The four biggest issues with having static environments](https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments) · pipelinedriven.org Roy on long-lived DEV, STAGE and PROD environments used by different people, and the queues that form waiting for them. - [Human Bottlenecks](https://leanpub.com/pipelinedriven) · pipelinedriven.org Section of Roy's Pipeline Driven book on human bottlenecks, the people-blocked delivery this lesson works around. ### Also linked in this lesson #### pipelinedriven.org - [Continuous Delivery Values](https://pipelinedriven.org/article/continuous-delivery-values) [Previous lesson Deploy by Proxy](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/deploy-by-proxy/) [Next lesson Branching Strategies](https://courses.osherove.com/courses/beautiful-builds-and-continuous-delivery-patterns/branching-strategies/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/