79 lines
4.3 KiB
Markdown
79 lines
4.3 KiB
Markdown
---
|
|
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.
|