One-Click 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.
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:
Assign a unique ID to all issues or bugs in its database.
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:
Allow some form of branching and merging of a central code hierarchy.
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:
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.
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”.
The testing server is updated with the new changes.
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”.
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”.
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.
- An Introduction to Tabled Logic Programming with Picat
- Ubuntu MATE, Not Just a Whim
- Build Your Own Raspberry Pi Camera
- Nasdaq Selects Drupal 8
- Non-Linux FOSS: Screenshotting for Fun and Profit!
- Secure Desktops with Qubes: Compartmentalization
- Canonical Ltd.'s Ubuntu Core
- A New Mental Model for Computers and Networks
- Getting a Windows Refund in California Small Claims Court
- The Peculiar Case of Email in the Cloud