Best practices for deploying tools & scripts to production?

Question

I\'ve got a number of batch processes that run behind the scenes for a Linux/PHP website. They are starting to grow in number and complexity, so I want to bring a small amount o

Answer 1

There are a several categories of tool here. Some people use a combination of tools from these categories. I sometimes use, for example, both Puppet and Capistrano. See Puppet or Capistrano - Use the Right Tool for the Job for a discussion.

Scripting Tools aimed at Deploying an Application:

The general pattern with tools in this category is that you create a script and/or config file, often with sets of commands similar to a Makefile, and the tool will ssh over to your production box, do a checkout of your source, and run whatever other steps are necessary.

Tools in this area usually have facilities for rollback to a previous version. So they'll check out your source to releases/ directory, and create a symbolic link from "current" to "releases/" if all goes well. If there's a problem, you can revert to the previous version by running a command that will remove "current" and link it to the previous releases/ directory.

• Capistrano comes from the Rails community but is general-purpose. Users of Capistrano may be interested in deprec, a set of deployment recipes for Capistrano.
• Vlad the Deployer is an alternative to Capistrano, again from the Rails community.
• Write your own shell script or Makefile.

Options for getting the files to the production box:

• Direct checkout from source. Not always possible if your production boxes lack development tools, specifically source code management tools.
• Checkout source locally, then tar/zip it up. Use scp or rsync to copy the tarball over. This is sometimes preferred for something like an Amazon EC2 deployment, where a compressed tarball can save time/bandwidth.
• Checkout source locally, then rsync it over to the production box.

Packaging Tools

Use your OS's packaging system to generate packages containing the files for your app. Create a master package that has as dependencies the other packages you need. The RubyWorks system is an example of this, used to deploy a Rails stack and sample application. Then it's a matter of using apt, yum/rpm, Windows msi, or whatever to deploy a given version. Rollback involves uninstalling and reinstalling an old version.

General Tools Aimed at Installing Apps/Configs and Maintaining a Set of Systems

These tools do not specifically target the problem of deploying a web app, but rather the more general problem of deploying/maintaining Apps/Configs for a set of servers, or an entire company's workstations. They are aimed more at the system administrator than the web developer, though either can find them useful.

• Cfengine is a tool in this category.
• Puppet aims to improve on Cfengine. It's got a learning curve but many find it worth the time to figure out how to do the configs. Once you've got it going, each box checks the central server periodically and makes sure everything is up to date. If someone edits a file or changes a permission, this is detected and corrected. So, unlike the deployment tools above, Puppet not only puts files in the right place for you, it ensures they stay that way.
• Chef is a little younger than Puppet with a similar approach.
• Smartfrog is another tool in this category.
• Ansible works with plain YAML files and does not require agents running on the servers it manages

For a comparison of these and many more tools in this category, see the Wikipedia article, Comparison of open source configuration management software.