One-Click Release Management

How a large development project on a tight release schedule and a tight budget can use open source to tackle the problems of version control and release management.

Say you have a large piece of software, a complicated Web site or a whole bunch of little ones. You also have a gaggle of coders and a farm of machines on which to deploy the end product. Worst of all, the client insists on a short turnaround time for critical changes. Proprietary products that may provide you with a systematic, unified development, testing and deployment process typically are expensive and offer limited deployment options. They often require new hardware resources and software licenses simply to support installation of the system itself. Such a solution can be difficult to sell to managers who are concerned about cost and to developers who are concerned about learning a new and complicated process.

However, managing the development process from end to end on a tight schedule without such a unified approach can lead to serious inefficiencies, schedule slippage and, in general, big headaches. If you're the administrator of such a project, chances are you're spending a lot of time dealing with the management of code releases. On the other hand, you already may be using an expensive piece of proprietary software that solves all of your problems today, but the higher-ups are balking at the ever-increasing license renewal fees. You need to present them with an alternative. It's also possible that you release code only once a year and have more free time than you know what to do with, but you happen to be an automation junkie. If any of these scenarios seem familiar to you, read on.

The Solution

Various open-source products can be adapted to minimize costs and developer frustration while taming your out-of-control release process by serving as the glue between existing toolsets. Maybe you even can start making it home in time to play a round or two of Scrabble before bedtime.

I base the examples presented in this article on a few assumptions that hopefully are common or generic enough that the principles can be extrapolated easily to fit with the particulars of a real environment. Our developers probably already use a bug-tracking system (BTS), such as Bugzilla, ClearQuest or Mantis, or an in-house database solution to track change requests and bugs. They also may be using a version control system (VCS), such as Arch, CVS or Subversion, to manage the actual code changes called for in various BTS entries.

If they're not using a BTS and a VCS for a large project, these developers probably have either superhuman organization skills or a high level of tolerance for emotional trauma. Which BTS and VCS we use is not essential to this discussion, and any exploration of the pros and cons between one system and another requires much more text than I am allotted here. In short, they all should support the building blocks needed for the type of process we'd like to employ. Namely, most any BTS can:

  1. Assign a unique ID to all issues or bugs in its database.

  2. Allow you to use the unique ID to track the state of an issue and store and retrieve a listing of any source files it effects.

Any VCS worth its salt (sorry VSS fans) can:

  1. Allow some form of branching and merging of a central code hierarchy.

  2. Allow a command-line client process to connect over a secure network connection in order to perform updates.

We use a Subversion (SVN) repository with the SVN+SSH access method enabled as our VCS and a generic MySQL database table as the BTS. We use Python, which tends to be quite readable even for the novice programmer, as our scripting language of choice. Chances are your distribution has packages for all of these products readily available; configuring them will be left as an exercise for the reader. The target machines are generic Web servers, all of which support SSH connections as well as the VCS client tools.

Here's the 10,000-foot overview of the example end-to-end process we are likely to be starting out with:

  1. An issue is generated in the BTS and is assigned an ID of 001 and an initial status of “new”. It includes, or will include, a listing of file paths that represent new or changed files within the VCS repository and is assigned to the appropriate developer.

  2. The assignee developer makes changes to his local copy of the source code, checks these changes into the VCS repository and updates the status of BTS ID# 001 to “in testing”.

  3. The testing server is updated with the new changes.

  4. A QA tester charged with reviewing all BTS items with a status of “in testing” verifies that the changes to the code are what is desired and updates the status of BTS ID 001 to “ready for production”.

  5. A release manager then packages all changes affected by BTS ID# 001 into a release and updates the status of BTS ID# 001 to “in production”.

  6. The live server is updated with the changes.

For the most part, we're managing to fix bugs and add new features to the code base without bugging the system administrator for much, aside from the occasional password reset or RAM upgrade. But steps 3 and 6 require us somehow to get the code out of the VCS and onto a live system. We could cut and paste files from the VCS into a folder on our hard drive, zip it up, send it to the sysadmin and ask him to unzip it on the live system. Or, we could take advantage of the structure of our VCS and its utilities to do the work for us and completely avoid having a conversation with the administrator, whose time tends to be a hot commodity.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Regarding some big tips about software release process

Anonymous's picture


I am Justin, i am a Indian Citizen and I am a SCM Analyst in one of the IT Company, and i would like to say which you have updated all very fine.

1. Could you please some of the Brief explaination need, step by steps procedure of Software Build release process?

2. What are the basic things needs as a release manager which we are needs to be taking care of software release Process and what information should capture while doing software release?

3. What are the basic steps should involved for the following scenario.... We have 10 changes done in 3 branches but we had an 3 errors on those changes, what are the steps to implement to solve this 3 errors?

waiting for the favorable reply

SCM Analyist

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot