Deploying ColdFusion Apps With Capistrano Part 3

Posted By on Mar 15, 2011 | 0 comments


Hopefully by now you have had a chance to play around with Capistrano and had a chance to deploy one of your apps. If you have and your anything like me, Im sure you ran into a situation where you needed to have a bit more flexibility in your deployment. Since most of the apps I deploy are written using the ColdFusion on Wheels framework, there are a few files that I dont want to deploy to production. So using that as an example, Im going to walk you through setting up and using shared files in your deployments.

Lets use our environment.cfm file as our example. This file simply tells our application what mode it should be running in. On my local workstation, Im typically running in design mode so all of my debugging info is displayed and nothing is cached. But when I deploy that to production, I dont want to push that file up with a value of ‘design‘ setting the environment, I want to keep it in ‘production‘ mode. So lets looks at how we accomplish this.

Remember our directory structure on the server after deployments looks like this:

/site
    releases/
    shared/

So inside our shared directory, lets create a directory called config.

Now that we have a place to hold our config file, we need to copy our config to the server and make sure its set to production mode. I’ll leave that method up to you since everyones method might be different. I simply used FTP to copy my file up and then used VIM to alter the file and change it to put the application in production mode.

Now I have a path like this shared/config/environment.cfm that will match the location of the config file in my application. Thats pretty much all you have to do on the server to set this up. So now lets see how Capistrano can link to that config each time it deploys a new copy of our application.

Here is what our deploy task looked like after part 2:

# this tells capistrano what to do when you deploy
namespace :deploy do

  desc <<-DESC
  A macro-task that updates the code and fixes the symlink.
  DESC
  task :default do
    transaction do
      update_code
      symlink
    end
  end

  task :update_code, :except => { :no_release => true } do
    on_rollback { run "rm -rf #{release_path}; true" }
    strategy.deploy!
  end

  task :after_deploy do
    cleanup
  end
end

Notice all the sections that are prefixed with task? Those blocks of code actually tell Capistrano what to do during deployment. The very first one is default and is run first by Capistrano when you tell it to deploy. Inside the transaction you can see the list of tasks its going to run and each of those tasks relates to a method defined in that namespace block. So in order to tell Capistrano to link our freshly deployed copy to the shared config file we just created on our server, we need to create a new task and tell the default target to run it during deployment. Here is an updated look at the recipe with our new symlink_shared task added to it.

# this tells capistrano what to do when you deploy
namespace :deploy do

  desc <<-DESC
  A macro-task that updates the code and fixes the symlink.
  DESC
  task :default do
    transaction do
      update_code
      symlink
      symlink_shared
    end
  end

  task :update_code, :except => { :no_release => true } do
    on_rollback { run "rm -rf #{release_path}; true" }
    strategy.deploy!
  end

  desc "Symlink shared configs and folders on each release."
  task :symlink_shared do
    run "ln -nfs #{shared_path}/config/environment.cfm #{release_path}/config/environment.cfm"
  end

  task :after_deploy do
    cleanup
  end
end

All we are telling Capistrano to do is run a command on the server to create a symlink in our release path pointing to our shared/config/environment.cfm file. In order for that to run, notice we added the symlink_shared target to the default deploy task at the end of the transaction list since we want to do that last. Dont let the existing symlink task in the transaction throw you off, thats a built in task that tells Capistrano to symlink your new release version to current like we saw in part 2.

Now all you have to do is redeploy your app and your all set. No more having to worry about accidentally setting your application to the wrong environment.

There are all sorts of things you can do like this in your deployments. I have linked to shared assets directories, uploaded files directories, all kinds of stuff. Its just a clean way to deploy and have each release point to something on the server that will not change.

If you have any questions regarding this type of deployment, feel free to post a comment and I will do anything I can to help you out.

Submit a Comment

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>