Continuous integration of Agile Software Development

Agile requirement analysis, Agile Project Management, and agile software development have become a hot topic. In today's complex and changing business projects, it seems that "agile" has become the best choice. Indeed, no matter from theory or countless cases, most of the software projects in today's business environment are suitable.

Just as the appearance of a good language affects a software developer's five, ten, or even longer career. The emergence and popularization of an excellent software project management philosophy and best practices will have a more profound impact on software practitioners.

Agile Software development may be particularly discussed. This is related to a large number of groups involved.

In agile software development, in addition to requiring the participation of individuals to be "agile", we also need to use some tools to improve the agility of the Organization. Here we will talk about the concept of continuous integration that is often mentioned in Agile development.

Before continuous integration of applications, the traditional development mode divides modules at the beginning of a project and waits for allCodeAfter the development is complete, the software is integrated for testing. With the development of software technology, various software methods are blooming, the scale of the software is also expanding, and the software requirements are becoming more and more complex, the software cannot be developed simply by dividing modules, and mutual cooperation is required within the project. the disadvantages of the traditional model of dividing modules are becoming more and more obvious. Because of the many bugs in the project
In the early stages of integration, the problem was discovered only during 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, the root cause of the problem is difficult to locate, and even the underlying architecture has to be adjusted. At this stage, there are many bug meetings, the content of the meeting is basically about how bugs are generated. In the end, they often develop 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:
1. Access a single source code library and Source code Stored in a single location (source code control system), so that everyone can obtain the latest source code (and previous versions) from here ).
2. Supports automatic creation of scripts to make the creation process completely automated, so that anyone can complete the process by entering only one command.
System creation.
3. The test is completely automated. Developers are required to provide self-tested code so that anyone can enter only one command.
Run a complete system test.
4. You can create a master instance by entering only one command.
5. 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 that the created
Indeed, M cconnell calls it "smoke test". In continuous integration, this is called 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 results are complete, rather than errors.
Discard the test process.
Continuous integration and daily creation have the following features:
1. 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.
2. Continuous integration emphasizes timely feedback. The goal of daily creation is to get a stable release version that can be used. Continuous integration emphasizes that rapid feedback is provided to developers after integration fails, the result of successful creation is also a stable version.
The three-day creation did not emphasize the frequency of developers' checkin source code submission, but continuous integration encouraged and supported developers to submit changes 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 previous section lists the advantages of continuous integration, but creating a continuous integration environment is technically complex and requires
The key to a certain amount of time is that continuous integration can catch enough bugs in a timely manner to fundamentally eliminate traditional models.
This is already worth the overhead.