Ryan Rinaldi
Ryan Rinaldi

Reputation: 4239

App build/deployment workflow

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)

Upvotes: 18

Views: 1384

Answers (8)

Tom Anderson
Tom Anderson

Reputation: 47243

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

Upvotes: 0

Matt Ryall
Matt Ryall

Reputation: 10595

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.

Upvotes: 2

Ryan Berger
Ryan Berger

Reputation: 9732

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.

Upvotes: 1

rasjani
rasjani

Reputation: 7970

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.

Upvotes: 2

Eldelshell
Eldelshell

Reputation: 6960

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.

Upvotes: 3

David T
David T

Reputation: 31

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.

Upvotes: 2

Dan
Dan

Reputation: 11183

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

Upvotes: 2

Gilbert Le Blanc
Gilbert Le Blanc

Reputation: 51565

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.

Upvotes: 2

Related Questions