Most of the applications I write, are PHP based, so all of my examples will be based on that assumption, but you can re-use the ideas mentioned for software written in any other programming language. The setup [in the example] discusses just the deployment to the test project. Deployment to the production will be similar, and by the end of the article, you should understand what differences it will require.

She walks you through the creation of a new project, an example of the contents of the "base.rb" configuration file and how to create the stages (environments) to deploy to. Next up is the "recipes" themselves - the configuration steps for the deployment process. In their examples they show how to set permissions, update a database, manage asset files and a bit more to get Plesk installed on a server.

Capistrano is written in Ruby and offers up a basic DSL from which you can craft quite flexible deployment scripts. [...] That said, it's very flexible. In my current setup I have it deploying to multiple environments (dev, staging, production), building code (think Phing), running tests on the servers before finalising the deploy and then restarting worker processes on completion.

He starts by introducing some of the commands that you can perform with the "cap" command line client and links to an example PHP project structure you cn base your deployment off of. He also includes a bit about multi-stage deployments, tag (version) selection and the full source of his build script.

I'm not a Capistrano expert (yet) and in this post I'll try to give you an overview how to set it up and how to deploy WordPress applications (websites) in seconds. We'll work with only one server today but the principles in deploying to two or more are pretty much the same.

He starts by introducing Capistrano and talking about some of the major benefits it can bring to you and your project (most importantly - simple deployments). The tutorial helps you install Capistrano and get it set up to work with your Github repository to pull the source. The WordPress specific bit has to do with configuration files and suggests an "if" check to see if there's local config first. Also included are the updates you'll need to make to the Capistrano config file and the commands to push the latest as well as rollback to your previous version.

Deploying should be an active part of your development process, but not something that gives you a headache. If deploying your entire application takes more than one command or doesn't put a smile on your face, you should keep reading. NOTE: This post will specifically cover how to deploy your Symfony2 application, but the library used here - capifony - is just as useful for deploying a symfony 1.x application.

He walks you through the simple five step process of installing and configuring the capifony tool to pull from a remote git repository, set up some shared directories and update the vendor libraries on deployment. A few more changes for the initial deployment and you'll be ready to call "cap deploy" any time you'd like to push the latest version of your application. He also points out that with version 2.0.9 and above of capifony, Doctrine database migrations are also supported. For more information on capifony, see the project's website.

I was looking for a good deployment solution for my CakePHP apps and as nothing seems to fit perfectly, Capistrano does a very good job at keeping it simple. My setup is using a Git repository but almost SCM all supported by cap. Here is a basic guide into Capistrano setup configuration for CakePHP.

Once you get past some of the basics, they walk you through the configuration options, environment options and the full scripts to perform the deployment.

While Capistrano is certainly up to the task of deploying my own personal projects, I had nothing but problems getting people OTHER than myself to get it up and running. You wouldn't think that getting Ruby and then assorted gems installed on a non-Windows machine would be that hard. Apparently it is. So what was my alternate solution? Create something that can be run on the server where the code is going to be deployed.

He creates a process similar to the Capistrano methods that uses a symlink to switch from an older version of the code to a newer one. He shares the configuration files he used to check out the latest source - all XML based.

One of the best deployment systems out there (imho), is by the Ruby community, and it's called Capistrano. We've been using it internally since this summer to manage and deploy our Symfony application with great success. I'll be sharing the methodology to "Capify" a Symfony project soon, but first I wanted to share the Wordpress-Capistrano project.

The project's currently hosted on github where you can download it and try it out for yourself. Most of his recopies should be commented out but be sure to check before running any sort of deployment.

I'm a big fan of having an automated deployment process. It's really the web development analog to the "one step build process", as described in the Joel Test. In the past I have used various shell scripts to perform this task, but I have recently become a convert to Capistrano (or "cap" for short). With Capistrano, uploading your code to the test server is as simple as typing cap deploy. When you're ready to launch in production, it's just cap production deploy.

In part one he sets up his Capistrano configuration with his deploy.rb, development.rb and capfile configuration files. In the second part he integrates Drush, a multisite deployment and a multistage process.

In Part I, I talked about my approach to deploying a website and I offered pear and subversion as solutions to the problem. To briefly elaborate on my subversion part, I want to share the following Capistrano recipe with you.

He shows how to set up a sample "capfile" with the commands to perform for his deployment - checking out a release and, using a symlink to change the location, deploy the latest version of the site. He briefly mentions some chaining the tool allows.

Recently though, I was working on a PHP project, and I decided that the time had come to rewrite my Mint recipe to allow deployment of any PHP project, totally independent of Rails. I set to work, and I'm happy to share the result.

The example makes it a simple matter of using the command "cap deploy:php" to use the recipe and push out your PHP application.