It used to be that reproducibility was the holy grail of build process and capabilities. While that is still the central requirement, good build management processes and tools can take you a lot further, a lot faster, and with better quality. The steps are the same: identify a build, select the updates (i.e. change packages) that are going into the build, create the build definition in the CM repository, and then click a magic button that causes the build to be built. Done.
Well, it doesn't really stop there. That build, or a subsequent one, has to make it out to production. That means there's going to be test cases run against it. Tech writers need to know what exactly is in the build so that they can document it. Product managers likewise need to know that the build has all of the required features and fixes, and that it of sufficient quality. Developers just want to test their own changes against the new build (which they probably created by themselves for themselves), so that they can correct them and repeat the process.
If you think deeply about a build - it's not just a set of executables/deliverables. There's a whole history of how it got there and a whole story about what's in the build.
What does Build Mean?
The term "Build" can take on more than one meaning, all around the same concept. Prior to a build taking place, there's the concept of "build" that means "Build Notice". Typically a Build Notice has a specific time in mind (possibly automated each day, hour, week, etc.) but may have either a rule-based (in the case of automation) or a manually specified content description, that is, what is going into the "build". The Build Notice, prior to the build is often referred to as the "build". In any next generation ALM tool, the current content definition should be a click or two away.
When a build has been completed, the record of what went into the build, the "Build Record" is also referred to as the "build". Because the context makes it clear that we're talking about a build in the past, the sense of the word deals with ensuring we have a record of what actually happened. In a next generation ALM tool, the build record itself may change over time - perhaps a scary thought if you've not been exposed to this, so we'll mention it in more detail below.
The Build Operation, that is, the compiling, linking, packaging, etc. is yet another meaning often inferred by the word "Build". Often you'll hear: "That broke the build", meaning that broke the Build Operation so that it couldn't complete.
And the fourth use of the work Build is to refer to the artifacts produced by the build. These are the executables, help files, or more generally, deliverables, in whatever form the build leaves them. It's common to hear: "What build were you using?" So to summarize, we have at least 4 common meanings for the term "Build"
1. Build Notice - used to refer to a Build in the future
2. Build Record - used to refer to the record of what went into the build
3. Build Operation - the procedure used to generate the build artifacts, and
4. Build Artifacts - the deliverables produced by the build operation.
With all of these meanings, you'd think that there would be a lot of confusion. But the context almost always makes the meaning clear. That, and the fact that we're really talking about the same thing, but just from