--- title: "Pipeline Disintegration (Post Build Pipeline)" url: "https://pipelinedriven.org/article/2015/3/29/pipeline-disintegration-post-build-pipeline.md" canonical: "https://pipelinedriven.org/article/2015/3/29/pipeline-disintegration-post-build-pipeline" published: "2015-03-29T05:18:33.939000+00:00" updated: "2015-03-29T05:18:32.107000+00:00" tags: [] author: "Roy Osherove" description: "Other Names: Post Build Hand off, Time Capsule, Strangler Application Symptoms: It is very complicated to add features to the current build process, because…" 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/" --- # Pipeline Disintegration (Post Build Pipeline) 29 March 2015 · 2 min read · Roy Osherove [![](https://pipelinedriven.org/img/c/image-asset-861558.png)](https://pipelinedriven.org/img/c/image-asset-861558.png "View full size") ### Other Names: Post Build Hand off, Time Capsule, Strangler Application ## Symptoms: It is very complicated to add features to the current build process, because the current tooling deficiencies, process bureaucracy or the responsible team is reluctant to add those features for their own reasons. ## Problem: The current build process is blocking from adding features required for the business to succeed, such as increasing feedback, adding more information, or adding more actions to ease manual work. Continuing to bang on that specific door might be a Sisyphean task, and spending too much time on it would be very unproductive and ineffective. ## Forces: You'd like to get more feedback sources to the build, but that might interfere with the team's current processes, area of responsibility, or, in regulated environments, even traceability, documentation and workload. You and other stakeholders believe that adding those features will increase feedback, quality or other benefits, but tacking new features on the current build seems to be stepping on everyones toes. ## Solution: Create a new pipeline that receives a _Time Capsule_ from the current build process. This _Time Capsule_ will contain the end artifacts from the build process (usually the "release" binaries and other support files, and possibly all the source code). Now that the time capsule is in your possession, you can put it through a new, separate pipeline that adds the steps that you might care about. Examples might include: - Static code analysis - Running unit tests (if those couldn't be run in the original build) - Deployments ### A more explicit example: 1. Make sure the "old" build copies or "drops" all related artifacts into a shared folder that will be accessible by the new pipeline. This should happen automatically every time the old build runs, which hopefully will be once or more a day. 2. Install an instance of a CI server of some sort (let's say it's TeamCity for the sake of argument), and create a new project for the new pipeline. This will hopefully be on a seperate server so as not to interfere with the old build's require hardware and software resources. 3. The first action as part of the new pipeline will be, instead of using source control, copying the time capsule binaries into the local build agent that will be invoked by the new CI tool during the run. 4. Next steps might then include running unit tests, static code analysis or anything else your heart desires, without interfering with the old build structure. 5. Notify stakeholders if the new pipeline fails. --- ## 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/