Index: openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp,v diff -u -r1.4 -r1.5 --- openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 27 Mar 2018 11:18:00 -0000 1.4 +++ openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 25 Apr 2018 08:38:28 -0000 1.5 @@ -3,15 +3,15 @@ Staged Deployment for Production Networks -
+ leftLink="high-avail" leftLabel="Prev" + title="Chapter 6. Production +Environments" + rightLink="install-ssl" rightLabel="Next"> +

Staged Deployment for Production Networks

<authorblurb>

($‌Id: -maintenance.xml,v 1.31 2017/08/07 23:47:55 gustafn Exp +maintenance.xml,v 1.32 2018/03/27 11:18:00 hectorr Exp $)

By Joel Aufrecht

</authorblurb> @@ -24,7 +24,7 @@ working configuration safely and quickly.

-Method 1: Deployment with CVS

With this method, we control the files on a site via CVS. This +Method 1: Deployment with CVS

With this method, we control the files on a site via CVS. This example uses one developmental server (service0-dev) and one production server (service0). Depending on your needs, you can also have a staging server for extensive testing before you go live. The @@ -86,8 +86,7 @@

To make these changes take place on service0:

 4) update the file on production:
 cd /var/lib/aolserver/service0/www
-cvs up -Pd index.adp
-

If you make changes that require changes to the database, test +cvs up -Pd index.adp

If you make changes that require changes to the database, test them out first on service0-dev, using either -create.sql or upgrade scripts. Once you've tested them, you then update and run the upgrade scripts from the package manager.

The production site can run "HEAD" from cvs.

The drawback to using HEAD as the live code is that you cannot @@ -103,7 +102,7 @@ tags to follow ...

-Method 2: A/B Deployment

The approach taken in this section is to always create a new +Method 2: A/B Deployment

The approach taken in this section is to always create a new service with the desired changes, running in parallel with the existing site. This guarantees control, at least at the final step of the process: you know what changes you are about to make because @@ -119,38 +118,38 @@ function or risk losing data in the shuffle. It also requires extra steps if the database will be affected.

-Simple A/B Deployment: Database is not +Simple A/B Deployment: Database is not changed

-

Figure 6.2. Simple -A/B Deployment - Step 1

Simple A/B Deployment - Step 1
+

Figure 6.2. Simple A/B +Deployment - Step 1

Simple A/B Deployment - Step 1

-

Figure 6.3. Simple -A/B Deployment - Step 2

Simple A/B Deployment - Step 2
+

Figure 6.3. Simple A/B +Deployment - Step 2

Simple A/B Deployment - Step 2

-

Figure 6.4. Simple -A/B Deployment - Step 3

Simple A/B Deployment - Step 3
+

Figure 6.4. Simple A/B +Deployment - Step 3

Simple A/B Deployment - Step 3

-Complex A/B Deployment: Database is +Complex A/B Deployment: Database is changed

-

Figure 6.5. Complex A/B Deployment -- Step 1

Complex A/B Deployment - Step 1
+

Figure 6.5. Complex A/B +Deployment - Step 1

Complex A/B Deployment - Step 1

-

Figure 6.6. Complex A/B Deployment -- Step 2

Complex A/B Deployment - Step 2
+

Figure 6.6. Complex A/B +Deployment - Step 2

Complex A/B Deployment - Step 2

-

Figure 6.7. Complex A/B Deployment -- Step 3

Complex A/B Deployment - Step 3
+

Figure 6.7. Complex A/B +Deployment - Step 3

Complex A/B Deployment - Step 3

- + homeLink="index" homeLabel="Home" + upLink="maintenance-web" upLabel="Up"> + \ No newline at end of file