What does God’s Steady Integration and Deployment Pipeline seem like, and what does this inform us?
Let’s think about God develops software program. They’d write some code, and commit it to an immaculate GIT repo. What kind of CI/CD pipeline would God use?
God is omniscient, all-powerful, and in any other case infallible. God doesn’t make errors. Or within the case of software program growth, God doesn’t write bugs.
Does God want static code evaluation? No, God’s code is gorgeous, well-formatted, and adheres completely with all type tips and greatest practices.
Does God want unit exams? Nicely, if we assume that God will ever be the one individual modifying this code, and assuming they’ve excellent reminiscence of what they hath written — then we will ignore the documentation worth of unit exams and say that nope, God doesn’t want unit exams.
What different steps in a pipeline does God’s code have to cross earlier than being prepared for manufacturing? Safety checks? Automated integration exams? Compliance verification? Usability testing?
None. God’s code is prepared for manufacturing the moment the final keystroke clicks into God’s keyboard. God’s code begins existence with 100% confidence, and no quantity of verification in any space, dimension, or purview is critical. God’s code is divine.
Thus, God has no want for validation in a CI/CD pipeline. God commits their code, builds no matter artifact that code represents, and might push that artifact straight and instantly to manufacturing. God solely makes use of some type of easy build-deploy pipeline, as a result of God’s code is production-ready from the second of conception.
I hope this small little bit of blasphemy helps talk a important level about CI/CD pipelines:
A lot (most?) of CI/CD pipelines exist as a result of not like God, our code is suspect. Our code wants validation, and the meat of CI/CD pipelines exists due to this.
Some from the infrastructure or DevOps persuasion would possibly chortle on this assertion. What about pulling the build-time configuration? Dependency administration? Asset assortment and artifact distribution?
Sure, all these are a part of ‘pipelines’. Constructing and deploying belongings is non-validation, but when we might assume excellent code, our build-deploy pipeline could be extremely easy; the complexity of contemporary CI/CD pipelines is because of the insecurity in our code. Constructing and deploying excellent code, like God, would truly be a quite simple kind of pipeline to create.
Beneath is a well-known ebook about CI/CD pipelines. In actual fact, many take into account it the bible (HA!) of CI/CD. This ebook is, at its core, a ebook about testing. It’s about find out how to create and arrange the equipment to take suspect, low-confidence code and transfer it by way of the mandatory steps, as successfully and effectively as attainable, till it is able to deploy into manufacturing.
Do a Google Image Search for CI/CD pipeline diagrams and attempt to discover steps that aren’t associated to or help high quality or testing. I’ve discovered only a few, and I’m on outcomes web page 7 (a spot I not often go).
This view of CI/CD pipelines as methods that help and allow the method of code validation isn’t semantic or an idle thought experiment — it reinforces that pipelines should be constructed to service the wants of validation and people performing it: builders, testers, operations, and so on. These are the shoppers of CI/CD pipelines and with out continued funding and upkeep of a wholesome pipeline, their jobs might be extremely troublesome, if not unimaginable.
In actual fact, we will scale back CI/CD pipelines to a collection of steps that incrementally will increase our confidence in code till we’re prepared for manufacturing deployment, as illustrated on this extremely simplified diagram:
Whereas this can be a very quality-centric view, one thing you would possibly anticipate from a Director of High quality Engineering, I do really feel it greatest describes the raison d’etre of CI/CD: CI/CD pipelines exist to help validation, and all the opposite stuff is simply filler.
Whereas we who construct software program typically suppose very extremely of ourselves, put us side-by-side with God and fallibility turns into obvious, and our want for testing and checks turns into apparent:
God doesn’t by chance combine tabs and areas or open brackets on the improper line, we do, so we’d like linting and static evaluation instruments.
God’s courses and capabilities don’t fail with sure enter values or throw surprising exceptions, ours do, so we’d like complete unit exams.
God doesn’t write an exponential algorithm when a linear-time implementation is feasible or doesn’t by chance question an unbounded desk on a non-indexed column. We typically do, and so we’d like stress, load, soak, resilience, and different varieties of efficiency exams, and environments accessible to carry out them on.
God’s interpretation of His Acceptance Standards doesn’t undergo from the imprecision and ambiguity of human language. Ours does, so we’d like part, integration, person acceptance, and all kinds of different testing to validate this, and once more, the suitable environments deployed to carry out them on.
God doesn’t want telemetry knowledge to inform Him if His code is working in manufacturing as a result of it’s excellent. Our isn’t, so we’d like observability constructed into our methods and locations to check these knowledge pathways and capabilities.
God pushes to manufacturing on Friday at 5 pm with out working any exams, and skips away with no fear, as a result of His code is ideal, all the time and without end.
Our code is suspect and must be assumed to be improper till it’s run by way of a well-designed CI/CD pipeline with steps to validate each attainable, conceivable approach it might fail.
God doesn’t use CI/CD pipelines, we completely should.