2,561
edits
FlightGear build server: Difference between revisions
Jump to navigation
Jump to search
m
reodering and adding more details about the benefits of automated builds
m (→Intro) |
m (reodering and adding more details about the benefits of automated builds) |
||
| Line 17: | Line 17: | ||
It does chew a bit of disk-space, since the master stores the artifacts for the last N builds, where N is configurable. The artifacts are a hundred megabytes or so, since it's all the header files, libs and binaries, though compressed of course. | It does chew a bit of disk-space, since the master stores the artifacts for the last N builds, where N is configurable. The artifacts are a hundred megabytes or so, since it's all the header files, libs and binaries, though compressed of course. | ||
= | = Goals = | ||
If you | |||
The objective of such systems is that there should be *zero* human steps to create a release - not just out of laziness, but for repeatability. I.e don't write a checklist or 'howto' of creating a release, write a shell script that does the steps. (Or several). And check those scripts into a source control system, too. | |||
In general, such systems are good for capturing how repeatable a build process is - and the experiences on each of the Linux/mac/Windows slaves seem to confirm this. | |||
Quoting [http://www.joelonsoftware.com/articles/fog0000000043.html The Joel Test: 12 Steps to Better Code]: | |||
2. Can you make a build in one step? | |||
By this I mean: how many steps does it take to make a shipping build from the latest source snapshot? On good teams, there's a single script you can | |||
run that does a full checkout from scratch, rebuilds every line of code, makes the EXEs, in all their various versions, languages, and #ifdef | |||
combinations, creates the installation package, and creates the final media -- CDROM layout, download website, whatever. | |||
If the process takes any more than one step, it is prone to errors. And when you get closer to shipping, you want to have a very fast cycle of fixing | |||
the "last" bug, making the final EXEs, etc. If it takes 20 steps to compile the code, run the installation builder, etc., you're going to go crazy and | |||
you're going to make silly mistakes. | |||
For this very reason, the last company I worked at switched from WISE to InstallShield: we required that the installation process be able to run, from | |||
a script, automatically, overnight, using the NT scheduler, and WISE couldn't run from the scheduler overnight, so we threw it out. (The kind folks at | |||
WISE assure me that their latest version does support nightly builds.) | |||
3. Do you make daily builds? | |||
When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new | |||
source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine | |||
and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy. | |||
Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good | |||
way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as | |||
possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on | |||
working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source. | |||
On the Excel team we had a rule that whoever broke the build, as their "punishment", was responsible for babysitting the builds until someone else | |||
broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how | |||
it worked. | |||
For additional information on the benefits of automated builds, please see: [http://www.joelonsoftware.com/articles/fog0000000023.html Daily Builds Are Your Friend (Joel on Software)]. | |||
In general, when people report that the 'current code doesn't compile', we can direct them to the Hudson page from now on. | |||
= Status 07/2010 = | = Status 07/2010 = | ||
| Line 43: | Line 72: | ||
Currently the master is being used to do the Linux builds, because it was easy - no particular reason it has to be done that way, though. | Currently the master is being used to do the Linux builds, because it was easy - no particular reason it has to be done that way, though. | ||
= Hosting Options = | |||
If you know of any others, please do feel free to add new hosting options here. Some of these are not necessarily useful for directly hosting Hudson, but instead for building FlightGear on different platforms using SSH. This applies in particular to the various build farms. | |||
* http://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F | |||
* http://en.opensuse.org/Build_Service | |||
* https://edge.launchpad.net/builders/ | |||
* http://hub.opensolaris.org/bin/view/Community+Group+testing/testfarm | |||
* http://www.metamodul.com/10.html | |||
* http://www.gnu.org/software/hurd/public_hurd_boxen.html | |||
* http://www-03.ibm.com/systems/z/os/linux/support/lcds/ | |||
= Benefits = | = Benefits = | ||