| Prev | Chapter 6. Production Environments | Next |
|---|
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 change that you intend to make and is the change that you tested.
Rollback: If anything goes wrong, you can return to the previous working configuration safely and quickly.
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 change that you intend to make and is the change that you tested.
Rollback: If anything goes wrong, you can return to the previous 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 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 assume in this example that you set up the + 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 + 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).
su - service0-dev @@ -22,14 +22,14 @@ 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 +
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 + 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 + /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.
@@ -54,7 +54,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 @@ -66,5 +66,5 @@ cd /var/lib/aolserver/service0/www 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 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 ...
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 you can see them directly. It does not, by itself, guarantee the entire control chain. You need additional measures to make sure that the change you are making is exactly and completely the change you intended to make and tested previously, and nothing more. Those 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 file system 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.
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 ...
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 you can see them directly. It does not, by itself, guarantee the entire control chain. You need additional measures to make sure that the change you are making is exactly and completely the change you intended to make and tested previously, and nothing more. Those 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 file system 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.
