Introduction

Ansible lifts a huge operational burden. So much so, in fact, that the friction of build and release go unnoticed. In contrast to manual configuration, entering a few keystrokes to run Ansible is a godsend. With frequency, however, that novelty diminishes. And your next constraint becomes velocity.

To achieve a higher velocity, human interaction has to be removed. However, velocity isn’t just about speed. It does little good to go fast if the system is unreliable or unsafe. So, automated testing also becomes part of the process. The answer is well-defined by a release pipeline model. The release pipeline has four stages:

• source
• build
• testing
• release

Source

You already have the first stage in place. Storing your Ansible code in a Git repository checks that box. Using source control provides a single path for changes. It answers the following questions:

• Who changed the environment?
• What did they change?
• When did the change occur?

Build

The next stage is build. Build runs scripts when changes are checked in. Within this stage, you define tasks that help catch problems at the earliest stage and set up notifications for the pipeline problems.

Testing

Testing is another step in the build process. Build and testing are both a part of continuous integration (CI). Broadly speaking, there are three types of tests:

• Lint
• Unit
• Integration

Linting verifies syntax and enforces coding standards. Unit tests validate that the code’s logic is sound, while integration tests validate expectations by running against real components.

Release

The release is the final stage. It takes the Run button away. The release is responsible for deploying code to production. And all the other environments you have to maintain.

Start simple. Start small. It takes time to mature this process.

Destroyed Infrastructure
In case you deleted the Ansible development environment, make sure to re-deploy the infrastructure for AWS and Azure by following the links.