I remember that after I graduated, I entered a foreign company that mainly focuses on software outsourcing to do development. It uses a traditional waterfall software development process without any agile practices. Every day I go to work, turn on the computer, get my tasks, update the code from version control, open the project and press Build to prepare for today's development tasks. Suddenly found that the Build failed (usually it failed to compile), shouted "Who Break Build", but no one responded, I was depressed by myself, then checked which files caused the compilation to fail, found the last submitter, and asked him to go to Fix Build. Later, if someone in the team Break Build, some other team members will write "XXX Break Build, I want to treat you to dinner today" and so on on MSN's signature. In fact, Build failures often occur in the software development process. Different programmers implement their own modules, write unit tests, and submit code after completion, which will inevitably cause conflicts and lead to Build failures. But for developers, they should be able to get feedback on the current Build as quickly as possible. If the Build fails, it must be fixed in the shortest possible time, so as not to affect the development progress of others.
What does Build specifically include? It does not just refer to compiling code, but compiling code, running all tests (including unit tests, functional tests, etc.), running code analysis (such as analyzing whether the code conforms to coding specifications), deploying the system (producing executable software) , or deploy the website to a web server). Build is a series of processes used to ensure that the code can run, can run correctly, and finally can be released.
In agile development, there is a very important practice called continuous integration. And what is continuous integration? In simple terms, continuous integration is the frequent, continuous integration of the work of multiple team members and feedback. A typical continuous integration cycle includes the following steps:
- The continuous integration server constantly checks the code status from the version control server to see if the code has been updated.
- If the code is found to have the latest commit, then download the latest code from the version control server.
- After the code is completely updated, call the automated compilation script to compile the code.
- Run all automated tests.
- Do code analysis.
- Generate executable software that can be provided to testers for testing.
If any one of these steps fails, it means that the Build failed, and the continuous integration server will give corresponding feedback. Generally speaking, the continuous integration server will have a corresponding management interface, you can see the status of the build and the corresponding information, if the build fails, you can check the reason, whether the compilation failed or the test failed. Or after each build, the continuous integration server sends an email notification, and you can see the status of the latest build from the email. Of course, you can also customize the feedback method. For example, in ThoughtWorks China, the continuous integration feedback of a team is a volcano light. Yellow means that the Build is in progress, green means that the Build is successful, and red means that the Build fails. Once the light turns red, Everyone should not commit code and should fix the Build as soon as possible. Another team was more creative and used voice to provide feedback. If the Build is successful, there will be a language prompt saying "Build XXXX succeeded", if it fails, there will be a prompt "Build XXXX failed, it was submitted by XXX", the member whose name is pronounced has to stop and repair the Build.
The purpose of continuous integration practice is not to reduce the number of build failures, but to detect problems as early as possible, solve them in the shortest time, and reduce risk and waste. If you want to try continuous integration, the first thing you need is a continuous integration server, such as CruiseControl or VSTS; then you need to automate the existing Build, such as writing Ant scripts; the last thing is to configure it on the continuous integration server, such as configuring version control, integration interval time, how to deploy, how to give feedback, etc.
Reprinted from: http://www.cnblogs.com/blusehuang/archive/2008/01/20/continuous_integration.html