Skip to Content
Last modified by Ralf Schuchardt on 2020/11/17 19:23
From version 13.1
edited by Pascal Robert
on 2009/03/05 20:38
Change comment: There is no comment for this version
To version 17.1
edited by David Avendasora
on 2010/11/30 05:51
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Web Applications-Deployment-Capistrano (Overview)
1 +Automating Application Deployment with Capistrano (Overview)
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.avendasora
Content
... ... @@ -1,14 +7,8 @@
1 -{{warning}}
2 -[http://www.capify.org/2009/02/25/farewell/]
3 -
4 -Capistrano has been a fantastically fun and varied project to work on, and it's taught me a lot. However, it's time for me to say goodbye, and move on. You can read the full announcement on Jamis' blog, but the gist of it is that I'm no longer going to be updating or maintaining Capistrano (or related libraries). Thanks to everyone who offered their support and encouragement over the last couple of years. It's been great!
5 -{{/warning}}
6 -
7 7  Capistrano is a deployment system written on Ruby. Actually you don't have to know ruby if you want to use Capistrano - you'll still be able to implement your basic tasks. But if you want to gain real power and control on your deployment scenarios, some knowledge or ruby will greatly help.
8 8  
9 9  = How to install Capistrano =
10 10  
11 -Here is the official Capistrano installation instructon page: http:~/~/www.capify.org/install. On Leopard all you need to do is to run the following command with root privileges:
5 +Here is the official Capistrano installation instructon page: [[http:~~/~~/www.capify.org/install>>url:http://www.capify.org/install||rel="nofollow" shape="rect" class="external-link"]]. On Leopard all you need to do is to run the following command with root privileges:
12 12  
13 13  {{noformat}}
14 14  
... ... @@ -20,7 +20,7 @@
20 20  
21 21  = Must-read article about Capistrano =
22 22  
23 -Basics of using Capistrano are well described on its official site: http:~/~/www.capify.org/getting-started/basics
17 +Basics of using Capistrano are well described on its official site: [[http:~~/~~/www.capify.org/getting-started/basics>>url:http://www.capify.org/getting-started/basics||rel="nofollow" shape="rect" class="external-link"]]
24 24  
25 25  = Writing simple deployment recipe =
26 26  
... ... @@ -79,7 +79,7 @@
79 79  == 1. Pack the BugTracker.woa into tar.gz archive. ==
80 80  
81 81  This step should be done locally - we don't need to use Capistrano's main feature of executing ssh-commands in parallel on multiple servers.
82 -So the code will be:
76 + So the code will be:
83 83  
84 84  {{code}}
85 85  
... ... @@ -115,7 +115,7 @@
115 115  
116 116  {{/code}}
117 117  
118 -This will remove the /Library/WebObjects/Applications/BugTracker.woa folder on all servers specified for :app role. Notice that we've used "run" instead of "system". There is a great difference between these commands. "system" executes commands locally whereas "run" executes them on all remote servers specified for the current role. Another thing to notice the --f flag used for rm command. Capistrano will throw an exception and exit immediately if one of the commands executed on remote servers fail. Without --f flag rm will fail when there's no "/Library/WebObjects/Applications/BugTracker.woa" folder. This can happen during the first deployment, for example.
112 +This will remove the /Library/WebObjects/Applications/BugTracker.woa folder on all servers specified for :app role. Notice that we've used "run" instead of "system". There is a great difference between these commands. "system" executes commands locally whereas "run" executes them on all remote servers specified for the current role. Another thing to notice the -f flag used for rm command. Capistrano will throw an exception and exit immediately if one of the commands executed on remote servers fail. Without -f flag rm will fail when there's no "/Library/WebObjects/Applications/BugTracker.woa" folder. This can happen during the first deployment, for example.
119 119  
120 120  == 4. Unpack the archive. ==
121 121  
... ... @@ -165,8 +165,8 @@
165 165  
166 166  {{/code}}
167 167  
168 -The new part here is FileUtils.rm//f call. This is the way to delete files in ruby.
169 -Now we can check that :cleanup task actually works by executing the following command~://
162 +The new part here is FileUtils.rm_f call. This is the way to delete files in ruby.
163 + Now we can check that :cleanup task actually works by executing the following command:
170 170  
171 171  {{noformat}}
172 172  
... ... @@ -189,11 +189,9 @@
189 189  You can use variable in capistrano scripts. You can set then with the "set" command:
190 190  
191 191  {{noformat}}
192 -
193 193  set <variable name>, <variable value> - this commands says for itself. Some examples:
187 +{{/noformat}}
194 194  
195 -{{/noformat}}
196 -
197 197  {{code}}
198 198  
199 199  set "var1", "some data"
... ... @@ -255,12 +255,12 @@
255 255  
256 256  {{/code}}
257 257  
258 -Note that in //upload// and //FileUtils.rm//f// calls variable names are used without any additional symbols - that's because they're not the part of any string literal - so they're used as simple ruby variables (well actually things are much more complicated - but at least they look like simple ruby variables).//
250 +Note that in //upload// and //FileUtils.rm_f// calls variable names are used without any additional symbols - that's because they're not the part of any string literal - so they're used as simple ruby variables (well actually things are much more complicated - but at least they look like simple ruby variables).
259 259  
260 260  == Moving global definitions to /etc/capistrano.conf ==
261 261  
262 -Capistrano processes /etc/capistrano.conf file before processing any recipe. If you use several recipes for multiple projects that are hosted on the same deployment server, you will still have to specify :app role in every recipe. To avoid such duplication you can move the role definition to /etc/capistrano.conf. Also some general variable definitions can be moved there. In our case it's the :wo//apps//path variable.
254 +Capistrano processes /etc/capistrano.conf file before processing any recipe. If you use several recipes for multiple projects that are hosted on the same deployment server, you will still have to specify :app role in every recipe. To avoid such duplication you can move the role definition to /etc/capistrano.conf. Also some general variable definitions can be moved there. In our case it's the :wo_apps_path variable.
263 263  
264 264  = Conclusion =
265 265  
266 -Actually, with this brief overview of Capistrano features, you'll be able to write quite complicated deployment recipes. But it won't come as a surprise if I say that Capistrano can do a lot more. You can embed capistrano scripts into the ruby code, define multiple deployment configurations in single capistrano file, process output from servers and more and more... I'll write about these topics as soon as possible.
258 +Actually, with this brief overview of Capistrano features, you'll be able to write quite complicated deployment recipes. But it won't come as a surprise if I say that Capistrano can do a lot more. You can embed capistrano scripts into the ruby code, define multiple deployment configurations in single capistrano file, process output from servers and more and more... I'll write about these topics as soon as possible.