Release Management Software

December 7, 2006 2:04 PM

I'm looking around for a simple tool to help manage file pushes to a website/web application. Is there such-a-thing as "Release Management" software?

To clear up some of the vagueness, I'm looking for something like this. A group of developers wants some files put online. They go to this theoretical tool, create a ticket, enter their file paths/repository-location into a form, along with any config file changes or other information.

Then, the Release Manager would go to this tool and have all the information they'd need to push the wanted changes live, possibly with some options to automate the file push. (In a crazy universe, a tester would look at it too!)

Does such a beast exist? It seems like the kind of thing programmers would have tried to solve 1000 different ways in-house, meaning there might be one or two decent products out there. I'm just not sure what to search on.

I'm aware of general ticketing systems like RT, but I'm looking for something that's specifically geared towards release managements.

Any suggestions or pointers towards things to look at are appreciated. Any "Why don't you just build it in Ruby on Rails" responses will be ignored. (-;

posted by alan to computers & internet (9 comments total)

Sun N1 Provisioning does a good chunk of this, but it's a bizarre product that Sun acquired and as such has all sorts of odd Windows-y stuff in it and comes with a process model that may or may not map usefully to your own -- possibly not, considering that your idea of a release manager is someone who actually deploys stuff.
posted by majick at 2:15 PM on December 7, 2006

Yeah, "deployment manager" may be a better term for what I'm looking for.

Or even more specifically, "keeps developers from hosing production manager".
posted by alan at 2:43 PM on December 7, 2006

Not that you have to build your site itself in Ruby on Rails, but I believe you can use the related application deployment package Capistrano even with other languages and CMSes, given a little tweakage.
posted by letourneau at 2:51 PM on December 7, 2006

I'm not totally sure I understand your situation, but why can't you just use source control for this? Your developers check in their code, and your Release Manager handles labeling versions and pushing them out to production.
posted by mkultra at 2:53 PM on December 7, 2006

Using scm systems for this is a pretty common approach. But be prepared to get into handling lots of branches. Typical approach is to devel in the head of the system, and branch (or at least "tag") for stable branches. Then just deploy the code from the scm onto production. This doesn't tend to work as well on apps that deploy in a significantly different way than they are developed (aka, most things) however.

Another approach is to package the web app software likes it's a real app and update it the same way you update other apps (especially if your on a system with strong packaging concepts like most linuxes). The big issue with that approach tends to be managing db schema changes. But thats always a bit of a headache, especially if data migration is called for.

Benefits for the latter approach are you can easily inventory what software is installed. It's versioned, and can include dependency info so you don't miss anything. Depending on the packaging system, it can also be used to insure consistent builds and build environments.

It's a bit more work to properly package the apps this way, but I think it's worth it.
posted by alikins at 3:17 PM on December 7, 2006

mkultra, alikins: Good information and great for shops with a strong Software Development Culture/Source Control™, not so much for shops where

]$ svn update index.php
C index.php
Updated to revision 1234.

can send a developer into spirals of hopelessness.
posted by alan at 4:18 PM on December 7, 2006

It doesn't have to be quite so bad- there are GUIs for any major package these days.

At the end of the day, though, you have to force the process on your developers. They'll fight you, but the world does not revolve around their convenience.
posted by mkultra at 6:20 PM on December 7, 2006

CruiseControl?

It's touted for it's continuous builds, but you can (and I have) integrated it to deploy webapps too. Not sure about parametising builds, but no doubt it could be done with a bit of tinkering.
posted by furtive at 6:24 PM on December 7, 2006

Given your svn caveats, this may not be much help, but we

1. Tag each of our builds in Subversion (copy the contents of /trunk to /tag/[version#])
2. Run a build script through NAnt to compile the contents of that tag
3. Use BeyondCompare to move any changed files live

My preference would be to have a DAV connection to the live servers and do the whole thing through svn, but it's baby steps here. Obviously you don't need step 2 if your code isn't compiled. We do a few other things for paths and stuff like that though, so you may want to keep that step.

In sum, we have a three-step process for what should be one double-click, but we're getting there. The Tortoise Windows client makes the svn process a lot easier for us.
posted by yerfatma at 8:15 AM on December 8, 2006