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.