TooliX Release Engineering Philosophy

Author: Manny DaSilva

Find out if your organization can benefit from TooliX's build/release engineering infrastructure products and services. This white paper reviews the various aspects of build/release engineering that TooliX feels are key to the success of any software product release organization.

Introduction

You have a great software product, but it just takes forever to get it built, tested and shipped. Why? Why is product release such a hassle? The answer is buried somewhere in the build/release engineering process that nobody cares to understand yet relies so much upon. Build/release engineering is a critical part of the overall software engineering process, yet many software companies pay little attention to its beginnings and/or on-going health. Its usually band-aided to the point where it becomes so unhealthy as to jeopardize the company's bottom line.

Many companies find that they've grown into their build process with very little planning or forethought or have overlooked it altogether. This may be the case in any organization, large or small, old or new. The day-to-day development activities take precedence and there is little time to design a reliable, repeatable process to build the product.

While often overlooked, the build process is certainly not unimportant and can make or break the desired end result of a company's development activities - getting product out to customers in a timely manner.

We Want Our Builds (And Test Media Too!)

Much has been said and written about Release Engineering and Software Configuration Management. This includes various theories on process and best practice methods. However, when everything is said and done, the one thing that we can not escape is that ultimately release engineers must produce product. This is the one thing that remains constant. Managers and developers alike want clean, repeatable builds, media kits ready for test installs and gold masters for duplication. This is where "the rubber hits the road".

Today's product release environment is a multi-platform, heterogeneous one that demands a robust, flexible toolset. One process across all platforms ensures that it's the work at hand that release engineers focus on and not the details of how each platform behaves. Other key features of a robust product release process include:

Generic wrappers around platform specifics for multi-platform
Multi-user/role tools to take advantage of synergy between developers and release engineers alike
Table/key-driven mechanics - hide the complexity and focus on the data - highly customizable
Web-ready - deploy the tools to your intranet
Built-in tool auditing for rapid debugging
Built-in process statistics for capacity planning
Self documenting using a familiar UNIX-style man page for accurate documentation/communication/training of process
Take advantage of ready-made tools like GNU/MKS Shell Toolkits and other tools like Make, Perl, etc.
Reduce porting (yes, that's right) - and increase heterogeneous development - painful but highly rewarding in the end
Share (as much as possible) source code between heterogeneous platforms
Split source and build targets in two and take advantage of the ability to build debug vs. release products
One common build environment for multiple compile languages
Plan up front for multiple compilers (e.g.. MSVC++5 MSVC++6)
Plan up front for multiple OS versions
Encapsulate "build methods" to only one project Makefile - "one-stop-shopping" for how projects build
Build "top-down" - build only those things that have changed and therefore need building - saves time
Recover and/or run parts of the build without negatively impacting other parts - the least impact the better
Run "what-if" builds that give impact analysis without actually producing output
Build both debug and release targets - developers will be much more productive
Built-in "triage" greatly improves build failure reporting, investigation and recovery
Built-in media kit building process for rapid build availability to QA
Validate media kit Bill-of-Materials

This vision of a build/release engineering infrastructure is simple: do it right (in the first place). Engineer the release engineering infrastructure/environment just like it was any other software system - because that's what it is. The more robust, flexible and feature rich it is, the better the chances are that release engineering will make a positive impact on the overall health of a company.

[ | | | | ]