What is pipeline as code?

With pipeline as code, teams can configure builds, tests, and deployment in code that is trackable and stored in a centralized source repository. Teams can use a declarative YAML approach or a vendor-specific programming language, such as Jenkins and Groovy, but the premise remains the same.

A pipeline as code file specifies the stages, jobs, and actions for a pipeline to perform. Because the file is versioned, changes in pipeline code can be tested in branches with the corresponding application release.

The pipeline as code model of creating continuous integration pipelines is an industry best practice, but deployment pipelines used to be created very differently.

Early in continuous integration, deployment pipelines were set up as point-and-click or through a graphical user interface (GUI). This presented several challenges:

• Auditing was limited to what was already built-in

• Developers were unable to collaborate

• Troubleshooting problems was difficult

• Difficult to rollback changes to the last known configuration

• Pipelines prone to breaking

What are the benefits of pipeline as code?

The pipeline as code model corrected many of these pain points and offered the flexibility teams needed to execute efficiently.

Pipeline as code comes with many of the same benefits the other "as code" models have, such as:

• Version control: Changes are trackable and teams can rollback to previous configurations.

• Audit trails: Developers can see when changes were made to the source code and why.

• Ease of collaboration: Code is available and visible for improvements, suggestions, and updates.

• Knowledge sharing: Developers can share best practices, import templates, and link code snippets so teams can learn from each other.

Pipeline as code also has operational and practical benefits:

1. CI pipelines and application code are stored in the same source repository. All the information teams need is located in the same place.

2. Developers can make changes without additional permissions and can work in the tools they’re already using.

3. Teams can collaborate more efficiently. Keeping information accessible means teams can collaborate and then act on their decisions.

4. Pipeline changes go through a code review process, avoiding any break in the pipeline integration.

5. Deployment pipelines are in a version control system independent of continuous integration tools. Pipelines can be restored if the continuous integration system goes down. If a team wants to switch CI tools later on, pipelines can be moved into a new system.

The pipeline as code model creates automated processes that help developers build applications more efficiently. Having everything documented in a source repository allows for greater visibility and collaboration so that everyone can continually improve processes.

Get started with CI/CD