While decompressing Friday afternoon at our weekly office happy hour, I naturally joined in a conversation about deploying a new technology experiment into staging and production phases.The conversation was rife with references to days of yore when the deployment process was a day’s long task that included logging into servers, manually updating them, and repeating the process carefully such that there wasn’t an outage.
It reminded me that every engineer has at least one good deployment battle story. One story that comes to mind is where the engineers were deep in the trenches with a technical problem that occurred right at the finish line. The entire team was scrambling to get a fix in or suffer the consequences of having an outage.
At Itential, we’re particularly sensitive to these types of situations due to the nature of the system we work with. Downtime and outages are not passive factors for us. Our products help teams work effectively, both in normal course but also in times of immense duress. The method applied to these situations is systematic automation. Automation is reproducible, programmatic, and consistent. If the process fails, it’s easy to look at every step along the way and assess. The counterpart to this is manual changes which are, of course, prone to error, misjudgment, or randomness.
So, when the Itential DevOps team sat down to develop a method for building, testing, and deploying our software, we decided to dogfood our own principals of systematic automation and build a robust, automated CI/CD (Continuous Integration/Continuous Delivery/Deployment) workflow.
What is CI/CD?
Continuous Integration (CI) is defined as the continual flow of changes into a centralized code repository. CI includes the workflows or “pipelines” associated with automated building and testing.
CI/CD as concepts typically defines itself in two ways:
- Continuous integration with Continuous Delivery – Continuous Delivery builds upon this continual flow of changes into a repository that adds the ability to “have a human push the button” before going to production.
- Continuous Integration with Continuous Deployment – Continuous Deployment acts the same as Continuous Delivery, however, it replaces the human button push with an automated process
Here at Itential, we have projects of both ilk. Our Adapter Builder is continuously deploying after it runs through the continuous integration pipeline. Roughly speaking, there are anywhere from 1-6 deployments to production throughout the day. That might not seem like a significant amount for an application that is the CI/CD lifecycle, however, the team is < 5 people adding changes in their spare time.
Our documentation site is also a continuous deployment application that takes it one step further by dynamically generating its own content before deployment. It deploys on a specific cadence attuned to how often the documentation is updated.
Our developer site is under the continuous delivery umbrella where one of our engineers will give it a quick once over with the design team to ensure that everything stays on brand and functional.
For our core product, Itential Automation Platform, we also use continuous integration with continuous delivery tuned to a longer running release cycle.
Why CI/CD (as a methodology) at Itential?
Beyond the simple answer of automation is what we at Itential do, it comes down to one thing:
Feedback loops.
There’s one underlying theme to software development that’s often overlooked; namely, that everything is a test. To clarify, there is no certainty that a feature as it has been designed and implemented is going to successfully appease the user. Even well-documented, specification-based features often meet their demise once they’re in use by the user. It naturally follows then, that you’d want to put as many small changes as possible in front of the user, as quickly as possible with the ability to continue iterating to ensure success (or, at least, ward off disappointment).
It’s on this principle that the entire software development process needs to be oriented. Hence, the need for CI/CD. Continual, risk-averse changes followed by a well-understood set of automated tests deployed to production with minimal human interaction helps to limit the possibility of deploying a disappointing piece of software, and letting it sit in production for months on end until some arbitrary time allows for the “next release.”
Making the Case for Continuous Integration and Deployment
This can all be summed up by “Feedback Loops”. At every level of the software development process, teams need smaller feedback loops. The faster a product manager can get feedback about their new feature, the faster they can start iterating on its improvements. The faster a developer can get feedback on their newly implemented code, the faster she can go into bug fixing, performance improving, or the next feature. This is what CI/CD does at its core. It shortens the feedback loops for time, effort, cost, and repeatability.
There is no perfect feature in software; only what was before, what is now, and what is next. It’s because of this, that time is a crucial part of the development process. The more of it that is expended during the process, the longer feedback loops become, and the less efficient the team is overall.
CI/CD methodologies minimize time originally allotted to perform operational tasks and give it back to the feature development process.
Tags: CI/CD
Itential
Company ‐ Itential
Itential is the only automation platform built to support both network and cloud, making it easy for enterprise organizations to maintain network compliance, reduce manual operations, and simplify network management. The Itential Automation Platform is a low-code cloud-native SaaS solution that seamlessly connects IT systems with network technologies for end-to-end network configuration, compliance, and automation.