ABCs of BPD (Build, Package and Deploy)


Build Types

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.

About the author

Mario  Moreira's picture Mario Moreira

Mario Moreira is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “Adapting Configuration Management for Agile Teams” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “Software Configuration Management Implementation Roadmap.” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!