ANÁLISIS DE LOS DATOS

The continuous integration tool is one stage of the pipeline, usually operating before a deployment to the staging systems. You need to be able to trace the generation of microservices throughout the pipeline. The continuous integration server generates an artifact that’ll be deployed into production. Before that happens, the source code for the artifact needs to be marked and tagged to create hermetic artifact generation—you must be able to reproduce any build from the history of your microservice. After artifact generation, you need to be able to trace the deployment of that artifact over your sys- tems from staging to production. This tracing mustn’t be only at the system level, but also within the system, tracing the number of instances run, and when. Until third party tooling solves this problem, you’ll need to build this part of the pipeline diagnostics yourself. It‘s an essential and worthwhile investment for investigating failures.

The unit of deployment is a microservice, and the unit of movement through the pipeline is a microservice. The pipeline should prioritize the focus on the generation and validation of artifacts that represent a microservice. A given version of a microser- vice is instantiated as a fixed artifact that never changes. Artifacts are immutable. The same version of a microservice always generates the same artifact, at a binary encoding level. It’s natural to store these artifacts for quick access1_{. Nonetheless you need to}

retain the capability to hermetically rebuild any version of a microservice, as the build process is an important element of defect investigation.

The development environment also needs to make the focus on individual microservices fluid and natural. This affects the structure of your source code reposi- tories. We’ll look at this more deeply in Chapter 7. Local validation is also important, as the first measure of risk. Once the developer’s satisfied that a viable version of the microservice is ready, it’s the developer that initiates the pipeline to production.

The staging environment reproduces the development environment validation in a controlled environment, keeping it free from the variances in local developer machines. Staging also performs scaling and performance tests, and can use multiple machines to simulate production, to a limited extent. Staging’s core responsibility is to generate an artifact with an estimated failure risk within a defined tolerance.

Production is the live, revenue generating part of the pipeline. Production is updated by accepting an artifact, and a deployment plan, and applying the deploy- ment plan under measurement of risk. To manage risk, the deployment plan is a pro- gressive execution of deployment primitives—activating and deactivating microservice instances. Tooling for production microservices is the most mature at present, as it is the most critical part of the pipeline. A great variety of orchestration and monitoring tools are available to help2_.

5.6.2 Process

It’s important to distinguish continuous delivery from continuous deployment. Con- tinuous deployment is a form of continuous delivery, where commits, though they

may be automatically verified, are still pushed directly and immediately to production. Continuous delivery operates at a coarser grain, where sets of commits are packaged into immutable artifacts. In both cases, deployments can be effectively "real-time" and occur multiple times per day.

Continuous delivery is more suited to the wider context of enterprise software development, as it allows the team to accommodate compliance and process require- ments which are difficult to change within the lifetime of the project. Continuous delivery is also more suited to the microservice architecture, as it allows the focus to be on the microservice rather than code.

If "continuous delivery" is considered a continuous delivery of microservice instances, this understanding drives other virtues. Microservices should be kept small, and that verification, particularly human verification such as code reviews, is possible with the desired time-frames of multiple deployments per day.

5.6.3 Protection

The pipeline protects you from exceeding failure thresholds by providing measures of risk at each stage to production. It isn’t necessary to extract a failure probability pre- diction from each measure1_{. You’’ll know the feel of the measures for your system, and}

you can use a scoring approach effectively.

In development, your key risk measuring tools are code reviews and unit tests. Using modern version control for branch management2 _{means you can adopt a devel-}

opment workflow where new code is written on a branch, and then merged into the mainline. The merge is only performed if the code passes a review. The review can be performed by a peer, rather than a senior. Peer developers on a project have more information and are better able to asses the correctness of a merge. This workflow means that code review is a normal part of the development process, and has low fric- tion. Microservices keep the friction even lower because the units of review are smaller and have less code.

Unit tests are critical to risk measurement. You should take the perspective that unit tests must pass before branches can be merged, or code is committed on the mainline. This keeps the mainline potentially deployable, as a build on staging has a good chance of passing. Unit tests in the microservice world are concerned with dem- onstrating the correctness of the code. The other benefits of unit testing, such as mak- ing refactoring safer, are less relevant.

Unit tests aren’t sufficient for accurate risk measurement, and are subject to dimin- ishing marginal returns. Moving from 50% test coverage to 100% reduces your deployment risk much less than moving from 0% to 50%. Don’t get suckered into the fashion for 100% test coverage. It’s a fine badge of honor (literally!) for Open Source utility components, but is superstitious theater for business logic.

75