Continuous Integration Maturity Model

Reference Original: http://my.oschina.net/u/134516/blog/495477

Levels of the Maturity model

1. Base: At base level, we just have a "model", our team is no longer all the processes are to be manually operated.

2. Beginner: The team began to take some of the company's ongoing delivery practices, but at the beginning of the level

3. Intermediate: The practice has matured somewhat, releasing fewer errors and being more efficient. For most teams, this basic practice is probably enough.

4. Advanced: The team has done far more than any other team in the industry and is very efficient and can prevent mistakes.

5. Extreme: The cost of achieving this level of requirements is very expensive, but for some teams it is their goal. In other words, most organizations believe that this level will not be achieved until they are crazy, while the other few think that it is insane not to achieve this level.

Build, deploy, test, and report

These topics cover the basic elements of the end-to-end build lifecycle, from source code to the process of building the environment's software.

Build

The key to continuous developer-centric integration is the rapid feedback of building software. In enterprise development, building management and controllable build processes are critical factors. A controlled build process regulates a series of steps to get source code, compile, package, and store.

Most projects start with the development of the machine to build, and there is no standard process. This development is built with the IDE, while the other uses the build script. Some very immature teams use these build results to test and even publish to the production environment. This lack of control results in the rapid appearance of many teams and they begin to look for better choices.

Our goal should be: build based on submissions, have a warehouse-dependent, secure configuration.

Deployment

Publishing is where you move software to a testable, user-accessible, or ready-to-send customer. For Web applications, this could mean installing an app on a series of Web servers, updating a database with a colleague, or a static storage server. For the video game control, one deployment should be to install the game on the test machine, while the deployment of the production environment may also involve "stamping a gold ISO to deliverto the publisher" (not quite understand that the game's release is not translated correctly ... ）

Most of the deployment starts with a manual process. The built address is sent to the deployment engineer and the deployment engineer moves the build to the target machine and executes the installation program to complete the deployment. This causes the deployment process to be slow and the deployment failure rate high. Engineers are often forced to perform risky deployments at night and over the weekend in production systems and test systems, which cannot be used by other people, but it is likely that the system is being used by the test. Even worse, deployments of different environments may have different processes, which makes it difficult to ensure that successful deployments in one environment can be equally successful in the next environment.

Goal of deployment Automation:Test Gated Automation promotions,database deployments,coordinated soa/multi-tier deploys.

Test

Continuous integration and delivery for a long time have been associated with automated testing to some extent. This groundbreaking article at Martin Fowler and Steve McConnell's early practice descriptions of daily builds and smoke tests were confirmed. In fact, this is primarily what we want to provide feedback on quality issues very quickly when performing regular build and deployment. In the context of continuous delivery, various types of automated tests and manual testing have been taken into account.

Ironically, many teams that are good at building and deploying are weak in testing. They do the building, make it pass some basic manual tests, and then publish it. Some parts of the application are often destroyed, and new features are not fully tested. As teams mature in the field of testing, they can quickly return to problems, increasing productivity and confidence.

Test automation target:Some static analysis, automated functional Tests run nightly (performs automated function testing nightly)

Report

Historically, the continuous integration tool focuses on reporting the state of the recent build. In a broader perspective, reporting is a key factor in the continued delivery of businesses. The company's continuous delivery reports cover software quality and content information, as well as relevant metrics for the enterprise's ongoing release process.

The team without reporting is blindly moving forward. If no one can review the results, then all the tests are useless. It is also useless to accumulate data that is not refined into understandable information. The reporting of mature teams is becoming more and more visualized, exposing more and more useful information.

Goal of reporting maturity: reportTrending (reporting trends)

Continuous Integration Maturity Model