|Software development process|
A software developer at work
- compiling computer source code into binary code
- packaging binary code
- running automated tests
- deploying to production systems
- creating documentation and/or release notes
Historically, developers used build automation to call compilers and linkers from inside a build script versus attempting to make the compiler calls from the command line. It is simple to use the command line to pass a single source module to a compiler and then to a linker to create the final deployable object. However, when attempting to compile and link many source code modules, in a particular order, using the command line process is not a reasonable solution. The make scripting language offered a better alternative. It allowed a build script to be written to call, in a series, the needed compile and link steps to build a software application. GNU Make also offered additional features such as "makedepend" which allowed some source code dependency management as well as incremental build processing. This was the beginning of Build Automation. Its primary focus was on automating the calls to the compilers and linkers. As the build process grew more complex, developers began adding pre and post actions around the calls to the compilers such as a check-out from version control to the copying of deployable objects to a test location. The term "build automation" now includes managing the pre and post compile and link activities as well as the compile and link activities.
New breed of tools
In recent years, build management tools have provided even more relief when it comes to automating the build process. Both commercial and open source tools are available to perform more automated build and workflow processing. Some tools focus on automating the pre and post steps around the calling of the build scripts, while others go beyond the pre and post build script processing and also streamline the actual compile and linker calls without much manual scripting. These tools are particularly useful for continuous integration builds where frequent calls to the compile process are required and incremental build processing is needed.
Advanced build automation
Advanced build automation offers remote agent processing for distributed builds and/or distributed processing. The term "distributed builds" means that the actual calls to the compiler and linkers can be served out to multiple locations for improving the speed of the build. This term is often confused with "distributed processing".
Distributed processing means that each step in a process or workflow can be sent to a different machine for execution. For example, a post step to the build may require the execution of multiple test scripts on multiple machines. Distributed processing can send the different test scripts to different machines. Distributed processing is not distributed builds. Distributed processing cannot take a make, ant or maven script, break it up and send it to different machines for compiling and linking.
The distributed build process must have the machine intelligence to understand the source code dependencies in order to send the different compile and link steps to different machines. A build automation tool must be able to manage these dependencies in order to perform distributed builds. Some build tools can discover these relationships programmatically (Rational ClearMake distributed, Electric Cloud ElectricAccelerator), while others depend on user-configured dependencies (Platform LSF lsmake)
Build automation that can sort out source code dependency relationships can also be configured to run the compile and link activities in a parallelized mode. This means that the compiler and linkers can be called in multi-threaded mode using a machine that is configured with more than one core.
Not all build automation tools can perform distributed builds. Most only provide distributed processing support. In addition, most products that do support distributed builds can only handle C or C++. Build automation products that support distributed processing are often based on make and many do not support Maven or Ant.
The deployment task may require configuration of external systems, including middleware. In cloud computing environments the deployment step may even involve creation of virtual servers to deploy build artifacts into.
The advantages of build automation to software development projects include
- Improve product quality
- Accelerate the compile and link processing
- Eliminate redundant tasks
- Minimize "bad builds"
- Eliminate dependencies on key personnel
- Have history of builds and releases in order to investigate issues
- Save time and money - because of the reasons listed above.
- On-Demand automation such as a user running a script at the command line
- Scheduled automation such as a continuous integration server running a nightly build
- Triggered automation such as a continuous integration server running a build on every commit to a version control system.
Requirements of a build system
- Frequent or overnight builds to catch problems early.
- Support for Source Code Dependency Management
- Incremental build processing
- Reporting that traces source to binary matching
- Build acceleration
- Extraction and reporting on build compile and link usage
- Generate release notes and other documentation such as help pages
- Build status reporting
- Test pass or fail reporting
- Summary of the features added/modified/deleted with each new build
- Continuous integration
- Continuous delivery
- List of build automation software
- Product family engineering
- Release engineering
- Software configuration management
- Unit testing
- Dr. Dobb's Distributed Loadbuilds, retrieved 2009-04-13
- Dr. Dobb's Take My Build, Please
- LSF User's Guide - Using lsmake, retrieved 2009-04-13
- Amies, Alex; Zou P X; Wang Yi S (29 Oct 2011). "Automate development and management of cloud virtual machines". IBM developerWorks (IBM).
- Mike Clark: Pragmatic Project Automation, The Pragmatic Programmers ISBN 0-9745140-3-9