Last modified by Ralf Schuchardt on 2020/11/17 19:23

From version 17.1
edited by David Avendasora
on 2010/11/30 05:51
Change comment: There is no comment for this version
To version 16.1
edited by David Avendasora
on 2010/11/30 05:51
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -2,7 +2,7 @@
2 2  
3 3  = How to install Capistrano =
4 4  
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:
5 +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:
6 6  
7 7  {{noformat}}
8 8  
... ... @@ -14,7 +14,7 @@
14 14  
15 15  = Must-read article about Capistrano =
16 16  
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"]]
17 +Basics of using Capistrano are well described on its official site: http:~/~/www.capify.org/getting-started/basics
18 18  
19 19  = Writing simple deployment recipe =
20 20  
... ... @@ -73,7 +73,7 @@
73 73  == 1. Pack the BugTracker.woa into tar.gz archive. ==
74 74  
75 75  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.
76 - So the code will be:
76 +So the code will be:
77 77  
78 78  {{code}}
79 79  
... ... @@ -109,7 +109,7 @@
109 109  
110 110  {{/code}}
111 111  
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.
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.
113 113  
114 114  == 4. Unpack the archive. ==
115 115  
... ... @@ -159,8 +159,8 @@
159 159  
160 160  {{/code}}
161 161  
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:
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~://
164 164  
165 165  {{noformat}}
166 166  
... ... @@ -183,9 +183,11 @@
183 183  You can use variable in capistrano scripts. You can set then with the "set" command:
184 184  
185 185  {{noformat}}
186 +
186 186  set <variable name>, <variable value> - this commands says for itself. Some examples:
187 -{{/noformat}}
188 188  
189 +{{/noformat}}
190 +
189 189  {{code}}
190 190  
191 191  set "var1", "some data"
... ... @@ -247,12 +247,12 @@
247 247  
248 248  {{/code}}
249 249  
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).
252 +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).//
251 251  
252 252  == Moving global definitions to /etc/capistrano.conf ==
253 253  
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.
256 +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.
255 255  
256 256  = Conclusion =
257 257  
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.
260 +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.