CASA Continuous Build/Test Server User Guidelines
This page provides
guidelines for using the CASA Continuous Build/Test (CBT) Servers (
casa-jenkins and
casa-cbts) to maximize the benefits of these servers for all CASA developers.
These guidelines are consistent with the practice of
Continuous integration, but are still useful if you do not practice Continuous Integration.
Status: PROPOSAL
Note: The table of contents provides an outline of the procedure to follow.
Before You Commit
Allow Time for Your Change to be Built and Tested
Do not commit changes to change control just before stopping work for the day (or for lunch). A failed build, not corrected quickly, can slow down other CASA developers.
Allow enough time for your change to build on the CBT server, for tests to run, and for you to check the results. Do not commit a change if you have less than the following time left in your work day.
These are minimums. They will be adjusted based on observed build and test times.
Check If the Build is Healthy
See the most recent build on the
CASA Production CBT server for the branch you are working on.
Below is a subset of the Jenkins build history for the CASA Trunk.
Healthy builds are indicated by a blue ball in the first column of the build history. Broken builds indicated by a red ball.
Healthy Build
If the latest build is healthy, proceed with your commit.
Broken Build
If the latest build is broken, allow the developer responsible for the change that broke the build time to fix it. Check back in a few minutes and try again.
The following practice is discouraged, unless you are fixing a build for someone else, as it can hinder the developer trying to fix a broken build. But, if you just can't wait for the broken build to be fixed,
- check the build logs for the broken build to see if your change will be built before the broken portion of the build. If so, then
- commit your change, and check the build logs to verify your change builds correctly.
With this approach, you will lose the benefit of post build testing.
If you do this, you are responsible for checking build results for your change and verifying your change did not introduce another build problem.
After You Commit
If Your Commit Failed
Send mail to casa-staff reporting you are working on fixing the CBT server build. Then, either fix the CBT server build immediately, or , if you can't fix the build immediately, revert your commit immediately (instructions below). Once the CBT server build is healthy, report to to casa-staff that you have fixed the CBT server build.
To revert a commit to Subversion, use the commands
svn merge -c -[revision number] .
svn commit -m 'Reverting r[revision number], because it broke the build. Will try again later.'
where [revision number] is the Subversion revision of your commit. Do not include "r" in the command. For example:
svn merge -c -23677 .
svn commit -m 'Reverting r23677, because it broke the build. Will try again later.'
Your change will remain in the change control history, so you can try again some other time when you have more time to resolve build issues. You can look at your change again with the command
svn diff -c[revision number]
where [revision number] is the Subversion revision of your commit. Do not include "r" in the command. For example:
svn diff -c23677
If Your Commit Succeeded
Move on to what ever you have to do next. Taunt someone who broke the build recently. Whatever...
--
ScottRankin - 2013-04-09