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 -N -r1.5.2.5 -r1.5.2.6 --- openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 5 Jan 2021 17:33:39 -0000 1.5.2.5 +++ openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 3 Sep 2021 09:15:17 -0000 1.5.2.6 @@ -1,5 +1,5 @@ -{/doc/acs-core-docs {ACS Core Documentation}} {Staged Deployment for Production Networks} +{/doc/acs-core-docs/ {ACS Core Documentation}} {Staged Deployment for Production Networks} Staged Deployment for Production Networks

Staged Deployment for Production Networks

-
($‌Id: maintenance.xml,v 1.35 2018/11/03 -19:57:22 gustafn Exp $)

By Joel Aufrecht +

($‌Id: maintenance.xml,v 1.35.2.2 2020/07/02 +08:39:25 gustafn Exp $)

By Joel Aufrecht

OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.

This section describes two minimal-risk methods for deploying @@ -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 @@ -102,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 @@ -113,32 +113,33 @@ additional measures typically take the form of source control tags and system version numbers. The parallel-server approach also guarantees rollback because the original working service is not -touched; it is merely set aside.

This approach can has limitations. If the database or filesystem regularly receiving new data, you must interrupt this -function or risk losing data in the shuffle. It also requires extra -steps if the database will be affected.

+touched; it is merely set aside.

This approach can has limitations. If the database or filesystem +regularly receiving new data, you must interrupt this 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 +

Figure 6.2. Simple A/B Deployment - Step 1

Simple A/B Deployment - Step 1

-

Figure 6.3. Simple A/B +

Figure 6.3. Simple A/B Deployment - Step 2

Simple A/B Deployment - Step 2

-

Figure 6.4. Simple A/B +

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 +

Figure 6.5. Complex A/B Deployment - Step 1

Complex A/B Deployment - Step 1

-

Figure 6.6. Complex A/B +

Figure 6.6. Complex A/B Deployment - Step 2

Complex A/B Deployment - Step 2

-

Figure 6.7. Complex A/B +

Figure 6.7. Complex A/B Deployment - Step 3

Complex A/B Deployment - Step 3