Mission for Automated Builds
"Build Early, Build Often"
A variation of this adage has been around in the Open Source community called "Release Early and Release Often" for quite some time albeit for a different reason. BEBO helps a development team identify issues that can arise from checking in the wrong files, files with incorrect syntax, missing files etc. BEBO will address integration issues at the application level that might have slipped passed individual developer builds.
Builds must be done on a regular basis. There should be a dedicated resource(s) assigned to do the same. The entire project team must be trained to view the builds as an important activity and not as a chore. Builds must be completed without any failures on a regular basis. Build failures must be a rare event and should be treated with utmost seriousness. The project team should ensure that successful builds are top priority on their agenda."
-- Something I plagiarized from another web site, but I like the message!
All Move products which are generated from the compilation or assembly of source code should be built automatically in a clean, controlled environment to ensure delivery of predictable binaries or scripts without error, to development, QA, and beyond. It is important that jobs are built continuously, triggered or polled, and immediate notification be provided from builds without manual tasks. There may be other internal deliverables that should be delivered in the same fashion that have yet to be determined.
Currently the Move Player, Player SDK, Publishing, Move Media Services and some specialized 'ground up' projects are under the control of the automated build system. Hopefully others will follow suit.
If you don't care about viewing the Cabie UI, standard (not promoted) build output may be browsed and downloaded from here (listed by build server):
Please note that when builds are promoted, they will no longer be grouped by build server, but by job name. **Promoted jobs are never automatically deleted by the build server**
**How come my job hasn't fired off?**
Currently there is no priority scheduling for jobs. If your job hasn't fired off and you know there are changes pending, there may be other jobs running, or the build server may be 'sleeping' between polls (since jobs aren't triggered). It is also possible that the build server process has gone belly up, this is typically due to a network error and the build administrator needs to be notified. Occasionally, characteristics of a job may be altered by the build administrator to specifically not allow a build to fire off, typically for some required maintainence.
**My build is an hour overdue, what's going on with it?**
The build server calculates predicted build durations by averaging build times over a determined number (typically based upon the number of builds the build server is told to 'keep') of successfully completed jobs then tacks on another 10% as a standard deviation. The build server fires off a watchdog thread that will email the build administrator if a job is overdue. Sometimes a build may be late because developer A checked in a 8,000 files which all have to be parsed by querying the source code control system. Typically viewing running processes on the build server can indicate what the hang up is. You may want to read up about using the [[cabie|Cabie UI]] for diagnostics. Additionally, if the job is brand new, it will show 'overdue' until enough builds have been completed to determine an average build duration.
**Why do I see the error message 'server unavailable'?**
There are times when the build server has to be taken off line for maintainence, usually due to changes being made to build server code. This typically means the build administrator has shutdown the build server process for either updates, OS updates, or a machine reboot is in progress due to other issues. If the problem persists contact the build administrator for details.
**The job <your-job-name-here> doesn't show up on the build server (Cabie UI) anymore. What happened to it?**
When it is determined that a particular job will not be built any longer, it is removed from view of all build server processes. It will no longer show up, cluttering the display, or for other build server operations (like building, polling etc.) This allows the build server to only deal with current active jobs. The builds from the missing jobs can still be accessed directly as described in '[Builds].
**A build job was removed from view of the Cabie UI, but I need it back and running, how do I do that?**
When a job is removed from view of the Cabie UI and server processes, it's characteristics remain safe so that the job can be restored to a running state by the build administrator, just ask and the job cab be restored...
**How can I request a new job be added to one or more of the build servers?**
Just contact the build administrator (hint: he maintains the build servers).
**Who maintains the build servers, who is the build administrator?**