views:

229

answers:

8

What do you use to manage the workflow of deploying your application after the build completes? I'm not talking about just the act of getting files on a server, I'm talking about what happens after that. Verification, testing, approval, migration to production, retiring old builds, etc.

Example:

  1. Build completes
  2. Build is deployed to a test environment
  3. Testing is completed (manual step)
  4. If testing passes deploy to UAT else reject build
  5. UAT is completed (manual step)
  6. If UAT passes deploy to Prod else reject build
  7. Retire build previously in Prod

Any good applications out there that can manage long running build workflows?

Update

I should also mention that I'm looking for tooling that actually implements the workflow and not just to track what state it's in. (Copy build, change build status, send emails, start/stop services, etc)

+2  A: 

A lot of companies use a project scheduling application, like MS Project.

Here's an open source project scheduling application, Open Workbench, that you might find useful. It has limitations, but I've used it to manage my schedules.

Gilbert Le Blanc
+2  A: 

ThoughtWorks Go looks the part. We use Maven at the moment, but still at a fracion of its capabilities.

Dan
I looked at Cruise (Go's name pre version 2) and while it looked good we can't use it since it doesn't work with TFS. I downloaded and installed Go a few days ago but the services wouldn't start so I was unable to evaluate it any further.
Ryan Rinaldi
+2  A: 

I don't really see why this couldn't be done using Ant (http://ant.apache.org) with some tasks, one per step. Since the timing of these things is manual and each environment can only have one copy of the software at one time, there doesn't seem to be much to do but code the workflow and letting folks at it.

David T
+3  A: 

This build and release systems are a mixture of different stuff, so following your list I'll respond:

  1. Build completes (CruiseControl with Maven Build)
  2. Build is deployed to a test environment (Ant task, called from CruiseControl)
  3. Testing is completed (manual step) (Maven tells you this)
  4. If testing passes deploy to UAT else reject build (If the tests fail, Maven won't end, no call to the ant deployer)

From here on, we do it pretty much with a mixture of ant and bash scripts

  1. UAT is completed (manual step)
  2. If UAT passes deploy to Prod else reject build
  3. Retire build previously in Prod

The harder thing we've found was to restart our application servers since we haven't had good experiences with hot deployments but it's doable with only maven, ant and bash.

Ubersoldat
Apologies for not accepting this while the bounty was still active. I was busy getting married and forgot about my question. Hope you understand.
Ryan Rinaldi
No problem and live happily ever after.
Ubersoldat
+2  A: 

If you manage to automate your tests (and depending on what sort of software you do, there's no reason why not), you should be able to use any continuous integration software.

The thing is, each phase can be written down as tasks that can be executed one after an another depending of what was the result of previous case.

For example, i've had a setup of CruiseControl that does exactly what you describe here, testing phase was running bunch of unittests (c++/qt) and uat stuff was written with testability driver.

rasjani
+1  A: 

I've used a web-based open source tool called Hudson and have been very happy with it. It's very good at managing builds and has excellent integration with SVN and ant. The only caveat is that you need to host it on your own server.

Ryan Berger
We use Hudson for this. We run nightly and weekly builds, and builds to QA and acceptance triggered manually. The manual builds go from a CVS tag, so it's easy for a human to manage the high-level workflow: build to QA, if successful tell the QA team, wait to hear back from the QA team, if passed build to acceptance, if successful tell the UAT team, wait to hear back from the UAT team, if passed, tell the ops guys to build to production (which is triggered manually, but using the same scripts that Hudson runs). We don't automate the workflow, and i see no benefit to doing so (for us).
Tom Anderson
+2  A: 

As far as I know, there is no single system that will automatically do all the tasks you mention. You need to write some scripts and tests to automate the deployment of your system and its testing. Then you can use a CI server to put it together. Here's what I'd suggest:

  1. Automate your deployment process using a scripting language appropriate to your platform (e.g. Ant, shell scripts, batch files). That includes the tasks you mention:
    • uploading the binary to the target server
    • taking a backup of the system
    • sending an email to alert users to the upgrade
    • performing the upgrade by bringing down the system, changing a symlink to point to the new version, and starting it up again.
  2. Write some tests which can verify that the software is working in a particular environment. You need to be able to run these against your UAT and production server to verify that the software has been deployed and is running correctly.

Once you have these things automated, you can use a continuous integration server to schedule these tasks or do them on demand. I'm most familiar with Bamboo (I work for Atlassian), but I'm sure CruiseControl and Hudson have similar features. Here's how you'd do it in Bamboo:

  1. Create a new build plan for your UAT deployment, which executes your deployment script followed by the tests
  2. Decide how you want to trigger the build, by either:
    • adding it as a dependency on your main build, such that it runs automatically on a successful build
    • make it run on a schedule, so you get nightly deployments
    • make it only triggered manually, in which case you just run the build when you want it to be deployed.
  3. Configure the permissions for the build so only authorised users can deploy versions to your server.

You'd then do the same and set up a build for your production deployment, but probably with only manually triggering and with more restrictive permissions.

Matt Ryall
A: 

We use this old Welsh guy called Alistair. Works like a charm.

Tom Anderson