Implementation of continuous building in agile development process based on IBM Rational build Forge

In the process of agile development, the software construction cycle and the degree of automation directly affect the speed and quality of development. This article, combined with specific software development projects, describes how to use IBM Rational build Forge to implement fully automated software construction, product installation and unit testing in the agile development process, continuously and rapidly build daily, improve the efficiency of the development team and improve the quality of products and development.

Overview

Agile development is a human-centered, iterative, step-by-step development approach, with a development cycle typically two to four weeks. One of the principles of agile development is to deliver valuable software early and continuously to satisfy customers, and the shorter the delivery time, the better. How can the delivery of the product be achieved in a short period of time? Continuous building every day can provide a good quality assurance for the implementation of short time delivery software.

Because a lot of code is being modified every day during the development process, these changes can create potential problems for the product. Therefore, for early detection of problems in development, code needs to be continuously integrated and frequently built, tested, and committed. If the build is not fully automated, frequent builds can take a lot of manpower and time. But the process of building automation is also a tedious and complex task. IBM Rational Build Forge provides a good, continuous building framework to automate end-to-end processes. Not only can it use its own scripts, but it can also integrate the user's existing scripts and tools, so it can efficiently utilize existing resources, and it has the task customization function to periodically start the required construction projects, providing a repeatable and reliable application development lifecycle process.

Continuous integration process

2.1 Typical Continuous integration process

There are generally two kinds of constructs in the continuous integration process: local build and integration build. The local build is typically done by the developer after the code has been modified and completed on its own machine, and the integration build is typically integrated with the code of all developers and is done by a professional build engineer. The typical continuous integration process, shown in Figure 1, is where developers get development code, developers work on their own, and build locally. After a certain amount of development time, combined team development results, the local build, if the local build successful, developers can submit code to the integration branch, build engineers to build and publish the integration.

Figure 1. A typical continuous build process

Project R makes appropriate modifications to this typical continuous integration process based on a typical continuous build process combined with the agile development approach.

2.2 Continuous integration process for project R

Project R Agile Development takes the form of Scrum development, one version of the development is divided into several sprints, a sprint typically lasts four weeks. In each Sprint, three to four integrated builds are required, and three local builds are required during the day. According to the construction requirements proposed by the project, the construction of Project R adopts the continuous building method of combining local build and integration construction, and uses the task customization of build Forge to realize three local builds every day.

In order to adapt to agile development and continuous building requirements, we modify the development pattern, code configuration management and build process of the project accordingly. The Code Configuration Management tool used by Project R is ClearCase (hereinafter referred to as CC). Before agile development, each developer had a separate development stream (stream), before each integration build, each developer needed to submit the code to the integration stream, then create a baseline (Baseline), and the build engineer checked out the code from the latest baseline to build the integration. If the program between developers is interdependent, but not communicated in time, it often leads to the failure of the integration build. With agile development, a unified development stream has been established for developers to gain more access to other developers ' code, and all developers are developing based on that stream, with 3 local builds on the stream each day to detect problems as quickly as possible. By building locally, confirming that the code is correct, the code is submitted to the integration stream, the baseline is created, and the integration is built. The CC strategy after adopting the agile development approach is shown in Figure 2.

Figure 2. ClearCase Simplified development Branching strategy diagram

After the CC's development strategy has been modified, the continuous build process used by Project R is shown in Figure 3. Developers perform development activities on the development stream, and the local build is started periodically according to the time of the custom task. If the local build succeeds and requires an integrated build, the developer submits the code and creates a baseline for the integrated build.

Figure 3. Project R Continuous Integration process