Several knowledge points about continuous integration

Continuous integration is a software development practice, that is, the team development members often integrate their work. Generally, each member is integrated at least once a day, which means that multiple integrations may occur every day. Each integration is verified through automated build (including compilation, release, and automated testing) to detect integration errors as soon as possible. Many teams find that this process can greatly reduce integration problems and allow the team to develop cohesive software more quickly.

Some principles:
1. All developers need to build locally on the local machine and then submit the version control library to ensure that their changes do not cause continuous integration failure.
2. The developer must submit at least once a day to the version control library.Code.
3. Developers must update the code to the local machine at least once a day from the version control library.
4. A dedicated integration server is required to execute the integration build. The build is performed multiple times a day.
5. Each build must pass 100%.
6. Each build can generate a product that can be released.
7. Building that fails to be repaired has the highest priority.

The continuous integration cycle includes the following steps:
1. The continuous Integration Server constantly checks the code status from the version control server to see if the code is updated.
2. If the Code has been submitted to the latest version, download the latest code from the version control server.
3. After the code is completely updated, call the automated compilation script to compile the code.
4. Run all automated tests.
5. Perform code analysis.
6. generate executable software that can be provided to testers for testing.

if any of the steps fails, the build fails, and the continuous Integration Server gives feedback. Generally, the continuous integration server has a corresponding management interface. You can view the build status and related information. If the build fails, you can check whether the build fails or the test fails. Or, after each build, the continuous integration server sends an email notification, showing the status of the latest build in the email. Of course, you can also customize feedback methods. For example, in thoughtworks China, continuous integration feedback from a team is the volcano lamp, yellow indicates that the build is in progress, and Green indicates that the build is successful, the red color indicates that the build fails. Once the light turns red, no one can submit the code, but the build should be repaired as soon as possible. Another team is more creative and uses voice for feedback. If the build succeeds, a language prompt is displayed, indicating "build XXXX succeeded". If the build XXXX fails, a prompt is displayed, indicating that "build XXXX failed, submitted by XXX ", the member whose name is read must stop and fix the build.
the purpose of continuous integration is not to reduce the number of build failures, but to discover problems as soon as possible, solve the problems in the shortest time, and reduce risks and waste. If you want to try continuous integration, the first thing you need is the continuous integration server, such as cruisecontrol or vsts. Then you need to automate the existing build, such as writing ant scripts; the last step is to configure on the continuous integration server, such as configuring version control, integration interval, deployment, and feedback.