Capistrano 1.1.9 (beta)
Posted by jamis August 30, 2006 @ 06:46 PM
A new release of Capistrano is nearly upon us! Before I unleash it upon the world, though, I’d like to have a few brave souls put it through its paces, so I’m doing a brief run of it as a pre-release. You can grab it from the Rails beta gem server:
gem install -s http://gems.rubyonrails.com capistrano
There are a lot of changes in this release, most of them minor or cosmetic. However, there are some changes that may bite you, too.
The most significant change that may affect you has to do with the roles used for the setup, update_code, rollback_code, and symlink tasks. These tasks have changed such that they now deploy to all defined servers. That’s right, if you’ve got a server associated with any role, those tasks will deploy to that server. However, a server can explicitly opt out of being part of release deployment by setting :no_release => true in its role definition:
role :file, "file-server.somewhere.example",
:no_release => trueTake note of that! If you have any servers using non-standard roles (any role besides web, app, or db), you need to explicitly add :no_release => true in their role definitions, or your next deploy will target those servers, too.
Other significant changes that may or may not tickle you:
- The -r/--recipe command line option is deprecated. You should use -f/--file instead.
- Matthew Elder has contributed (and agreed to maintain) a module for the Mercurial SCM.
- If you have sudo in a non-standard location, you can specify the path to sudo via the :sudo variable
- Added :svn_passphrase so you can use keys with passphrases
- Fixed missing default for :local in the CVS module
- Subversion SCM accepts HTTPS certificates now
- Work with pid-based setups (new spawner/reaper)
- Added update task
- Added :except on task declarations (as the opposite of :only)
- Override the hosts to be used for a task via the HOSTS environment variable
- Override the roles that will be used for a task via the ROLES environment variable
- Added :hosts option on task declarations for defining tasks that work only on specific machines (rather than by role)
- Don’t require a capfile (this allows you to use capistrano to operate on arbitrary hosts, all from the command line)
Various other changes have been made as well—you can look at the CHANGELOG for a complete list.
Not tickle me? Mercurial Support
??! Wooo Hooo!!! Thank you very, very, very, very, very much Matthew!
Any future plans to support Windows?
morten, Windows is supported, as a platform for deploying from. But if you mean, do I plan to support deploying to windows, then the answer is “no”. (That, btw, is an invitation for someone else to stand up and write a utility for deploying to Windows.)
Right now I am not using Capistrano (even when I do Linux), primarily because I don’t want to use different tools for different deployment platforms… If Capistrano was platform-independent regarding deployment I would have no excuse :-)
I’ll go ‘woot!!!’ over not requiring a capfile everywhere. excellent!
Jamis, this is great stuff. I’ll let you know if I find something. Adam
And the changelog, by the way, is located here (I think):
http://dev.rubyonrails.org/svn/rails/tools/capistrano/CHANGELOG
What is a capfile?
Jeremy, your welcome! Please email me if you have any problems/questions about the module :)
Jeroen, a capfile is to Capistrano, as a rakefile is to Rake, and a makefile is to Make. It’s the file that contains the instructions that Capistrano will use to deploy your application. It is also called a “recipe file” in some documentation.
Okay so you don’t necessarily need a config/deploy.rb on the machine you’re executing the capistrano commands from? (not sure if I’m getting this)
Jeroen, right, for simple things like “check the uptime of this specific machine”, you can now do that all from the commandline, using environment variables and capistrano options:
HOSTS=foo.bar.com COMMAND=uptime cap -v invoke
Now, naturally, for things like deployment and cluster management, using a deploy.rb is going to be much more convenient than specifying all the options on the command-line. But for quick, one-off things like the above, the new version is quite handy.
Interesting. In my company the developers are not reponsible for the servers, deployments uptime etc. A different team performs these tasks. I’ve been thinking about how to integrate capistrano into this “system”. You don’t want to the deployment/sysadmin team to have to install the whole rails stack and capistrano on their local machines. Easiest way I could think of was that they svn co a config directory on one of the servers (where rails and cap are installed) and perform deployment tasks from there.
Anyways, thanks for a great tool!
I am experimenting with using capistrano as part of a centralised admin system and it’s working well so far although early days still.
Is there any mailing list just for Capistrano? The rails list has so much traffic it’s hard to keep track.