---
title: "What is CI?"
date: 2022-01-26T22:58:17-06:00
draft: false
tags:
- ci
- continuous integration
- ansible
- software engineering
- technology
series:
- Ansible CI
---

{{< series "Ansible 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.
