Pipeline Disintegration (Post Build Pipeline)

Other Names:

Post Build Hand off, Time Capsule, Strangler Application


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.


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.


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.


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.