Build Process Top Ten Tips
Filed under: deployment build automation build scripting release build process
There are 0 comments on this article.
Introduction
Although no two build processes are ever the same, there are always a few generic themes or ideas that seem to run through them. This has led me to document and recommend the following top tips! There are certainly other aspects of the build process which are important and I'm sure you could define a few more top tips from your own environment - if you do make sure to send them to me. However, the tips that seem to be most consistent to me are (in no particular order) as follows:
- Create a dedicated workspace for building in
When you are executing an integration or releasebuild, you should do so in a clean and controlled environment. The best way to achieve this is to create a dedicated build workspace. This workspace should be synchronized with the development environment before building. This can beto either the latest set of development changes (for an integration build) or to a specific baseline (for a release build). You should use different build workspace for different releases of your projects or applications. Most SCM tools have a capability to achieve this, in CVS/Subversion it is called a workspace or working copy, however in ClearCase a workspace is realized by a ClearCase View.
- Use a standard project directory structure
If you are going to build multiple projects or applications you should agree on a standard directory structure. This should include aspect of the build process such as where the source and test components will reside, where the build outputs will be created, what the build scripts should be called and so on. A good example of a project directory structurefor buildingjava applications can be seen with Apache Maven.
- Implement a single consolidated set of build scripts
Any build scripts that you implement should be usable by all members of your development team, whether they be developers executing private builds in theirIDE (Integrated Development Environment)or by build engineers executing a release build from the command line or a management console. Your build scripts should be consistently named and be in a known location (as in2 above), they should be well documented and also have different entry points for the different team members. A number of Enterprise Build Control tools (such as IBM Rational Build Forge, ElectricCloud ElectricCommander or Viewtier ParaBuild) present this information via a management console, allowing different classes of users different access rights but executing the same fundamental scripts.
- Baseline before and/or after each build
The decision of whether to baseline before or after each build is often down to personal or project preference, however you should baselinein at least one of these cases. Baselining before the build allows you assess and revert to the inputs of the build process. Baselining after the build allows you to also baseline the outputs from the build process, for example your versioned executables or libraries. If your SCM tool also implements baseline promotion levels, you can use this capability to promote the level or maturity of the build baseline when the build has been successful.
- Separate build script logic from data
Build scripts can quickly become large and unwieldy; if you are going to keep them maintainable and usable by different members of your team (as in3 above), you should separate out any configuration data from your build scripts. With a scripted build process this typically means creating a separate data file along side your main build scripts. The first thing that the build scripts do is then read in this data to initialize variables and the environment. The entries in this data file can then be overridden by different members of the development team as and when needed. An example of this is Apache Ant and the convention of using default.properties and build.properties files. A number of Build Control tools also allow you to create different "environment groups" in their databases for this configuration data. You can then apply this environment to the standard execution of the build scripts.
- Create a library of reusable build script routines
Developers always implement code routines to save time and promote sharing and re-use - build scripts should be no different. Most build scripting tools support some form of import, includeor macro capability. Create a standard set of routines that contain operations such as creating project directory structures, executing unit test suits, or SCM functions such as applying baselines. Place these routines in a a separate file and then "import" them in your main build file. The acid test is whether the same set of routinescan be imported into another project's main build file without change. Examples of such an import capability is the GNU make include function or the Apache Ant import task. A similar capability is available in a number of Build Control tools, where you can create project "templates" in their database and implement instances of these "templates" for executing different project builds.
- Treat your build scripts as first class citizens
Your build scripts are an important development asset - without them you can't create or deploy any application! Consequently, you should treat them as first class citizens. This means version controlling them, documenting them and managing and assessing the impact of changes to them just as with any other development asset. Your build scripts should also be baselined (see4 above) alongside all your source and configuration data.
- Don't tie your build process to your IDE
Many modern development environments now allow developers to build (compile and test) their changes without creating build scripts - either automatically when changes are made or by clicking on a button. This can be a great productivity enabler, however you should not rely on this capability. The development environment often makes it easy toimplement buildchanges and consequently easy to make mistakes. Also, what if you have different developers using different environments or you want to change to a different one. In these cases, you should also script up your build process in a development environment neutral tool, such as GNU make, Apache Ant or MSbuild (for Microsoft Visual Studio Applications). These scripts should be used by build engineers for conducting release builds and can also be executed automatically by scheduling tools. Developers should also execute the same set of scripts before they deliver into an integration build to ensure that their changes will build consistently. Some Build Control tools also allow developers to validate their changes as part of a "pseudo" integration build;this will run their changes through the same essential process there is more likelihood of the full integration build succeeding when they do commit them.
- Automate build script invocation and report generation
Don't rely on people to execute your build scripts, as people can make mistakesand more importantly might not be around at times when you want your build scripts to be run, i.e. overnight. Instead make use of some mechanism to automate the execution of your build scripts. This is particularly true for integration builds, and techniques such as Continuous Integration where you might be building many times a day. Take advantage of a Build Control tools such as CruiseControl, IBM Rational Build Forge or ParaBuild. At the same time, automate the execution ofany build reports, such as unit test reports, baseline reports or change logs. This will enable consistent and reliable updates on the progress of the build and development process as a whole.
- Reduce build execution times using build avoidance or distribution techniques
If your build takes a significant amount of time to execute from beginning to end, then take advantage of tools which offer build avoidance ordistribution techniques. Such tools allow you to execute your builds quicker and more regularly. The benefits of regular feedback from the integration of software components in the form of an executablebuild should never be underestimated. An example oftools that support build avoidance and/or distribution are the ClearCase clearmake tool, IBM Rational BuildForge or ElectricCloud ElectricAccelerator. If you can't physically reduce the time to build all of your files, then implement build pipelines. This is where you stage the binary outputs of a project and then subsequent projects re-use these outputs without recompilation.
If you have any of your own tips, then please feel free to comment on this article and add them below.