Setting up a "Stage" Environment

By "stage" we really mean staging environment but most docs will just say "stage" for convenience.

This doc assumes you already have a production environment deployed, and therefore includes e.g. a step for cloning the production database nightly. However if you're doing things the "right way" then stage may be the first thing you deploy, in which case you'll skip the clone step in the beginning. Once everything works, you deploy to production, and then you would add the cloning step (etc.) to your stage setup.

Virtual Environment

In general everything which would be required for a production deployment, is required for stage also. That starts here, with creating a Python virtual environment specific to stage. This can exist on the same machine as production, in which case this virtual environment must be given a different name (e.g. "poser" for production and "poser-stage" for stage). Or it can exist on a different machine, in which case the two environments may be named the same. (OTOH you may want to use a different name even if you run stage on a different machine, just to keep things extra obvious.)

The stage virtual environment should run the same version of Python as you (plan to) run in production, etc. All dependency packages (Python or OS-level) required by your app should be installed and available, again with version numbers considered in relation to production setup. (They may not always match, e.g. stage may need to test newer versions for sake of a planned production upgrade.)

"Volatile" Software Source

Here we are referring to the specific Python packages which may be considered "volatile" for the sake of Poser app development. In many cases this would hopefully mean just your Poser app itself, but e.g. in my (author's) case this also would usually include the Rattail and Tailbone libraries, and perhaps others.

Whereas a production app is often running only released packages, a stage app will run "from source" for the "volatile" code but will install normal packages for all dependencies thereof.

App Config

By and large the stage config will be a copy/paste job from production, although the two should probably be distinct and not "shared" perpetually. Some config options may need to change, e.g. if you've named your stage virtual environment differently from production (because they're on the same machine). And there of course may be others, it's worth a good looking over first.

If you have no sample config to use as a starting point then you can always do (commands like):

rattail make-config -T rattail
rattail make-config -T quiet
rattail make-config -T web
rattail make-config -T datasync
rattail make-config -T filemon

Database

This ties into the config, of course. As with the virtual environment, you may or may not name the stage database the same as production, depending on where (which machine) stage runs etc.

Otherwise the stage database should be more or less identical with production. Often the "latest" data available is what should be used on stage, because:

• some features of your app require a "complete" (e.g. production) set of data to be tested properly
• some bugs in your app will only reveal themselves with certain "unexpected" data, which may exist in production

So of course the easiest way to ensure stage data resembles production, is to clone it. This ideally should be automated to happen nightly.

App Daemons

The config for supervisor will again be quite similar to production, perhaps even identical.

Apache Config

Again, similar, and probably copy/pasted from production, perhaps with some tweaks depending on where stage runs.