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.2 -r1.3 --- openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 7 Aug 2017 23:47:51 -0000 1.2 +++ openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 8 Nov 2017 09:42:11 -0000 1.3 @@ -10,12 +10,12 @@
<authorblurb>($Id: +maintenance.xml,v 1.31 2017/08/07 23:47:55 gustafn Exp +$)
-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 +</authorblurb> +
This section describes two minimal-risk methods for deploying changes on a production network. The important characteristics of a safe change deployment include: (THIS SECTION IN DEVELOPMENT)
Control: You know for sure that the change you are making is the @@ -24,7 +24,7 @@ working configuration safely and quickly.
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 @@ -103,7 +103,7 @@ tags to follow ...
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,28 +119,28 @@ function or risk losing data in the shuffle. It also requires extra steps if the database will be affected.