Continuous delivery of the third-continuous integration

Other continuous delivery related articles: "Continuous delivery" series of articles Directory

Chapter III Continuous Integration 1. Introduction

The goal of continuous integration is to keep the software in a working state

2. Achieve continuous Integration 2.1. Preparatory work

1. Version control
2. Automated Build
3. Team consensus

2.2. A basic continuous Integration system

A simple process for developers to use continuous integration services

1. Check to see if there is a build running, if any, wait for it to finish, if it fails, just fix it with the rest of the team and then commit the code
2. Once the build is complete and the test passes completely, update the version's code from the version control library to your own development environment
3. Execute the build script on your own development machine and run the tests to make sure all the code on your machine is working properly
4. If the local build succeeds, you commit the code
5. And wait for your build results for this submission
6. If it fails, stop the work, fix the problem, go to step 3
7. If it succeeds, celebrate and start the next mission.

3. Prerequisites for Continuous Integration 3.1. Frequent submission 3.2. Comprehensive Automated word test suite

Unit testing, integration testing, acceptance testing

3.3. Maintain a short build and test process

Frequent execution cannot take too long

3.4. Managing the development workspace

When developers start a new task, they should always start with a known-good state.

4. Using Continuous Integration Software

Jenkins,cruisecontrol,go,teamcity, etc.

5. Essential Practice 5.1. Do not submit a new code after a build failure 5.2. Run all commit tests locally before committing, or let the continuous integration server do this 5.3. Wait until the submission test passes and then continue to work 5.4. The build must be in a successful state before going home

If you don't want to be scolded by your coworkers the next day,

5.5. Always ready to roll back to the previous version

According to the process of continuous succession, the previous version must be no problem

5.6. Specify a time to repair before rolling back

Say 10 minutes without fixing the problem, roll it back.

5.7. Do not comment out the failed test

Either the test is wrong or the problem is changed, or the test can be deleted, at your discretion, not commented out

5.8. Responsible for self-caused problems 5.9. Test-driven Development 6. Recommended Practices

The following practice of our mission is also useful

• If you violate architectural principles, let build fail
• If the test run slows down, let the build fail
• If there is a compile warning or code style problem, let the test fail

8. Summary

Continuous integration is the cornerstone of the deployment pipeline, and even with continuous integration, the development process can be greatly improved

Continuous delivery of the third-continuous integration