Changes for page Automating Application Deployment with Capistrano (Overview)

Summary

• Page properties (4 modified, 0 added, 0 removed)

Details

Page properties

Parent

...	...	@@ -1,1 +1,0 @@
1		-documentation.Home.Deployment.WebHome

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.ralf_schuchardt
	1	+XWiki.avendasora

Tags

...	...	@@ -1,1 +1,0 @@
1		-deployment

Content

...	...	@@ -2,9 +2,10 @@
2	2
3	3	= How to install Capistrano =
4	4
5		-Here is the official Capistrano installation instruction page: [[https:~~/~~/capistranorb.com/documentation/getting-started/installation/>>url:https://capistranorb.com/documentation/getting-started/installation/||shape="rect"]]. 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	8	gem install -y capistrano
9	9
10	10	{{/noformat}}
...	...	@@ -13,7 +13,7 @@
13	13
14	14	= Must-read article about Capistrano =
15	15
16		-Basics of using Capistrano are well described on its official site: [[https:~~/~~/capistranorb.com>>url:https://capistranorb.com||shape="rect"]]
	17	+Basics of using Capistrano are well described on its official site: http:~/~/www.capify.org/getting-started/basics
17	17
18	18	= Writing simple deployment recipe =
19	19
...	...	@@ -28,6 +28,7 @@
28	28	So let's start our recipe file:
29	29
30	30	{{code}}
	32	+
31	31	task :deploy, roles => :app do
32	32	end
33	33
...	...	@@ -36,6 +36,7 @@
36	36	This is the empty definition of task "deploy" that will run on application servers (see, roles :app). We need to define the :app role in order to make the recipe usable:
37	37
38	38	{{code}}
	41	+
39	39	role :app, "localhost"
40	40	task :deploy, roles => :app do
41	41	end
...	...	@@ -45,6 +45,7 @@
45	45	Ok - this is not much, but at least something. Capistrano recipes are executed using "cap" command. So now you should be able to execute the following:
46	46
47	47	{{noformat}}
	51	+
48	48	cap -f BugTracker.cap deploy
49	49
50	50	{{/noformat}}
...	...	@@ -52,6 +52,7 @@
52	52	The output should be:
53	53
54	54	{{noformat}}
	59	+
55	55	* executing `deploy'
56	56
57	57	{{/noformat}}
...	...	@@ -68,9 +68,10 @@
68	68	== 1. Pack the BugTracker.woa into tar.gz archive. ==
69	69
70	70	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.
71		- So the code will be:
	76	+So the code will be:
72	72
73	73	{{code}}
	79	+
74	74	system "tar -C build -czvf BugTracker.woa.tar.gz BugTracker.woa"
75	75	raise "failed to create an archive" unless $?.exitstatus == 0
76	76
...	...	@@ -86,6 +86,7 @@
86	86	Here's how it can be done:
87	87
88	88	{{code}}
	95	+
89	89	upload "BugTracker.woa.tar.gz", "/tmp/BugTracker.woa.tar.gz"
90	90
91	91	{{/code}}
...	...	@@ -97,11 +97,12 @@
97	97	This will look like this:
98	98
99	99	{{code}}
	107	+
100	100	run "rm -rf /Library/WebObjects/Applications/BugTracker.woa"
101	101
102	102	{{/code}}
103	103
104		-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.
105	105
106	106	== 4. Unpack the archive. ==
107	107
...	...	@@ -108,6 +108,7 @@
108	108	Nothing new in this code:
109	109
110	110	{{code}}
	119	+
111	111	run "tar -C /Library/WebObjects/Applications -xzvf /tmp/BugTracker.woa.tar.gz"
112	112
113	113	{{/code}}
...	...	@@ -115,6 +115,7 @@
115	115	So, right now we have the following deployment script:
116	116
117	117	{{code}}
	127	+
118	118	role :app, "localhost"
119	119	task :deploy, roles => :app do
120	120	# creating BugTracker.woa.tar.gz
...	...	@@ -140,6 +140,7 @@
140	140	Let's write a cleanup task in order not to leave tar.gz archives both on our local machine and on remote servers. The task can look like this:
141	141
142	142	{{code}}
	153	+
143	143	task :cleanup, roles => :app do
144	144	FileUtils.rm_f "BugTracker.woa.tar.gz"
145	145
...	...	@@ -148,10 +148,11 @@
148	148
149	149	{{/code}}
150	150
151		-The new part here is FileUtils.rm_f call. This is the way to delete files in ruby.
152		- 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~://
153	153
154	154	{{noformat}}
	166	+
155	155	cap -f BugTracker.cap cleanup
156	156
157	157	{{/noformat}}
...	...	@@ -159,6 +159,7 @@
159	159	It's great to have a cleanup task, but it would be even better if it would run after the deployment. Capistrano has a "hooks" feature that will help us with that:
160	160
161	161	{{code}}
	174	+
162	162	after :deploy, :cleanup
163	163
164	164	{{/code}}
...	...	@@ -170,11 +170,13 @@
170	170	You can use variable in capistrano scripts. You can set then with the "set" command:
171	171
172	172	{{noformat}}
	186	+
173	173	set <variable name>, <variable value> - this commands says for itself. Some examples:
174	174
175	175	{{/noformat}}
176	176
177	177	{{code}}
	192	+
178	178	set "var1", "some data"
179	179	set :var2, 10
180	180
...	...	@@ -183,6 +183,7 @@
183	183	Note also that you can use the identifiers starting with ":" as variable names. This is the ruby way of specifying unique identifiers (called symbols in ruby). Using symbols is a bit faster than using strings, besides you can easily see identifiers in your code, as they won't be quoted - and will not look like string literals. Anyway these calls are absolutely equal:
184	184
185	185	{{code}}
	201	+
186	186	set :var1, "some data"
187	187	set "var1", "some data"
188	188
...	...	@@ -191,6 +191,7 @@
191	191	After the variable is set, you can use it in string literals using in the traditional ruby way:
192	192
193	193	{{code}}
	210	+
194	194	run "echo #{var1}"
195	195	run "echo #{var2}"
196	196
...	...	@@ -199,6 +199,7 @@
199	199	So let's generalize our script with some variables usage:
200	200
201	201	{{code}}
	219	+
202	202	role :app, "localhost"
203	203
204	204	set :app_name, "BugTracker.woa"
...	...	@@ -231,12 +231,12 @@
231	231
232	232	{{/code}}
233	233
234		-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).//
235	235
236	236	== Moving global definitions to /etc/capistrano.conf ==
237	237
238		-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.
239	239
240	240	= Conclusion =
241	241
242		-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.