Automated Deployments

Designing for easy deployment

Our goal in this chapter is to learn how we need to design our applications so that they’re easy to deploy. This section describes the deployment tools themselves to give us a baseline for understanding the design forces they impose. This overview won’t be enough for us to pick up Chef and start writing deployment recipes, but it will put Chef and tools like it into context so we know what to do with our ingredients.

Build pipeline

The first tool of interest is the build pipeline. It picks up after someone commits a change to version control. Some teams like to build every commit to master; others require a particular tag to trigger a build. In some ways, the build pipeline is an overgrown continuous integration (CI) server.

The pipeline spans both development and operations activities. It starts exactly like CI with steps that cover development concerns like unit tests, static code analysis, and compilation. See the figure that follows. Where CI would stop after publishing a test report and an archive, the build pipeline goes on to run a series of steps that culminate in a production deployment. This includes steps to deploy code into a trial environment (either real or virtual, maybe a brand-new virtual environment), run migration scripts, and perform integration tests.

We call it a build pipeline, but it’s more like a build funnel. Each stage of a build pipeline is looking for reasons to reject the build. Tests failed? Reject it. Lint complains? Reject it. Build fails integration tests in staging? Reject it. Finished archive smells funny? Reject it. This figure lumps steps together for clarity. In a real pipeline, we’ll probably have a larger number of smaller steps. For example, “deploy trial” will usually encompass the preparation, rollout, and cleanup phases that we’ll see later in this chapter.

Tools for making build pipeline

There are some popular products for making build pipelines. Jenkins is probably the most commonly used today $^{1}$ ...