Comments

Leave a response

1. b on 25 Apr 05:22:
   

   Thanks Jamis, Wow, looks fantastic! Looking forward to giving it a test drive. Thanks for all your work. The more I use Capistrano the more I cant imagine doing things any other way. Even for small projects. Great stuff.

2. Hugh on 25 Apr 11:01:
   

   I like the website name =P.

   Is that the word you use when you use Capistrano on a project?

3. topfunky on 25 Apr 17:28:
   

   Tip: I didn’t have Highline installed, and the install line above couldn’t find the highline gem.

   What worked was to “gem install highline”, then install capistrano as mentioned above.

4. Achim Maisenbacher on 25 Apr 17:31:
   

   Sounds great, i’ll test it soon!

5. anon on 25 Apr 17:58:
   

   Capistrano? what is it? generally putting at least a 1 line descriptor of what you are announcing is good form. tnx.

6. Jamis on 25 Apr 18:25:
   

   Thanks for the suggestion, anon. I’ve added a couple of sentences to the announcement.

7. Joe Ruby on 26 Apr 02:49:
   

   That graphic on capify sure is relaxing…

8. Brian on 26 Apr 14:02:
   

   I’m new to Ruby. When you write

   Capistrano is a utility for executing remote commands in parallel on multiple remote servers.

   Are we talking any commands or ‘just’ ruby specific code?

   ‘Cause I have a few hundred wintel and unix servers to manage – yet another tool to run around and execute commands would be pretty cool.

9. Jamis on 26 Apr 18:56:
   

   Brian, I mean shell commands. Capistrano cannot be used to manage windows machines, although some people have reported success with cygwin. It just basically logs into each machine and runs the commands you specify, as if you had typed them on the command-line.

10. Greg H on 26 Apr 21:01:
    

    Hi Jamis – does 2.0 include any of the following:

    • ability to do a “light” deploy where only the few files which are changed are copied up into the deployment area (i.e. at the moment manual ftp is required). “cap directupdate <you file>“
    • support for “freezing rails” but in a manner whereby every “cap deploy” does not take the hit of checking out rails from svn each time (i.e. normally it would be in the application vendor directory here)

    Thanks Greg

11. Jamis on 26 Apr 22:34:
    

    Greg, there is “cap deploy:upload”, which can be used to upload a subset of files to the remote servers.

    No support yet for deploying with a shared checkout of rails, but I’d like to include that eventually, especially if it can be done without being specific to rails.

12. Jake on 27 Apr 15:36:
    

    Jamis- when SVN does an export from a workspace, does it hit the server/repository again or does it read from the workspace?

    Would it be faster to juse do an “svn update” followed by an “svn export” from the workspace (shared checkout) ?

13. Jamis on 27 Apr 21:16:
    

    Jake, it will hit the repository.

14. Jamis on 27 Apr 21:18:
    

    I should clarify; it will hit the repository if you are using the export functionality as exposed by Capistrano. However, you can always write your own tasks that use the alternative export syntax of subversion to export from a working copy.

15. DGM on 28 Apr 15:25:
    

    I’m with Jake on this one… I cannot use the existing tasks to deploy, because my development SVN server is behind a firewall, and the production machines cannot access it. Not to mention the fact that the production servers don’t have svn installed. (Some people have minimalist install policies for the purpose of security… and I can’t really argue with that)

    Also, while it seems the usual method around here is to do development testing on one’s own workstation and then deploy to the real site, I have several projects where I need more deploy stages… I need to deploy to a testing environment which is set up like production, but on a a dedicated test server. Onced it has passed tests on that server, then it can be deployed to the real production servers.

16. Jamis on 28 Apr 22:03:
    

    DGM, you’re right, in your situation, ou cannot use the deployment tasks from Capistrano 1.x.

    Capistrano 2.0 provides more options. Specifically for people in your situation, cap2 now provides “deploy_via :copy”, which will do the checkout locally, tar it up, sftp the archive to the remote machines, and then unarchive to the correct location. It works like a charm on boxes that have no access to the repository.

17. FX on 19 May 21:06:
    

    Capistrano 2.0 Preview 2 is available. So Preview 1 can be skipped.

18. jghjmo381j on 21 May 18:03:
    

    b6067ab7 jozrkrnsos5709 86871×2lvn55fb8w