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.

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.

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!

In a nutshell...

You should start with some source control solution - probably Subversion or Git. Once that's in place you can create a script that generates a clean build of your source code and deploys it to your production server(s).

You could do this with a simple batch script or use something like Ant for more control. Here is a simple example of a batch file using Subversion:

svn copy svn://path/to/your/project/trunk -r HEAD svn://path/to/your/project/tags/%version%
svn checkout svn://path/to/your/project/trunk -r HEAD //path/to/target/directory

Ant makes it easy to do things like automatically run unit tests and sync directories. For example:

<sync todir="//path/to/target/directory" includeEmptyDirs="true" overwrite="true">
  <fileset dir="${basedir}">
    <exclude name="**/*.svn"/>
    <exclude name="**/test/"/>
  </fileset>
</sync>

This is really just a starting point. A next step might be a continuous integration solution like Hudson. I would also recommend reading "Pragmatic Project Automation: How to Build, Deploy, and Monitor Java Applications".

One ColdFusion specific gotcha is to make sure you clear the Application scope when required (to update any singleton components). A common approach here is to use a URL parameter that causes onRequestStart() to call onApplicationStart(). You may also have to clear the trusted cache.

We use a system called AnthillPro: http://www.anthillpro.com

It's commercial software, but it allows us to completely automate our deployment process across multiple servers and operating systems (We currently use it for both ColdFusion and Java, but it can be used for most languages. It has a ton of 3rd party integrations:

http://www.anthillpro.com/html/products/anthillpro/tool-integrations.html