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:
- A developer submits changed code to the Software Configuration Management system
- The code build is automated (periodically or triggered by code changes)
- Unit tests are executed
- The component is deployed on the integration-test environment
- The integration tests are (automatically) executed
The Continuous Delivery workflow can be summarized as follows:
- The code is officially tagged, versioned, and released
- The components are deployed on the official environment test (preproduction)
- The functional tests are executed by the test team
- The components are approved and released for the production environment
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:
- Setting up the Maven repository
- Setting up the Software Configuration Management system
- Setting up the Software Version Management system
- Setting up the Build Integration tool
- Setting up the Test Integration tool
- Customizing CID
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.
Release lifecycle
Throughout CID's workflow, the Build Phase starts the following:
- A version that is assigned to each component (artifact)
- Source code that is tagged
- Source code that is built and tested through a test platform (Test Phase)
- The issues that are marked as released on the component version
- Each component that is packaged
- A patch with one or more new components that are notified
Finally, the test team installs and validates the patch using the following steps:
- The prerequisites (the database changes or configuration) are applied
- The components are installed (Deploy Phase)
- According to the test plan, functional, integration, and regression tests are executed by the delivery team
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.