Most operations shops are well down the road to highly automated configuration and provisioning systems. Sometimes this transformation is part of a DevOps transformation, and other times it's because it's the best way to manage change in the environment.
These systems are very good at creating system artifacts that fit our needs, but issues still arise the first time a development team deploys an application to the node. Problems aren't caught until a human gets involved, and troubleshooting is a long, manual process involving checklists and ad-hoc fixes. How do we smooth that rocky road where operations and development artifacts meet?
Enter CI/CD
Continuous integration and delivery (CI/CD) has been a watchword in IT shops for years, but primarily as a development process. CI is about the automation of testing for changes made to the code and to prevent changes introduced to the codebase from breaking the application. CD is about making sure that any final artifacts are suitable for use in a production environment. Any application build that makes it through integration tests can be identified for easy deployment.
From an operations point of view, our "application" is a fit for a server or a container. Our "code" is the individual automation snippets that do actions. Our "build" is the blueprint for stringing those snippets together to get a working system. All changes to an automation script or file should be tested to ensure they don't cause problems.
Think of the tests of your automation like bench[1] or smoke[2] tests. Most automation doesn't consist of one big blob of code for each system. Rather, we've adopted other patterns, like "don't repeat yourself" (DRY) to build reusable chunks of automation that we can recombine