In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
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.
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 an entire 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. This is, 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 the build operation was broken so that it couldn't be completed.
The fourth use of the word 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?" To summarize, we have at least 4 common meanings for the term build:
1. Build notice: a build in the future
2. Build record: the record of what went into the build
3. Build operation: the procedure used to generate the build artifacts
4. Build artifacts: the deliverables produced by the build operation.