Many in the software engineering world considers build, package, and deploy the core areas of Configuration Management (CM). To highlight this, many CM jobs are titled “Build Engineer” or “Release Engineer” with responsibilities that focus on the tasks of building, packaging, and deploying releases.

Private builds – A Private build is described as an individual developer working in isolation (private workspace) who builds their code separate from others. The Private build is typically against a baseline (or configuration) of code that changes regularly. Synchronizing recent changes (if this is appropriate) into the private workspace point in time the developer is testing against.
Integration build – An Integration build is described as individual code changes promoted into an integrated workspace and built together. If the result is a build with no errors that passes some (or all) level(s) of testing and meets the some (or all) level of requirements, the Integration build can be known as a test build or a release build. This is typically an evolutionary process.

Integration builds may be continuous (e.g., nightly, weekly, etc.) since this may reduce the effort of merging individual code changes and uncovering build issues sooner. The project or development manager should track the changes going into a build (particularly as the release date approaches).

Test build (sometimes known as QA builds) – A Test build is described as an Integration build with the goal of handing off the deliverables to the Test team to validate the functionality against stated requirements (which we hope are documented!). Validation may include regression tests, performance tests, and eventually user acceptance tests (which may be done by customers of the product).

Release build – A Release build is described as an Integration build with the goal of being released into ‘production’. It should have met the test criteria so it is now release ready and can be shipped to the customer. Effectively, a Release build always starts as an Integration build and follows the same build process. The Integration build will meet a milestone level of completeness (test build) and then the full requirements (release build). In many cases, a project team may not call it the Release build until they know that it has tested correctly. This is why it is important to label the build items after a successful build especially as the team approaches the release date. Also, in some cases as the release date is approached, all builds are called Release builds in hopes that one of them will pass appropriate tests and be deemed ready for release.

• Identify the items that need to be built (they should be in a common SCM tool repository)
  
• Begin the build (execute the specific build commands)
  
• Pipe all build output to a log file
  
• Review the build results & address any build issues (as appropriate)
  
• Optional: the build is smoke tested to validate that the core functionality runs properly
  
• If the build was successful and of significance (e.g., milestone, test, release):
  
  • Label the versions of the source code that was used in the build
    
• Note: since the build process is iterative (occurs very often), consider automating the build process as much as possible

• If the build deliverables had some significance (e.g., milestone, test, release), version control the deliverables from the build.
  
  • Note: this may be a step at the end of the build process
    
• Identify any other known items (scripts, database, configuration, documents, etc.) that will create a package of deliverables that can be run in test (then production).
  
  • Note: this may include version controlling some (or all) of these items preferably in the same code repository as the build deliverables.
    
• Collect the items together (e.g., ‘tar’ or similar function) into a identifiable draft package (items from the above 2 steps).
  
  • Note: this step should be automated – it is iterative and will occur until the package is validated for release.
    
• Create a draft release notes to accompany the draft package
  
• Migrate the draft package into an appropriate test region for validation (functional, system, regression, performance, user acceptance).
  
  • Validate the draft package. This is a test step.
    
• Incorporate (check-in) changes made to the draft package during testing into code repository so that the new ‘latest’ (a.k.a., release) package includes these changes.

• Finalize the release notes
  
• Submit a change request to the CCB to change the production baseline with the release package.
  
  • Collect supporting documents that indicate the readiness of the release (test reports, release notes, installation plan, backout and recovery plan, etc.)
    
• Review and authorize the release package
  
  • Review the change request and all supporting documents
    
• Determine disposition of release package (approve, reject, pending, etc.)
  
  • Address concerns
    
• If approved, communicate pending release package has been tested with release dates to stakeholders and support staff.
  
• Install release into ‘production’. Production may be media or production server(s) or client(s).
  
• Validate release package in ‘production’.
  
  • If media, this should include testing the installation process from media to production server and/or client as well as testing functionality once installed.
    
  • If production server or client, test functionality.
    
• Communicate that release is in production to all customers, stakeholders, and support staff

• “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing. Specifically the following sections:
  
  • Chapter 4, “6.6. Develop an SCM Build Process”
    
  • Chapter 4, “6.7. Develop an SCM Release Process”

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment