Managing and Tracking Distributables

[article]
Summary:
No matter how big or small your project, or even your organization as a whole, release management simply cannot be overlooked. Learn how centralized distribution, when focused on from the beginning, can make everyone's job easier, in order to give your customers a better finished product.

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

source=http://git.myproduct.com/thisrepo

branch=master

revision=1234567

date=2011-07-09-17:55

As property files are easy to

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

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

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

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03