1. First, a developer commits code to the version control repository.
Meanwhile, the CI server on the integration build machine
is polling this repository for changes (e.g., every few minutes).
2. Soon after a commit occurs, the CI server detects that changes
have occurred in the version control repository, so the CI server
retrieves the latest copy of the code from the repository and then
executes a build script, which integrates the software.
3. The CI server generates feedback by e-mailing build results to
specified project members.
4. The CI server continues to poll for changes in the version control
repository.
Figure 1-1 illustrates these parts of the CI system.
The following sections describe the tools and players identified in
Figure 1-1 in more detail.
FIGURE 1-1 The components of a CI system Developer Developer Developer Subversion Version Control Repository Feedback Mechanism CI Server Integration Build Machine Compile Source Code, Integrate Database, Run Tests, Run Inspections, Deploy Software Commit Changes Commit Changes Commit Changes Poll : Generate Build Script 6 Chapter 1 ❑ Getting Started Developer Once a developer has performed all of the modifications related to the assigned task, she runs a private build (which integrates changes from the rest of the team) and then commits her changes to the version control repository. This step may occur at any time and does not affect the subsequent steps of the CI process. An integration build does not occur unless there are changes applied to the version control repository. Listing 1-1 demonstrates an example of executing a private build by calling an Ant build script from the command line. Notice that this script retrieves the latest updates from the Subversion version control repository. Find Problems Earlier by Building Often Once you’ve automated your build and it can be run via a single command, you are ready to perform CI. By running this automated build whenever a change is committed to your project’s version control system, teams can answer questions like: • Do all the software components work together? • What is my code complexity? • Is the team adhering to the established coding standards? • How much code is covered by automated tests? • Were all the tests successful after the latest change? • Does my application still meet the performance requirements? • Were there any problems with the last deployment? Knowing that software was successfully “built” with the latest changes is valuable, but knowing that software was built correctly is invaluable, as software defects will undoubtedly creep into a code base at some point. The reason you want to build continuously is to get rapid feedback so that you can find and fix problems throughout the development lifecycle. Build Software at Every Change 7 LISTING 1-1 Running a Private
https://www.assembla.com/spaces/cie/documents/c5Sfa6Lq8r3yLWab7jnrAJ/download/c5Sfa6Lq8r3yLWab7jnrAJ
Posts
