Many organizations treat release management as a nonexistent field or an “also-ran.” Reproducibility is near the bottom of the list of concerns, let alone thinking about other parts of the discipline. But, release management fundamentals still apply regardless of the size or type of your organization. By starting with centralized distribution, an organization can make massive strides towards managing releases.
Understanding Centralized Distribution
Centralized distribution means there's a single, known source for distributables. It means that nothing is released without hitting the named server and that customers can never have a patch, a file, a complete install, or even a document that has not been sent to the centralized distribution server. Further, through centralized distribution, you help ensure that an organization has a single source of truth for its binaries, much like revision control is for sources. Most importantly, it means that everything sent to the customer (distributables) can be tracked down to a single source.
This doesn't mean that all files are distributed from a single server or over a single protocol. Rather, centralized distribution means that all distributables are made available from a single known system, presented to users as if the distributions are centralized. This system could be a single desktop, a server with a SAN, or even six servers acting together, sharing files over HTTP, RSYNC, FTP, and every other protocol under the sun. The mechanism doesn't matter nearly as much as the fact that distribution is centralized—that nothing releases outside of this single source of truth.
Starting at the Beginning
Centralized distribution is easy to achieve even if the build process isn't reproducible, automated, or existent. Simply place all binaries on a single server. Whether developers copy files or the build process automatically does it for you, the end result is the same: "Where do I get it?" conversations go away. Communication immediately flows more easily, and builds no longer have to be passed around.
Improving Your Distribution
Ideally, build systems would be responsible for ensuring that distributables end up on the central server. Centralizing distribution in the following way can also help reduce development time by simplifying the aftermath of a build. Every company has a different concept of build, but most agree on the notion of source code compiling executables. In an ideal world, a build would produce at least the following outputs:
- Cut—The entire build output, potentially for repackaging into an installer
- Installer Symbols—Whether you use PDBs (C#) or pre-stripped binaries (C++), having symbols around from a production build reduces the time developers have to spend rebuilding the product.
- Documents—All PDFs or text files that would be released with the product. This forces revision control for documentation as well.
- Logs—Even after the fact, build logs are surprisingly useful.
- Build details file—A file (in my case an INI, since it's cross-platform and nearly all languages have a great INI support) with details about the build: build server, source location (revision control), revision, build date, and build number.
Tracking Sources of Distribution
Regardless of what ends up in distribution, we need the ability to know where it came from. More importantly, we're probablygoing to want to do something with that data programmatically, so having reasonably generic cross-platform access is key.
This is where we reuse the ancient technology called property files.
Property files are files of the format variable=value, with each variable appearing on its own line. In terms of build data, I like to store product name, revision control location, revision, branch, version, and date information. Here's an example:
product=My Mythical Product
As property files are easy to