Continuous Integration is a common practice proposed by the extreme programming (XP) methodology to integrate various components developed over a long period of time by different groups. Continuous Delivery is a series of processes designed to ensure software quality and to deploy them safely as the final version to a production-like environment. Continuous Integration is de facto complimentary to Continuous Delivery and anticipates this stage.
The Continuous Integration workflow can be summarized as follows:
The Continuous Delivery workflow can be summarized as follows:
Other authors refer to Continuous Integration as part of Continuous Delivery. In this book, we will avoid a complete discussion of these concepts; we will refer to the complete process as Continuous Integration and Delivery (CID). CID consists of continuous software releasing during the day, software versioning, a tool to align the development environment (development) with the shared environment (mainline), a platform to release and manage the versioned components, continuous unit test management, integration test management, and functional test execution.
CID needs a complete build-and-integration tool, allowing the development team to build and manage the versions, integrate a bug-fixing tool, perform some basic tests, and release the software to the test team. In this chapter, we will build a complete Maven CID environment using some common open source tools such as Nexus, Jenkins/Hudson, MantisBT, and Ant. There are other powerful commercial products, but generally speaking, the main concepts of CID can be discovered and applied through these tools.
In particular, we will cover the following topics:
CID's flowchart is a set of repeatable steps implementing the software-releasing phase for a production-like environment. This phase aims to package the application and related components, assign the correct version number, archive the code, and provide the correct information to test and install the new patch.
The following diagram shows CID's flowchart. Following change requests due to bugs or new features, developers make the new changes to the source code and test the components on the development environment. Developers mark the issue as resolved and provide the needed information (prerequisites), such as configuration, the database changes, and preinstallation actions (Development Phase), to install the components.
Throughout CID's workflow, the Build Phase starts the following:
Finally, the test team installs and validates the patch using the following steps:
These last steps are a part of the delivery (and validation) stage. In this book, we will not discuss about the final delivery stage as we assume that all released versions will be validated and promoted (for production) by a delivery team, rather than by an automation system. Therefore, we will refer to the keyword release version in the sense of release candidate version for production.
The previous diagram reports some technologies used in this chapter to implement CI's pipeline. In particular, Nexus is used to administer a shared and remote Maven repository, Subversion (SVN) to manage source code, MantisBT as a bug-tracking tool, Hudson/Jenkins to manage the build pipeline, and, obviously, Maven to manage the software's version and to compile and package the components. Different technologies, such as GIT or JIRA will shortly be discussed to complete the overall view. Finally, Maven Ant integration will be discussed to customize some basic steps.