Having the build and deployment pipeline as code (PaC) builds on the benefits of having Everything as Code (EaC), e.g. immutable version control, audit trails, peer reviews, textual representation, and knowledge sharing.
Furthermore, allowing the product team to control the pipeline helps to embed professional engineering practices that help the team understand the full journey of their artefact, from dev, build and production deployment.
At a high level, a pipeline consists of three parts, namely: building and testing the artefact, assuring quality, and orchestrating deployment to production.
The build and test stage of the pipeline compiles the code, runs initial tests (e.g. unit tests, linting) and outputs an artefact (or library, module, UI, application, etc) for storage in a repository.
The quality assurance part of the pipeline may run additional processes across the codebase - think security, cyclomatic complexity, bug detection, code coverage metrics, etc.
The final stage is the orchestration of deployment to production (through a number of lower environments - dev, staging, production for example).
The quality assurance stage also runs against each of the environments as the deployment is orchestrated. For example, integration tests are performed in higher environments, with testing being performed against more production-like systems.
PaC provides a point-in-time representation that describes not only the functionality of the deployment artefact (i.e. the actual programming source code), but how it is built and deployed.
This textual representation, when under the control of the product team, resides within the source controlled codebase so that any member of the team (or indeed organisation) can review, comment upon, and improve.
An additional benefit of having PaC is that this drives engineers to think beyond the code that they are writing to the wider context of how this code will be used - both from a pipeline and end-user perspective.
Engineers now have to take into consideration the build and quality controls that go into professionally deploying an artefact into production. This is especially useful when the team is also on support - ensuring that there are no knowledge gaps or dependencies in how the entire application interacts within the organisation’s technical estate.
More knowledge leads to a more rapid turnaround time to fix production issues - as there are no external dependencies to rely upon - and allows the team to integrate additional learnings (extra quality controls, deeper tests) into the pipeline that reduces errors and includes better quality controls.