Kelly O'Hair's Blog

Build Machines and Test Machines

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

Comments

This work is licensed under a Creative Commons License.