A build server is a server devoted to continuously build and test the application via a long running agent process. From the developer's point of view the process is completely automated. An open source application named CruiseControl is used for this purpose (http://cruisecontrol.sourceforge.net). By merely checking changes into the source control system, the application developer has told the build server (or just the "build" for short) all it needs to know about the change. No direct contact from developer to build server is required or allowed for that matter. This isn't to say, however, that there is little interaction between the developer and the build server. The build server is prone to get upset about changes that cause application not to work right. That is its job. And, frankly, it is not shy about complaining when it gets upset. Complaining is a nice word but "nagging" is actually more accurate; as a matter of fact our build server has a configuration value set: nag=true.
The following describes the expected way the build server will behave and how/why we should try to make it happy:
- Every 10 minutes or so (this is configurable), the build server looks for committed changes in the appropriate location in the source control system. If none are found, the build waits another 10 minutes and polls again.
- When changes are found it does the following:
- Downloads all changes.
- Performs build and test. We use Maven to facilitate this (http://maven.apache.org).
- Removes all artifacts, class files and other remnants from the last build
- Runs the Artifact Generator to create all necessary artifacts
- Compiles all code
- Runs all JUnit tests
- Publishes results to a project build web site.
- If the build was unsuccessful, commonly called "broken", it sends emails to everyone who committed changes since the last successful build.
- Developers receive emails when the build is broken. These are only the developers that committed changes since the last successful build. The build is somewhat targeted in this regard, guessing that those providing new changes are by far the most likely culprits. When developers get these emails they should go to the project build web site (a link is included in the email) and inspect the problem.
- If the developer thinks the problem is his/her fault, it is customary to:
- Send a note to other developers on the list so they do not waste time on the problem
- Fix the problem, test it locally, commit changes to source control and hope the build is appeased.
- If no developer takes responsibility for the problem, some collaboration may be required. It may also require some discussion with the "build master" (see below).
- The build server continues to attempt builds per its normal polling interval. For example, if the build is broken, it will attempt to build every 10 minutes and will fail each time. With each failure it will send "nagging" emails to each developer committing changes since the last successful build -- the "nag list". As you may have guessed, this set of developers may grow as different developers commit changes while the build continues to be broken. This makes the number of "nagged" developers grow through time. Therefore, it behooves the development community to fix the build as soon as possible. More specifically, when a developer suspects in his or her heart that he or she was the one who broke the build, he or she should stop what he or she is doing and fix it. And on the next successful build, the build will stop nagging that developer and all other developers in the nag list.
Copyright © 2013, Oracle and/or its affiliates. All rights reserved.