An overview of the enterprise's continuous integration Maturity Model-building

This article is at the 2.0 software development conference
I will discuss with you. As mentioned above, the model originated from citcon
A discussion in North America by Eric and Jeffrey Fredrick


Analysis summary and published here
. Because there is a lot of content, it will be published as a series. (Jeffrey Fredrick


Currently, it is one of the developers and maintainers of the open-source continuous integration tool cruisecontrol)

========================================================== ==============================

 

In today's software development field, the automation promotion is quite remarkable, and software is increasingly developed by large-scale and distributed teams. Strict enterprise management requirements are also very common. As a result, the collision between agile software development and continuous integration and the reality of enterprise development projects is becoming more and more remarkable. Throughout the entire lifecycle of software development, our investment in automation is constantly increasing. The pioneers in this area have crossed the team-level continuous integration and combined their automation results with end-to-end solutions. These investments in enterprise-level continuous integration allow them to respond to changes in demand and deliver high-quality software quickly, and get twice the result with half the effort. Despite the advantages of automation, the adoption of automation is not balanced. For example, many teams are still struggling with manual, slow, and high-risk deployment, while some teams can perform efficient and secure production environment deployment multiple times in a day. In fact, there are many ways or means to improve our development automation, But where should we start?

Diversity of Enterprises

 

When we created this guide, we encountered the challenge that different enterprises (or even different teams of the same company) were not uniform. Some demands for medical equipment systems may be more difficult than making games, or adding new features to e-commerce websites, or creating an internal SOA application. Therefore, a single maturity model cannot adapt to all situations. Therefore, we have chosen four dimensions of continuous enterprise integration to measure maturity: Build, deploy, test, and report. We classify the practices corresponding to each dimension under a certain level and explain why (or not) these practices need to be adopted. Through this model, you can learn about the average level of enterprise continuous integration in the industry, and reflect on what aspects are higher than the average level of the industry, and what other aspects are insufficient. The evaluation scale reflected by this model is based entirely on the first-hand experience of hundreds of teams over the past few years and some reports in this field. To explain how to use this model, we have created three enterprise cases with different requirements. We will analyze their situation and show how they use the Maturity Model to plan which improvements will bring them the highest ROI.

 

Level in Maturity Model

 

Throughout the article, the maturity levels of enterprise continuous integration in different dimensions will be elaborated in the same way. Level: entry, beginner, medium, advanced, and crazy. To explain these levels, the following is an example of the relationship between different levels. The starting point of the instance is: the process is completely manual, that is, an engineer must manually execute a series of lengthy and error-prone steps to achieve the goal of "automating a manual process. For this "automated process", its maturity model is as follows:

 

 

The team was initially an entry-level team because they had already written some auxiliary scripts to automate those very slow or problematic parts of the process. The benefit of this automation is to save time and reduce errors. For further improvement, the team concatenates all the auxiliary scripts to automate a single script throughout the process, that is, to reach the intermediate level. The return of this single script is that this operation process can be easily handed over to others. When the team wants to improve to the class, it needs to use an application software to call and execute the script. This application may be executed in the background, but it must run on the correct conditions, timing, and location every time. For example, the app may only need a mouse click, Or you only need to call the script at a specific time to automatically input some parameters for execution.

 

Of course, the definition of the progressive class or crazy class will change over time. When continuous integration was born, "automatically trigger building after code submission" was considered crazy, and today it can only be regarded as an intermediate activity.

 

Build, deploy, test, and report

 

Our Maturity Model consists of four dimensions: Build, deployment, test, and report. These four dimensions cover the entire end-to-end build lifecycle from source code to products.

 

Build

 

The original developer-centric continuous integration aims to get quick feedback from building software. After continuous integration enters the enterprise perspective, building management, dependencies between projects, and management control in the building process are all crucial elements. Most new projects are generally built on the development machine at the beginning, and there is no standard process. A developer may be used to building on his own IDE, while another developer may have written a build script to do this. The least mature teams will deploy and test binary files built using this process, and even publish them to the production environment. This kind of problems caused by lack of control will soon become apparent. Therefore, we need to find a better method at the beginning.

 

 

The first step to mature building is to standardize the building process and perform formal building on non-development machines. Building on a non-developer machine means that the building will not be contaminated by changes in the developer's machine environment. Because the formal build is no longer performed on the developer's machine, we must get the code from a fixed source file control every time and follow certain rules: for example, the latest version is checked out from a branch every time, or the source code of a tag is used. After doing this, the Team has reached the entry level.

 

The entry-level team takes further actions to automate the building steps. That is, the build server directs the machine, checks out the rules by source code to obtain the source code, and executes those build steps, thus providing a preliminary controlled build process. Typically, these automated builds are executed daily, although some teams may execute more than twice a day. At this time, the team is upgraded to the novice level.

 

For intermediate teams, they began to focus more clearly on and manage their dependencies on other software (including sub-projects or third-party libraries ). Intermediate users use dependency management libraries to track these library files and provide these library files during building, rather than using some verbal conventions. Similarly, those builds that may be referenced by other builds also put themselves in this library through dependency management tools for reference by other builds. After achieving this level of control, automatic building is easy to achieve and provides more valuable feedback. The intermediate team adopted continuous build (that is, automatic build upon each developer's submission or when dependency changes ). All build results are saved (may be placed on a network server, or simply on a continuous Integration Server) and periodically cleaned up and tagged for easy identification. Large teams will use distributed building facilities to process a large number of parallel structures. At this time, many organizations can say that they have met their needs.

 

 

More formal organizations (such as enterprise-level organizations) will be further organized to control the construction process. In this environment, the Team tracks the changes in the build process like tracking changes in source code and dependencies. The modification process must be approved. It is strictly controlled to log on to the official building machine and modify the configuration of the building server. For a place where "obedience is a factor" or where continuous integration of enterprises has become a production system, the controlled building process of the class should be targeted. For other teams that do not have this requirement, the intermediate level is acceptable.

 

In addition, some organizations have more strict management and control rules, and require that they be able to perfectly rebuild the previous release version (for example, they need to get the same product as a build product a year ago ). These organizations will use a variety of technologies to ensure the repeatability of each environment. Some scripts that may be carefully controlled by version may be prepared to build machines starting from installing the operating system before running the build. Some other Virtual Machine images may be used to do similar things. We define this control level as crazy level. Therefore, some teams may not need to do this. Because the burden may be too large and the benefits are too small.

 

<To be continued>