What is CI?
At work I have been doing CI for nearly 10 years, now. Having been working at Red Hat for the past 6 of those, some of the CI work that I do is available in open source contributions up on Git Hub. I plan to make a series of posts about that work, so I am going to start with this brief discussion of the very idea of CI before I get into working on the particular types of CI that I do.
CI is Not Automation
OK, maybe I should go into a little bit more detail. CI is not automation. At it’s core, CI does not imply anything more than the two words in its name suggest. It is Continuous, and it is Integration. The “Continuous” part means that every step is integrated. Every branch as it comes into your version control gets integrated. Strictly speaking, every commit should be integrated, but as engineers we are willing to bend the rules and say that the integration needs to happen at the tip of a branch or a pull request. If you opt to squash merge a PR in git, then you can maintain that full coverage on your main branch.
The second component of Continuous Integration is obvious the Integration portion. After we establish that every piece of the repository is integrated we need to discuss what the integration portion is. Integration comprises building candidate artifacts, testing, linting, reviewing, and preparing a candidate build for potential deployment.
What you will notice is that, nowhere in the definition of Continuous Integration is it made mandatory that any or all portions be automated. It is perfectly acceptable to practice CI without any automation whatsoever. It might not be acceptable to someone holding the purse strings, but there is no technical reason you cannot run the process manually and still call it Continuous Integration. The only milestones you must hit to be considered CI is 1) Continuous and 2) Integration.
CI is Not Pushing Every Build
That idea really falls under the umbrella of Continuous Deployment. Continuous Deployment itself is a companion idea to CI, but it is followed by every successful integration being deployed. Very few companies, projects, etc want to follow a strict Continuous Deployment strategy. However, one of the excellent benefits that CI gives is the ability to either utilize CD or at least be always ready to deploy the latest artifacts should the need or desire arise.
CI is, in fact, attempting to be the backstop that allows a fast moving project to avoid breaking things as often as they otherwise might. If every candidate has been thoroughly vetted and is already prepared for deployment, then a project can employ a fast moving delivery schedule or a delivery-as-needed schedule with its confidence maximized by the process.
Obviously, your confidence in your deployments can only be as good as your confidence in your verification process. If your project truly employes CI and is still seeing a high rate of failures on delivery, then your verification process could proably benefit from some improvements. One of the benefits of CI is that it can be a part of a rapid feedback cycle that improves the quality of processes - both of the software itself and of the validation process that a product undergoes.
But what about automation…
Although CI does not demand automation, the names of the two have become nearly synonymous, as process and product complexity can rapidly grow beyond the abilities of manual testing, build, delivery, and other types of teams. This is where automation begins to earn its keep. A good build server configuration can produce artifacts far more quickly than waiting for manual builds to complete. A proper lint tool can find, report, and even fix problems far more quickly than a manual reviewer. A code formatting tool can produce standards-conformant code much more efficiently than a codebase audit can do. And, of course, a properly written set of automated tests can improve the confidence in a potential release artifact. Well written automation can find large numbers of defects much more rapidly than manual testing and can allow the goal of truly continuous integration to be achieved much more readily.