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.