Continues Integration (and yes I mean Jenkins) is awesome, plain and simple. CI provides a way for developers to continuously integrate, test and give a degree of confidence that it will work with in other environment(s) to ensure stability. If this tool is so great why aren’t sys admins using it as well? Shouldn’t sys admins test their code, measure code coverage, integrate with other sys admins configs and finally ensuring it will work across environments?
If your a sys admin I know what you’re thinking.. I do test my code and I do ensure it works in our environments. And you’re probably also thinking, Why use a CI tool? What is the point if we’re just writing scripts and doing system configurations?
That’s the point, it isn’t just some script that is written once and forgotten about. Generally the scripts sys admins write are the backbone of any organization and are tucked away in a file system somewhere. It is possible some testing was performed when the script was written, but things change and unless those tests are continuously be run when the script is applied again there is no sure way of knowing something is broken.
Step in CI server. What does this get us? Well, let me make the assumption, silly as it may be, that all of the IT operations scripts are under source control (I know, I know, not a safe assumption, but I want this as another blog post down the road). With that assumption in place, now lets assume the Ops team has also built some basic unit testing around what their script will do. After that we set up a job that will constantly poll our scripts for any changes and should a change occur our tests will run against the script verifying everything still works as expected.
What does this get the Ops team? Now anytime anybody updates the script, known tests are run to verify everything still works as expected and the entire team is notified the status of the script. There is now stability, repeatability, and an overall confidence in a companies infrastructure.
For those of us who hate writing documentation. Having this CI/CD process for scripts also acts as a living document. IT organizations can leverage it also as repository for intellectual capital. Yes, not all the code will live on the Jenkins server, but in an ideal scenario all scripts will be tested there having 1 place for everybody to review the health and assets for the IT Ops team.
Short story long. There is a movement to get more automation, rigor and confidence around doing IT Ops and the only way to get there is by writing good code, which implies good testing. This will help with less rework, unnecessary troubleshooting, loss of intellectual artifacts and allow the team to focus on more interesting things rather than trying to figure out what you did a year ago and why the script is no longer working.
Get in the habit of using CI/CD you and your IT organization will not regret it.