DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
Stepping from "crafted" DevOps toolchains to declarative pipelines 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?
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.
