<p><strong>Pipeline as Code (PaC)</strong> means that the CI/CD configuration will be stored in the VCS instead of in the CI/CD tool itself, e.g. configuring it manually by using a UI.</p>

<blockquote>
  <p>Any experiences what can be the "critical mass" where this investment
  is a clear pay-off and not an overkill?</p>
</blockquote>

<p>Imagine that more than 100 jobs have been configured manually the last couple of years and one would like to transform all these jobs to PaC then it would mean that less resources will be available to create new features and therefor not advisable, but if one would create tasks to address this and transform a manual job to a PaC one every sprint then it could be beneficial in the long run.</p>

<p><strong>Advantages of PaC</strong> </p>

<p><em>No endless searching for configuration anymore</em></p>

<p>One advantage is that one does not have to look in various places, e.g. CI/CD tool, documentation how a CI/CD job has been configured as the relevant stuff resides in the same place as the code, i.e. VCS. </p>

<p><em>No endless and unnecessary debugging anymore</em></p>

<p>Another advantage is that someone cannot break the CI/CD job easily like it is possible when it is configured using a UI. If for example someone has to change the CI/CD could then one has to change the code in the VCS. As every code change could be tracked, it will be immediately clear who changed the pipeline and what was changed when a pipeline is broken.</p>

CC BY-SA 3.0
2017-12-10T12:58:22.647Z
2017-12-10T12:58:22.647Z
030
<p>Stepping from "crafted" DevOps toolchains to <a href="https://www.thoughtworks.com/radar/techniques/pipelines-as-code" rel="nofollow noreferrer">declarative pipelines</a> is imo next transformation step towards even more productivity which requires additional effort.</p>

<p>Any experiences what can be the "critical mass" where this investment is a clear pay-off and not an overkill?</p>

<continuous-integration><build-pipeline><methodology>
What are formal criteria for establishing declarative pipelines, or pipelines as a code?
Ta Mu
# What are formal criteria for establishing declarative pipelines, or pipelines as a code?

(Asked by: username_0 on 2017-06-09)

Stepping from "crafted" DevOps toolchains to [declarative pipelines](https://www.thoughtworks.com/radar/techniques/pipelines-as-code) is imo next transformation step towards even more productivity which requires additional effort.

Any experiences what can be the "critical mass" where this investment is a clear pay-off and not an overkill?

**Tags:** continuous-integration, build-pipeline, methodology


---

## 1 answers

### Answer by username_1 on 2017-12-10. Score: 2

**Pipeline as Code (PaC)** means that the CI/CD configuration will be stored in the VCS instead of in the CI/CD tool itself, e.g. configuring it manually by using a UI.

> Any experiences what can be the "critical mass" where this investment
> is a clear pay-off and not an overkill?

Imagine that more than 100 jobs have been configured manually the last couple of years and one would like to transform all these jobs to PaC then it would mean that less resources will be available to create new features and therefor not advisable, but if one would create tasks to address this and transform a manual job to a PaC one every sprint then it could be beneficial in the long run.

**Advantages of PaC**

*No endless searching for configuration anymore*

One advantage is that one does not have to look in various places, e.g. CI/CD tool, documentation how a CI/CD job has been configured as the relevant stuff resides in the same place as the code, i.e. VCS.

*No endless and unnecessary debugging anymore*

Another advantage is that someone cannot break the CI/CD job easily like it is possible when it is configured using a UI. If for example someone has to change the CI/CD could then one has to change the code in the VCS. As every code change could be tracked, it will be immediately clear who changed the pipeline and what was changed when a pipeline is broken.


---

