Why continuous integration?

Why continuous integration?

Before continuous integration of applications, the traditional development mode is to divide modules at the beginning of a project, and then integrate all the code for testing after development, with the development of software technology, various software methods are blooming, the scale of software is also expanding, and software requirements are becoming increasingly complex. software cannot be developed simply by dividing modules, the internal project cooperation is required, and the disadvantages of the traditional model of dividing modules are becoming more and more obvious. Because many bugs exist in the early stages of the project, and problems are discovered in the final integration, developers need to spend a lot of time in the integration phase to find the root cause of the bug. Coupled with the complexity of the software, it is difficult to locate the root cause of the problem, and even have to adjust the underlying architecture, at this stage, there were a lot of bug meetings. Basically, the content of the meeting was about how bugs were generated. In the end, they often developed into different module owners to share their responsibilities.

The biggest advantage of continuous integration is to avoid this traditional model in the integration phase of the pest removal conference. Continuous integration advocates that project developers frequently submit their changes to the source code (Check In) to a single source code library and verify whether these changes damage the project, continuous integration includes the following key points:

• Access a single source code library and save all the source code in a single location (source code control system), so that everyone can obtain the latest source code (and previous versions) from here ).
• Supports automatic creation of scripts to completely automate the creation process, allowing anyone to create the system by entering only one command.
• The test is completely automated. Developers are required to provide self-tested code so that anyone can run a complete system test with only one command.
• Allows anyone to create a master by entering only one command.
• Developers are advised to frequently submit (Check In) modified code.

The key to continuous integration is full automation. The entire creation process should be completed automatically after the source code is read, compiled, connected, and tested. For a successful creation, each step in the automation process should not go wrong. The most important step is testing. Only the creation that passes the test is successful.

In continuous integration, the creation is no longer as simple as traditional compilation and connection. The creation should also include self-testing. The self-testing code is submitted at the same time when the developer submits the source code, it is a unit test for source code (from the practice of XP). It integrates all the self-test code to form a test set, after all the latest source code is compiled and connected, you must test the test set before it can be successfully created. The main purpose of this test is to verify the correctness of the Creation. m cconnell calls it a "smoke test". In continuous integration, this is called the integration Acceptance Test build verify test, bvt for short. BVT testing is the foundation of quality, and the QA Team will not feel the existence of BVT. They only aim at successful
Create and test (such as functional testing ).

BVT testing should be as detailed as possible. More problems can be found only through detailed testing, and the feedback results will be of more reference significance. All tests should be completed, the feedback is complete, rather than giving up the test process when an error occurs.

Continuous integration and daily creation have the following features:

• Continuous integration emphasizes the frequency of integration. Compared with daily creation, continuous integration is more frequent. At present, the best practice recommended is to integrate every hour.
• Continuous integration emphasizes timely feedback. The goal of daily creation is to get a stable release version that can be used. Continuous integration emphasizes fast feedback to developers after integration failure, the result of successful creation is also a stable version.
• The daily creation does not emphasize the frequency of developers submitting (Check In) source code, but continuous integration encourages and supports developers to submit modifications to the source code as soon as possible and get feedback as soon as possible.

From the features of continuous integration and daily creation listed above, it is obvious that there are a lot of "Frequency" and "feedback, continuous integration has a basic point that is contrary to intuition, that is, "regular integration is better than occasional integration ". Martin Fowler believes that for continuous integration, the more frequent the integration, the better the effect. If your integration is not performed frequently (less than once a day), the integration is a pain point, if the integration is occasionally performed once (one week or even one month), it will take a lot of time and effort to wait until the integration phase discovers bugs and finds the cause to solve the bugs, in addition, this method is a bit like the traditional integration mode, which violates the original intention of continuous integration.

According to Martin Fowler, the increase and time of project bugs are not linear, but proportional to the square of time. The longer the interval between two integrations, the more bugs increase than you expected, the more work you pay to solve the bugs. The more you think the more work you pay, the more you want to postpone integration later, in an attempt to solve the problem at the last time, more bugs will be generated, resulting in a greater workload for the next integration. The more you feel the pain of integration, the more you will push the integration time back, finally, a vicious circle is formed.

Therefore, if the integration result is painful, it may indicate that you should integrate more frequently. Frequent integration and timely feedback spur the project team to actively face the problem instead of putting the problem to the end. If the method is correct, more frequent integration should reduce your pain and save you a lot of time.

Because continuous integration is ultimately created through testing, you will find that the requirements for the frequency of continuous integration are exactly the same as the idea of testing first in the test-driven development method proposed by Kent Beck. It should be noted that introducing continuous integration from the beginning of the project can discover bugs as early as possible, but it does not mean that continuous integration can help you catch all bugs. The ability to troubleshoot continuous integration depends on the test technology. As we all know, it is impossible to prove that the tested code has found all the errors.

The above lists the advantages of continuous integration, but creating a continuous integration environment is technically complex and takes some time, the key is that continuous integration can catch enough bugs in a "timely" manner to fundamentally eliminate the disadvantages of traditional models, which is worth the overhead it has to spend.