--- title: "The first rule of continuous delivery toolchains" url: "https://pipelinedriven.org/article/the-first-rule-of-continuous-delivery-toochains.md" canonical: "https://pipelinedriven.org/article/the-first-rule-of-continuous-delivery-toochains" published: "2017-03-10T17:06:29.643000+00:00" updated: "2017-03-30T17:35:26.408000+00:00" tags: [] author: "Roy Osherove" description: "Continuous delivery transformations are hard enough in many areas already: changing people's behavior, changing policies, architecting things differently -…" 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/" --- # The first rule of continuous delivery toolchains 10 March 2017 · 1 min read · Roy Osherove Continuous delivery transformations are hard enough in many areas already: changing people's behavior, changing policies, architecting things differently - all these things are difficult on their own.   Having a toolchain that prohibits you from achieving your pipelines in a way that fully supports CI/CD is something you can try to avoid off the bat.  The simple rule is: ## Don't select your toolchain before you've designed the pipeline you wish to have Don't decide you're going to use a specific tool for the new way of working before you've done at least the following: - Choose a project in your organization that exemplifies an "average" project (if there are many types choose two or three). - Do a [value stream mapping](https://en.wikipedia.org/wiki/Value_stream_mapping#In_software_engineering) of that project from conception to cash  - from the point of an idea, to that getting into a backlog, to that code ending up in production. Then Time the value stream and see how long each step takes. - Once you have a value stream, design a conceptual pipeline that tries to automate as much of the value stream as possible (some things will not be able to be automated without the change of organizational policies) Now that you have  conceptual pipeline (or several), you can start deciding which tools fit best for the actions you would like to pull off in the pipeline. What you'll find is that some tools will not lend themselves easily into the pipeline work, and some tools will fit in just right. ## Remember: the pipeline drives the tool selection. Not the other way around. You should not let the tool dictate how your pipeline works because you're trying to change the way the organization works, not map the organization to a tool that might hider your progress. --- ## 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/