- 1.1 Introduction: What Is Continuous Delivery?
- 1.2 Why Software Releases are So Complicated
- 1.3 Values of Continuous Delivery
- 1.4 Benefits of Continuous Delivery
- 1.5 Generations and Structure of a Continuous Delivery Pipeline
- 1.6 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 Generations and Structure of a Continuous Delivery Pipeline
As already mentioned, Continuous Delivery extends the approach of Continuous Integration to additional phases. Figure 1.3 offers an overview of the phases.
)
Figure 1.3 Phases of a Continuous Delivery pipeline
This section introduces the structure of a Continuous Delivery environment. It is oriented along Humble et al. (see footnote 1) and consists of the following phases:
The commit phase comprises the activities that are typically covered by a Continuous Integration infrastructure such as the build process, unit tests, and static code analysis. Chapter 3 discusses this part of the pipeline in detail.
Chapter 4, “Acceptance Tests.” Strictly speaking, the topic is automated tests: Either the interactions with the GUI are automated to test the system or the requirements are described in natural language in a manner that allows them to be used as automated tests. From this phase on, if not before it is necessary to generate environments on which the applications can run. Therefore, Chapter 2, “Providing Infrastructure,” deals with the question of how such environments can be generated.
Capacity tests (Chapter 5, “Capacity Tests”) ensure that the software can cope with the expected load. For this purpose an automated test should be used that unambiguously indicates whether the software is sufficiently fast. The relevant point is not only performance, but also scalability. Therefore, the test can also take place in an environment that does not correspond to the production environment. However, the environment has to be able to deliver reliable results about the behavior in production. Depending on the concrete use case other non-functional requirements, such as security, can also be tested in an automated fashion.
During explorative tests (Chapter 6, “Exploratory Testing”) the application is not examined based on a strict test plan. Instead, domain experts test the application with a focus on new features and unanticipated behaviors. Thus, even in Continuous Delivery not all tests have to be automated. In fact, by having a large number of automated tests, capacity is freed for explorative testing since routine tests do not have to be manually worked off anymore.
The deployment into production (Chapter 7, “Deploy—The Rollout in Production”) merely comprises the installation of the application in another environment and is therefore relatively low risk. There are different approaches to further minimize the risks associated with the introduction into production.
During operation of the application, challenges arise—especially in the areas of monitoring and surveillance of log files. These challenges are discussed in Chapter 8, “Operations.”
In principle, releases are promoted into the individual phases. It is conceivable that a release manages to reach the acceptance test phase and successfully passes the tests there, but shows too low a performance during the capacity tests. In such a case the release is never going to be promoted into the following phases, like explorative testing or production. In this manner, the software has to show that it fulfills increasing requirements before it finally goes into production.
Let us assume for example that the software contains an error in the logic. Such an error would at the latest be discovered during the acceptance tests, since those check the correct implementation of the application. As a consequence, the pipeline would be broken off (Figure 1.4). Additional tests are not needed anymore at this point.
){kind=link}
Figure 1.4 Continuous Delivery pipeline stops at acceptance tests
The developers will then fix the error, and the software is built anew. This time it also passes the acceptance test. However, there is still an error in a new function for which there is no automated acceptance test. This error can only be discovered during the explorative tests. Consequently, this time the pipeline is interrupted at the explorative tests, and the software does not go into production (Figure 1.5). This prevents testers wasting time with software that does not fulfill the requirements with regards to load handling, or that contains errors that can be detected by automated tests.
)
Figure 1.5 Continuous Delivery pipeline stops at explorative tests
In principle, several releases can be processed in the pipeline in parallel. Of course this requires that the pipeline support multiple releases in parallel—if the tests are running in fixed environments, this is not possible since the environment will be occupied by a test so that a parallel test of a second release cannot run at the same time.
However, it is very rare that releases are processed in parallel by Continuous Delivery. A project should have exactly one state in the version administration, which is then promoted through the pipeline. At the most it might happen that modifications to the software occur with such a speed that a new release is already sent into the pipeline before the previous release has left the pipeline. Maybe there are exceptions for hotfixes—but one objective of Continuous Delivery is just to treat all releases equally.
1.5.1 The Example
section P.2). This example is intentionally kept very simple concerning the domain logic. Essentially the first name, name, and email address of a customer are registered. The registrations are validated. The email address has to be syntactically correct, and there is only one registration allowed per email address. In addition, a registration can be searched based on the email address, and can be deleted.
Since the application is not very complex, it is relatively easy to understand so that the reader can concentrate on the different aspects of Continuous Delivery that are illustrated by the example application.
Technically the application is implemented with Java and the framework Spring Boot. This makes it possible to start the application, including web interface, without installing a web or application server. Thus the testing becomes easier since no infrastructure has to be installed. However, the application can also be run in an application or web server like Apache Tomcat if that is necessary. The data are stored in HSQLDB. This is an in-memory database that runs inside the Java process. This measure also reduces the technical complexity of the application.
The source code of the example can be downloaded at http://github.com/ewolff/user-registration-V2. An important note: The example code contains services that run under root rights and can be accessed via the net. This is not acceptable for production environments because of the resulting security problems. However, the example code is only meant for experimenting. For that the easy structure of the examples is very useful.