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.1.2.11 -r1.1.2.12
--- openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 21 Jun 2016 07:44:36 -0000 1.1.2.11
+++ openacs-4/packages/acs-core-docs/www/maintenance-deploy.adp 23 Jun 2016 08:32:45 -0000 1.1.2.12
@@ -11,8 +11,8 @@
Staged Deployment for Production
Networks
-
($Id: maintenance.xml,v 1.30 2010/12/11
-23:36:32 ryang Exp $)
By Joel Aufrecht
+
($Id: maintenance-deploy.html,v 1.24.2.10
+2016/06/21 07:44:36 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
@@ -31,29 +31,30 @@
only way files should move between the server instances is via
cvs.
To set up a developmental installation, first set up either your
developmental installation or your production installation, and
-follow the instructions for committing your files to CVS. We'll
+follow the instructions for committing your files to CVS. We'll
assume in this example that you set up the production server
(service0). To set up the developmental instance, you then follow
the intall guide again, this time creating a new user
-(service0-dev) that you'll use for the new installation. To get the
-files for service0-dev, you check them out from cvs (check out
+(service0-dev) that you'll use for the new installation. To get
+the files for service0-dev, you check them out from cvs (check out
service0).
su - service0-dev
co -d /cvsroot service0
mv service0 /var/lib/aolserver/service0-dev
ln -s /home/service0-dev/web /var/lib/aolserver/service0-dev
emacs web/etc/config.tcl
emacs web/etc/daemontools/run
-
In the config.tcl file, you'll probably want to pay attention
-the rollout support section. That will ensure that email on your
-developmental server will not be sent out to the general world.
Also, instead of going through the OpenACS online installer,
-you'll actually load live data into your production server.
You can even automate the process of getting live data from your
+
In the config.tcl file, you'll probably want to pay
+attention the rollout support section. That will ensure that email
+on your developmental server will not be sent out to the general
+world.
Also, instead of going through the OpenACS online installer,
+you'll actually load live data into your production server.
You can even automate the process of getting live data from your
production server. Copy something like this to
-/home/service0-dev/bin and put it in service0-dev's crontab to run
-once a night. You'll need to make sure the database backups are set
-up in service0's crontab, and that if the servers are on different
-physical machines, that the database backup is copied to the
-developmental machine once per night.
+/home/service0-dev/bin and put it in service0-dev's crontab to
+run once a night. You'll need to make sure the database backups
+are set up in service0's crontab, and that if the servers are
+on different physical machines, that the database backup is copied
+to the developmental machine once per night.
/usr/local/bin/svc -d /service/service0-dev
/bin/sleep 60
# this deletes the dev database!
@@ -75,7 +76,7 @@
if the file is /var/lib/aolserver/service0-dev/www/index.adp, do:
cd /var/lib/aolserver/service0-dev/www
-cvs diff index.adp (this is optional; it's just a
+cvs diff index.adp (this is optional; it's just a
reality check)
the lines starting > will be added and the lines
starting < will be removed, when you commit
@@ -88,18 +89,18 @@
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
+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
commit new work on the development server without erasing the
-definition of 'working production code.' So a better method is to
-use a tag. This guarantees that, at any time in the future, you can
-retrieve exactly the same set of code. This is useful for both of
-the characteristics of safe change deployment. For control, you can
-use tags to define a body of code, test that code, and then know
-that what you are deploying is exactly that code. For rollback, you
-can use return to the last working tag if the new tag (or new,
-untagged changes) cause problems. .... example of using tags to
-follow ...
+definition of 'working production code.' So a better method
+is to use a tag. This guarantees that, at any time in the future,
+you can retrieve exactly the same set of code. This is useful for
+both of the characteristics of safe change deployment. For control,
+you can use tags to define a body of code, test that code, and then
+know that what you are deploying is exactly that code. For
+rollback, you can use return to the last working tag if the new tag
+(or new, untagged changes) cause problems. .... example of using
+tags to follow ...
The approach taken in this section is to always create a new
@@ -120,27 +121,27 @@
Simple A/B Deployment: Database is not
changed
Complex A/B Deployment: Database is
changed
