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

From version 16.1
edited by David Avendasora
on 2010/11/30 05:51
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
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. 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:
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
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"]]
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,11 +183,9 @@
183 183  You can use variable in capistrano scripts. You can set then with the "set" command:
184 184  
185 185  {{noformat}}
186 -
187 187  set <variable name>, <variable value> - this commands says for itself. Some examples:
187 +{{/noformat}}
188 188  
189 -{{/noformat}}
190 -
191 191  {{code}}
192 192  
193 193  set "var1", "some data"
... ... @@ -249,12 +249,12 @@
249 249  
250 250  {{/code}}
251 251  
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).//
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).
253 253  
254 254  == Moving global definitions to /etc/capistrano.conf ==
255 255  
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.
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.
257 257  
258 258  = Conclusion =
259 259  
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.
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.