Introduction to enterprise continuous integration Maturity Model 2-deployment

I am on a business trip and have not updated my blog in time. After "building", let's talk about the deployment of another dimension of the enterprise's continuous integration Maturity Model ". Before the text, I want to emphasize that "this model itself is a tool in the toolbox, not a tool ."

 

 

Deployment

 

Deployment refers to moving the software to the place where it is tested, or a location specified by the user to be sent to the customer. For Web applications, this may mean installing the software on a Web server and updating the database or static content server. For a video game, this test deployment may refer to the installation of the software version on some testing machines, while the product deployment may refer to the installation of a CD for the publisher.

Generally, the deployment process is manual at the beginning. The deployment engineer obtains the deployment file from somewhere, places it on the target machine, and then begins the formal installation process. However, this manual process is slow and the deployment failure rate may be higher. Engineers are often forced to work overtime at night or weekends to deploy the test environment or production environment because these environments need to run normally and cannot be stopped easily. Even worse, different steps may be used for manual operations in each environment (for example, steps are reversed in order, which is especially prone to different operators), and almost cannot be guaranteed: successful deployment in an environment indicates that the deployment in the next environment is equally likely to be successful.

For the team, abandoning the full manual process, using some auxiliary scripts or full-process scripting is a huge improvement. Throughout the industry, most teams will have some auxiliary scripts, but there are few teams with fully scripted deployment methods, especially in controlled environments (such as trial environments or production environments ). Therefore, the average level in the industry should be at the entry level.

 

The intermediate team is good at automated deployment in the testing environment. They use scripts to deploy in some or all of the test environments with one click. This greatly frees deployment engineers and reduces the time wasted by testers waiting for deployment. Just as continuous building is a feature of the intermediate build team, automatic deployment to the first test environment is a sign of intermediate maturity in the deployment dimension. Based on the dynamic nature of the team, the automatic deployment of this test environment should occur after any successful continuous build or periodic deployment within one day without interrupting the testing staff. The last feature of the intermediate team is the establishment of standardized environment deployment sequence. Although there may be some environment variables or two deployment methods, the earlier a version is successfully deployed, this means that subsequent deployment is more likely to succeed. Achieving this level is the goal of many teams. The advanced team is directed to the controlled environment or production environment. To deploy a production environment (or release), you only need to click the mouse. The production environment release is automatically triggered, and the corresponding release version can be used for disaster recovery. The teams that have already deployed the internal test environment should set the target to "advanced": If completely consistent deployment process is performed in all environments, when deploying the production environment, will greatly reduce the possibility of failure at the last moment. Another feature of a class-training team is that all versions passed the previous quality test are automatically deployed to some or all of the test environments. For example, with the approval of the test Manager, a build version is automatically installed in the stress test environment.

The goal of a crazy team is "continuous deployment", that is, it is automatically deployed to the production environment without manual intervention. After a version is obtained, it is automatically deployed to a series of testing environments. This version is automatically deployed to the production environment after all stages of the building pipeline and all tests are passed. Some. com applications can complete the entire process from source file control to release within one hour. Obviously, the automated testing at this time must be very mature and have automatic rollback and corresponding monitoring methods. However, in a fast-paced competitive environment, the rapid deployment of new features is also a core competitiveness, which can reduce the risk of large-scale function changes.