An Operations View on CI/CD
What is CI/CD? In this era of modern development practices, it’s hard to go a whole day without hearing the term “CI/CD”. But what exactly does it mean? And where did it come from? As a DevOps Specialist with over 2 decades of experience, let me paint a picture for you.
In my early days in IT Operations, deployments were a rare, but an important component of the job. About once a month, Development would announce that they had a “new release!” – and consequently, we’d inherit a ton of code we had to get to customers. This would include, new binaries, configurations, scripts for database changes, requests for more VMs, and other ancillary changes. We would spend days understanding how it all fit into the existing infrastructure and how to best deploy. Back then, of course, we also made sure we had everyone’s phone number so we could call them in the middle of the night when the deployment went sideways.
When DevOps came around, we enthusiastically bought into the promise of CI/CD, aka, Continuous Integration / Continuous Deployment. Initially, some Operations folks were left scratching their heads. “Continuous? How does that work? Are we going to be deploying every night?!”. Other Ops folks rejoiced – “automated deployments with testing and rollback?! w00t! w00t!”
Continuous Integration (CI) – Build, Test, Repeat
The truth, of course, lies somewhere in the middle. Continuous Integration starts with Developers. The idea is that every day their code gets committed and built. Then, it gets tested. Automatically, of course. On the surface, it may seem that operations get left out of the loop, however, there needs to be infrastructure available for the builds (i.e. build servers) and infrastructure to test on. This naturally falls to the Operations team. In order to gracefully receive new builds, Development and Operations need to work together. That’s one of the main principles of DevOps.
This isn’t always easy. Developments and Operations teams can often feel like they are speaking a different language – after all their priorities differ. Defining a process that facilitates both of their needs is critical to success. Developers know what their code needs. Be it a specific version of a compiler, a minimum amount of RAM, or even a connection to the database. Operations need deployment requirements with well laid out implementation instructions, so they can plan security and infrastructure needs in preparation for deployment.
Continuous Deployment (CD) – Moving Towards Zero-Touch Deployment
The result of the CI is an object – a binary file, a container, a script, etc. The mission is to pick it up and put it in the right place(s). Continuous Deployment is the Holy Grail for all Operations people. The goal being – once the code has been written and tested, it is put in production with zero-touch. Meaning the collaboration between development and operations results in automated delivery of software and any associated updates and fixes, without anyone lifting a finger. Magic!
A noble aspiration, and of course more difficult to implement without the right tools. While there is much more to explore in terms of how to overcome complexity, integration of tools and simplification of processes, it is clear that CI/CD is being adopted as a way to enable digital transformation to better support business objectives. So, irrespective of whether you consider “DevOps” a culture or a philosophy, we can all align on CI/CD because it is a goal. And goals are much easier to sink your teeth into.
Software delivery is now critical for virtually every organization, even if the process of deploying them can be hampered by mind-numbing complexity. We're on a mission to simplify application delivery. Our goal is to help remove the errors, latency, and outages that result from a sluggish application deployment process - so you can deliver fixes, features, and updates to your customers quickly and securely.