Home
SCM Blog
SOX
Build
Agile
CMMI
Six Sigma
ITIL
Sftwr Engineering
Software Testing
Config Mgmt
Release Mgmt
SDP
Subversion
Source Code
Forrester Reports
SCM Jobs
SCM Salaries
Contact Us
SCM EZine
FDD
Disaster Recovery
SCM War Stories

[?] Subscribe To
This Site

XML RSS
Add to Google
Add to My Yahoo!
Add to My MSN
Add to Newsgator
Subscribe with Bloglines

Software Build

Definition

Software building, otherwise known as integration, is the process of taking all source code files that make up an application and compiling them into build artifacts, such as binaries or executables.

History

During early software development, even small software projects were easily compiled into a small number of computer executables. However, larger software projects were not so easily assembled.
Build Best Practices

Continuous Integration

CruiseControl

Automated Build Process

Maven Project

It was not just a matter of compiling the individual components of an application, but the linking them together. This is the process of telling the individual compiled components where to find things they require or depend on to run.

During the early days of software development, these were normally manual steps after the compilation. In large software applications, this could take a tremendous amount of effort and time. Which would lend itself to human error.

It did not take long to realize building needed to be automated just like the compiling. Software building is the process of documenting and automating these steps.

Just like the maturity of the actual software building process. A maturity of the software development process was underway.

Early software engineering processes flowed from the traditional engineering practices. The phased approach to software engineering was often employed.

Requirement->Development->Building->Testing->Release

One of the long standing problems for software development teams have been the integration of the new code and the stability of the application. In the early days of software engineering, the integration could be so unpredictable and painful that many development teams would put off integration until the end.

There were many reasons for this, larger development teams would be comprised of many smaller isolated development teams. In an effort to complete their individual pieces, they would work in isolation.

In addition, these teams often would not communicate between themselves. This procrastination would lead to the problem, that no one could accurately predict how long it would take to complete the integration.

Often when the other development teams would try to integrate with the newly delivered code, they would have to do major reengineering of their code.

This could be a very long and time consuming process.

There are other issues with this serial approach, it blocked any testing that could be done during the early part of the development process. With speed-to-market becoming so important in the competitive world of software, development required a more iterative approach.

As development practices matured and improved, a more iterative approach to software development emerged.

A paradigm shift moved the integration phase from after the coding phase to happen in parallel. This also happened for testing. This dramatically reduced the overall timeline for software development and increased the stability of the code during the development process.

The Build

Build automation is the process of combining all the steps necessary to compile the source code into build artifacts into a one step process. This can include many different types of tasks depending on the technologies involved.

Software Build Best Practices

  • Build Early and Build Often

  • Fully Automate the Build Process

  • Daily full system builds

  • Continuous Integration builds

  • Creating a repeatable build process

  • Using a secure and dedicated build server

  • Building in a clean workspace

  • Require all necessary files be checked-in prior to the build

  • Label the source code in each build with a unique identifier.

  • Create a BOM, bill of materials, of the source code versions for each build

  • Create a build manifest of the build artifacts.

  • Create and keep your build logs

  • Send build status emails

  • Track release baselines Software Build Best Practices

    Although, the term Continuous Integration is relatively new, the concept has been around software development companies for decades. Many organizations developed internal tools that would produce the builds upon the check in of code.

    For more in depth discussion Continuous Integration


    footer for Software Build page