Best Practices for Code/Web Application Deployment?

Question

I would love to hear ideas on how to best move code from development server to production server.

A list of gotcha's, don't do this list would be helpful.

Any tools to help automate the steps of.

1. Make backups of existing code, given these list of files

2. Record the Deployment of these files from dev to production

3. Allow easier rollback if deployment or app fails in any way...

I have never worked at a company that had a deployment process, other than a very manual, ftp files from dev to production.

What have you done in your companies, departments, etc?

Thank you...

Yes, I am a coldfusion programmer, but files are files, and this should be language agnostic question.

Answer 1

OK, I'll bite. There's the technology aspect of this problem, which other answers have already covered. But the real issue is a process problem. Where the real focus should be ensuring a meaningful software development life cycle (SDLC) - planning, development, validation, and deployment. I'll cover each in turn. What you want is a repeatable activity at each phase.

Planning

Articulating and recording what's to be delivered. Often tickets or user stories are enough. Sometimes you do more, like a written requirements document, that a customer signs off on, that's translated into various artifacts such as written use cases - ultimately what you want though is something recorded in an electronic system where you can associate changes to code with it. Which leads me to...

Development

Remember that electronic system? Good. Now when you make changes to code (you're committing to source control right?) you associate those change with something in this electronic system - typically tickets. I like Trac, but have also heard good things about Atlassian's suite. This gives you traceability. So you can assert what's been done and how. Then you can use this system and source control to create a build - all the bits needed for whatever's changed - and tag that build in source control - that's your list of what's changed. Even better, have a build contain everything, so that it's standalone entity that can easily be deployed on it's own. The build is then delivered for...

Validation

Perhaps the most important step that many shops ignore - at their own peril. Defects found in production are exponentially more expensive to fix then when they're discovered earlier in the process. And validation is often the only step where this occurs in many shops - so make sure yours does it.

This should not be done by the programmer! That's like the fox watching the hen house. And whoever is doing is should be following some sort of plan. We use Test Link. This means each build is validated the same way, so you can identify regression bugs. And, this build should be deployed in the same way as you would into production.

If all goes well (we usually need a minimum of 3 builds) the build is validated. And this goes to...

Deployment

This should be a non-event, because you're taking a validated build following the same steps as you did in testing. Could be first it hits a staging server, where there's an automated copying process, but the point being is that is shouldn't be an issue at this point, because you validated with the same process.

Conclusion

In terms of knowing what's where, what you really want is a logical way to group changes together. This is where the idea of a build comes in. It's really the unit that should segue between steps in the SDLC. If you already have that, then the ability to understand the state of a given system becomes trivial.

Answer 2

Check out Ant or Maven - these are build and deployment tools used in the Java world which can help you copy / ftp files, backup and even check out code from SVN.

You can automate your deployment steps using these tools, for example Ant will allow you declare a set of tasks as part of your deployment. So you could, for example:

1. Check out a revision using SVNAnt or similar to a directory
2. Copy (and perhaps zip first) these files to a backup directory
3. FTP all the files to your web server(s)
4. Create a report to email to the team illustrating the deployment

Really you can do almost anything you wish to put time into using Ant. Maven is a little more strucutred (and newer) and you can see a discussion of the differences here.

Hope that helps!