More on this book
Community
Kindle Notes & Highlights
by
David Farley
Read between
October 13 - December 20, 2018
A deployment pipeline is, in essence, an automated implementation of your application’s build, deploy, test, and release process.
The aim of the deployment pipeline is threefold. First, it makes every part of the process of building, deploying, testing, and releasing software
visible to everybody involved, aiding collaboration. Second, it improves feedback so that problems are identified, and so resolved, as early in the process as possible. Finally, it enables teams to deploy and release any version of their software to any environment at will through a fully automated process.
The remedy is to integrate the testing, deployment, and release activities into the development process.
All aspects of each of your testing, staging, and production environments, specifically the configuration of any third-party elements of your system, should be applied from version control through an automated process.
A working software application can be usefully decomposed
into four components: executable code, configuration, host environment, and data. If any of them changes, it can lead to a change in the behavior of the application. Therefore we need to keep all four of these components under control and ensure that a change in any one of them is verified.
The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release your application in version control.
If It Hurts, Do It More Frequently, and Bring the Pain Forward
documentation is painful, do it as you develop new features instead of leaving it to the end. Make documentation for a feature part of the definition of done, and automate the process as far as possible.
The whole team should regularly gather together and hold a retrospective on the delivery process. This means that the team should reflect on what has gone well and what has gone badly, and discuss ideas on how to improve things.
Somebody should be nominated to own each idea and ensure that it is acted upon. Then, the next time that the team gathers, they should report back on what happened. This is known as the Deming cycle: plan, do, study, act.
Configuration management refers to the process by which all artifacts relevant to your project, and the relationships
between them, are stored, retrieved, uniquely identified, and modified.
Generally, we consider it bad practice to inject configuration information at build or packaging time.
Treat your application’s configuration the same way you treat your code. Manage it properly, and test it. Here is a list of principles to consider when creating an application configuration system:
When evaluating third-party products and services, start by
asking the following questions: • Can we deploy it? • Can we version its configuration effectively? • How will it fit into our automated deployment strategy?
In this sense, a change to your environment is just like a change to your software. It has to go through your build, deploy, test, and release process in exactly the same way as a change to the application’s code.
Configuration management is the foundation of everything else in this book. It is impossible to do continuous integration, release management, and deployment pipelining without it. It
James Shore describes the simplest way to get started with continuous integration in an article called “Continuous Integration on a Dollar a Day” [bAJpjp] using only an unused development machine, a rubber chicken, and a bell.
Prerequisites for Continuous Integration
Unit tests should run very fast—your whole suite, even for a large application, should be able to run in under ten minutes.
Always Run All Commit Tests Locally before Committing, or Get Your CI Server to Do It for You
We have two book recommendations for further reading on this topic: Steve Freeman and Nat Pryce’s Growing Object-Oriented Software, Guided by Tests, and Gerard Meszaros’ xUnit Test Patterns: Refactoring Test Code.
To work out stories that follow the INVEST principles [ddVMFH] (they should be Independent, Negotiable, Valuable, Estimable, Small, and Testable), with acceptance criteria.
The later stages in the pipeline that perform deployments to manual testing environments need to be activated on demand, which we describe in a later section in this chapter.
In many organizations where automated functional testing is done at all, a common practice is to have a separate team dedicated to the production and maintenance of the test suite. As described at length in Chapter 4, “Implementing a Testing Strategy,” this is a bad idea. The
Acceptance tests written without developer involvement also tend to be tightly coupled to the UI and thus brittle and badly factored, because the testers don’t have any insight into the UI’s underlying design and lack the skills to create abstraction layers or run acceptance tests against a public API.
expressed in the language of the business (what Eric Evans calls the “ubiquitous language”3), not in the language of the technology of the application.
Most importantly of all, avoid environment-specific scripts: Separate environment-specific configuration from the build scripts themselves.
At some organizations, there are teams of specialists who are experts at the creation of effective, modular build pipelines and the management of the environments in which they run. We have both worked in this role. However,
we consider it a failure if we get to the point where only those specialists can maintain the CI system.
In larger or more widely spread teams, this isn’t always easy. Under these circumstances it is useful to have someone to play the role of a “build master.”
There are some important principles and practices governing the design of a commit test suite. The vast majority of your commit tests should be comprised of unit tests, and it is these that we focus on in this section.
The second important property is that they should cover a large proportion of the codebase (around 80% is a good rule of thumb),
Second, UIs are designed to work at human timescales which, compared to computer timescales, are desperately slow.
Acceptance testing relies on the ability to execute automated tests in a production-like environment. However, a vital property of such a test environment is that it is able to successfully support automated testing. Automated
same as user acceptance testing. One of the differences is that automated acceptance tests should not run in an environment that includes integration to all external systems.
Instead, your acceptance testing should be focused on providing a controllable environment in which the...
This highlight has been truncated due to consecutive passage length restrictions.
1. Decide upon an architecture for your application. Pay particular attention to process and network boundaries and I/O in general.
Understand and use patterns and avoid antipatterns that affect the stability and capacity of your system. Michael Nygard’s excellent volume Release It! describes these in detail.
We also introduce two extremely powerful techniques that can be used to perform zero-downtime releases and rollbacks on even the largest of production systems: blue-green deployments and canary releasing.
The People Who Do the Deployment Should Be Involved in Creating the Deployment Process
copies of the environment for
We recommend Scott Ambler and Pramod Sadalage’s excellent book Refactoring Databases, and the accompanying minibook Recipes for Continuous Database Integration, for more detail
used is to autogenerate a list of database objects touched by each application through static analysis of the codebase. This list is generated as part of the build process for every application, and the results are made available to everybody else, so it is easy to work out if you are going to affect somebody else’s application.
If your codebase is already large and monolithic, one way to start decomposing it into components is to use branching by abstraction, as described earlier in this chapter.
Maven: The Definitive Guide written by Sonatype and published by O’Reilly. Meanwhile, we do want to cover some of the basic dependency refactorings you can do in Maven.
It’s worth saying again: You
