Skip to main content

Build Machines and Test Machines

Posted by kellyohair on October 8, 2006 at 10:46 AM PDT

Just thought I'd touch on a subject that some people forget about
when having to build products that will run on many different
machines.
Building and testing on a single machine is easy, building bits
that need to run on dozens of different machines is the hard part.

Test machines and Build machines are different.
Ideally you WANT to test on any and all machines you can get your hands
on, but when you build, you need build machines that match
specifications and have pre-installed products, anything else
and you run the risk of creating faulty build bits.
These build machines can also be so old that some products
might not be available, or might
have problems running on it.
Or some product dependency
that a product depends on won't be available.
So anything used in the build process has to be carefully considered
and carefully tracked.

Once the platforms a release will officially support is
decided, then we can decide what the official build machines
and configurations will be.
But we also have to consider the timing of making these changes
during the release, so expect these changes to be gradual
over time and not all at once.

I'm not a Release Engineer,
but I do appreciate the job they have to do.
Once a product is released, the Release Engineering team has to
preserve those build machines as long as the product might need to
be updated, patched, or re-built for any reason.
This can be a very long period of time, anywhere from 5-7 years.
Any change to a build system can create a difference in the built
product, and sometimes those differences are not readily apparent,
sometimes not until a bug is found in the field.
If only we could all deliver pure Java products, our lives would be
so much easier.

So when it comes to build systems and changes to build systems,
expect it to be slow and careful.

-kto

Related Topics >>