Changes for page Deployment-Book

Summary

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

Details

Page properties

Parent

...	...	@@ -1,0 +1,1 @@
	1	+The WebObjects Beginner Book

Tags

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

Content

...	...	@@ -5,17 +5,19 @@
5	5	Deployment typically need the following tools:
6	6
7	7	* A Web server (Apache httpd)
8		-* A Web server module (mod//webobjects for Apache)//
	8	+* A Web server module (mod_webobjects for Apache)
9	9	* wotaskd
10	10	* JavaMonitor
11	11
12		-For a deployment-like environment on your deployment box, JavaMonitor is not needed, but you do need wotaskd, the Web server and the module. (link to apache setup in the wiki)
	12	+For a deployment-like environment on your deployment box, JavaMonitor is not needed, but you do need wotaskd, the Web server and the module.
	13	+ [[doc:WO.WO 5\.4 Getting Started]]
	14	+ [[Running Through Apache - Leopard & Snow Leopard Client - Summary>>doc:documentation.Running Through Apache - Leopard & Snow Leopard Client - Summary]]
13	13
14	14	== Why Deployment at the Beginning? ==
15	15
16	16	You might wondering: why bother with deployment so early one? So of the reasons are:
17	17
18		-* You can use features like mod//rewrite, which are not available when using DirectConnect.//
	20	+* You can use features like mod_rewrite, which are not available when using DirectConnect.
19	19	* You can detect deployment problems early on. Nothing is worst than finding deployment problems when you deploy it and found out that you forgot a lot of things.
20	20	* You can use static content or scripts (PHP, etc.) that are not bundled in your applications.
21	21
...	...	@@ -22,7 +22,6 @@
22	22	== Structure of .framework and .woa Build Products ==
23	23
24	24	{{code}}
25		-
26	26	.framework
27	27	-> Resources
28	28	-> English.lproj, ...
...	...	@@ -37,9 +37,8 @@
37	37	-> English.lproj, ...
38	38	-> .css/.png
39	39	-> .css/.png
	41	+{{/code}}
40	40
41		-{{/code}}
42		-
43	43	{{code}}
44	44
45	45	.woa
...	...	@@ -81,10 +81,14 @@
81	81
82	82	== SSL Configuration ==
83	83
84		-It's useful to create a https configuration on your deployment-like setup. By doing that, you can try out switching between SSL and non-SSL and make sure that switching is working well. On your development box, no need to purchase a SSL certificate, you can create a self-signed certificate for free. To create a self-signed certificate on OS X, do the following:
	84	+It's useful to create a https configuration on your deployment-like setup. By doing that, you can try out switching between SSL and non-SSL and make sure that switching is working well. On your development box, no need to purchase a SSL certificate, you can create a self-signed certificate for free. To create a self-signed certificate on OS X, check [[this page>>url:http://wiki.wocommunity.org/display/WO/Development-SSL+requests+via+https+protocol||shape="rect"]].
85	85
86		-== Deployment Components: JavaMonitor, Wotaskd and javawoservice ==
	86	+{{code}}
87	87
	88	+Deployment Components: JavaMonitor, Wotaskd and javawoservice
	89	+
	90	+{{/code}}
	91	+
88	88	== Setting up JavaMonitor ==
89	89
90	90	== Editing spawnofwotaskd.sh ==
...	...	@@ -104,7 +104,7 @@
104	104
105	105	The first thing to do when an application doesn't launch by JavaMonitor/wotaskd is to launch it by command line. To do so, open a command line shell, logging as the "appserver" and start the launch script manually. For example, if you have an application named "MyApp.woa" in /Library/WebObjects/Applications, do the following commands:
106	106
107		-* sudo --s--
	111	+* sudo -s
108	108	* su - appserver
109	109	* cd /Library/WebObjects/Applications/MyApp.woa
110	110	* ./MyApp
...	...	@@ -111,7 +111,7 @@
111	111
112	112	99% of the time, that procedure will show the problems, in particular permissions and classpath problems.
113	113
114		-== Deployment alternatives (servlet, mod//proxy)// ==
	118	+== Deployment alternatives (servlet, mod_proxy) ==
115	115
116	116	== Handling Transitions between http and https ==
117	117
...	...	@@ -119,8 +119,8 @@
119	119
120	120	Using a continuous build system is useful. Many people in the community don't even build their applications on their development boxes anymore, they use a continuous build system to build projects from a source control repository. This is even more useful if you have more than one developer working on your projects, by centralizing builds, you can detect source merge problems, etc. You can even run unit tests and do deployments from a build system.
121	121
122		-The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
	126	+The most popular continuous build system is Jenkins. It's an open source project build in Java, with many useful plugins.
123	123
124	124	== Using a staging server ==
125	125
126		-It's not a requirement early on, but if your development and development environments are not alike (for example: development on OS X, deployment on Linux), you should create a staging environment that is setup exactly like your production environment. By "exactly", we means that for instance if your production environment is using CentOS 5 64bits (x86//64), your staging environment should use the same OS, and the same version of Apache, etc. A staging environment will allow your customers to try new versions of your apps without putting them on your production server, and you can detect environment-specific problems.//
	130	+It's not a requirement early on, but if your development and development environments are not alike (for example: development on OS X, deployment on Linux), you should create a staging environment that is setup exactly like your production environment. By "exactly", we means that for instance if your production environment is using CentOS 5 64bits (x86_64), your staging environment should use the same OS, and the same version of Apache, etc. A staging environment will allow your customers to try new versions of your apps without putting them on your production server, and you can detect environment-specific problems.