1 Integrated build basic process
1.1 overview
Before the construction begins, the architect should determine the project's initial source code package organizational structure, and the dependencies between the bags, etc., and define the build directory structure of the project unified. The architect should also guide set members to formulate integrated build plans to determine integrated content, build cycles, and schedules. In the initial stage of the project construction phase, the architect should be closely involved or directly assumed the direction of the integrated work, thus determining the direction of the evolution for the project source structure; thereafter, it should also be given enough attention, and regularly revised and maintain the source catalog structure in order to Grasp the project source code and final delivery workpiece.
Each build cycle contains: implementation -> unit test -> Submit -> integrated -> The basic process of smoke testing.
1.2 Integration Process Description
CEOs on the private development workstation, according to the project unified source structure organized its unit development directory, complete the source code, and unit test code, and prepare the automated build script of private components with the guidance or help of the group (coding and Easy to debug, the implementation sector usually selects the GUI integrated environment to compile. The compilation item in the IDE internal format is neither standard or not for integrated build, so maintenance additional build scripts are necessary), and the integrated stream in the construction success (Stream) Submit a result (before the completion of the submission, the performer should try integration to verify the build script as much as possible to verify the build script, and the unit test code is available, and then submitted.
The set member gets the source code submitted by the integration server, first adjusting the source code structure as needed to solve the compilation collision between the components, reproduce or modify the integrated build script, join the integrated constructive target (Target), and add new add The unit builds the script call to implement a unified batch compile, link, and finally generate integrated constructs; in order to implement and verify integrated targets, you may need to modify the source code, add or modify the code used to integrate test, and integrated debugging, etc. Setting members or implementors to complete this work; set members began to perform clean integration builds (in order to achieve continuous integration, you can configure the operating system task, timing automatically perform building tasks at night), generate executable delivery workpieces (also static or Dynamic link library, etc.); in order to verify the success of the build step, you will need to perform smoke testing. The principle is to use the existing test code as much as possible, to achieve automated smoke test by calling them in the build script (for the GUI target system In terms of automation, it is often difficult to rely on hand-to-smoke testing.
Setting members or configuration administrators to establish baselines for a construction of success; the tester will integrate this baseline on the test workstation; the implementation may reset the development baseline on this baseline on their respective development workstations (REBASE ) To continue subsequent development work on a new basis.
1.3 Continuous Integration Process Description
The set members can be automatically completed by configuring the CruiseControl tool, which is more simple, and does not require manual intervention and integrated work that wants to repeatedly execute. Set members can configure multiple sustained integration projects, including several people at the same time in the development of sub-components, and finally published integrated packages.
CruiseControl performs each build cycle in the event period, including: boot initialization -> detection source change -> Integrated Build -> Unit Test -> Release Construction and test results.
