Building continuous integration systems with Subversion, Hudson, and Eclipse

Introduction to Continuous Integration System

Continuous integration systems are systems that continuously compile, test, inspect, and deploy source code.

Martin Fowler is defined for continuous integration:

Continuous integration is a software development practice in which team development members often integrate their work, and often each member can have multiple integrations per day. Each integration is validated by an automated build (including compilation, publishing, automated testing), which discovers integration errors as quickly as possible. This process can greatly reduce integration problems, allowing the team to develop cohesive software faster.

Continuous integration has the following characteristics and requirements:

There is a unified source code library.

The development of developers based on the same source code base is a prerequisite for continuous integration. In order for the continuous Integration System to function correctly, a source code management system, such as Subversion, is needed.

Implement software build and test automation.

Use some continuous integration software, such as Hudson, to automate software construction and testing.

Each time the code is submitted, a build is triggered on the continuous integration server.

In the development process, if there is a difference in the developer's local compilation environment, one of the developer's modifications may be validated locally, but after being submitted to the repository, another developer downloads to his own machine and fails to compile. To avoid this, you need to create a dedicated continuous integration server that unifies the configuration of the compilation environment, and each time a developer commits an integration and testing on a continuous integration server. This ensures that the version that the developer obtains from the version library can be compiled successfully on the local machine.

The test environment is consistent with the actual environment in which the product is released.

The goal of continuous integration is to quickly integrate and validate issues and then publish them. To ensure that continuously integrated products are finally released successfully, continuous integration of the test environment must be consistent with the actual operating environment of the product, so that users can get the products that really pass the testing test.

Continuous integration has the following advantages and benefits:

Reduce repetitive process and improve work efficiency.

The process of submitting code to a software release includes code building, testing, deployment, and so on, each of which is a time-consuming and unproductive process for development engineers, and the process is repeated every time the code changes. Continuous integration systems can automate these repetitive actions without too much human intervention, freeing project members from this duplication of work and putting them into other, more valuable jobs.

Improve the quality of the repair problem, can be produced at any time to deliver quality and reliable software, reduce project risk.

With continuous integration, we can often modify the source code and integrate these changes in time with other codes. Once the problem is identified, it will be resolved by the developer at the first time and the problem will be repaired quickly. Once a problem arises, the pattern of immediate repair, because there are not many problems superimposed together, fix the problem will be easier, the quality of repair is also higher. And can be produced at any time to deliver quality and reliable software. Continuous integration of the day can be multiple integration and to do the corresponding testing, in advance timely detection of defects, the problem in the early stage of the project to avoid the problem left to the late project, resulting in the risk of timely delivery of software.

If there is no continuous integration, these problems may have to accumulate until the integration test before delivery, at this point, many problems are intertwined, making it more difficult to fix problems, and rushing to fix them may introduce new flaws, reducing the quality of the fixes and potentially delaying the release of the product, which could eventually lead to a project failure.