Assisted Deployment
From Campus Web Server Help
EITS will soon offer an automated deployment process will assist you as you move code from the development to staging and production environments.
As a developer, you are free to write your application using any revision control system you wish. When you're ready, export the code from the RCS to /usr/www/dev/$user/release/$repo/$env, where env is "staging" or "production" and $repo is the common name of the repository. Since it is exported code, the release could contain anything from PHP to images to a single file to be placed in your /etc directory.
Just tell us where to put the repository, and we will take that raw repository of files and overwrite any existing content in the target path that you have specified. It's that simple; we just remove the old stuff and copy over the new stuff. To determine where the repository should be moved (e.g. target path), create entries in /usr/www/dev/$user/site.yaml in a "repo: target_path" format.
Example:
repopaths: images: public_html/images static: static wrappers: wrappers etc: etc
The repository names must be equally indented under the heading repopaths:. The target path is a path which is relative to your user directories. For example, if you want a repository named "images" to be posted under /usr/www/stage/baseball/public_html, your repopaths entry would simply be images: public_html/images.
Every minute, the server will look for release files. If it finds one, it will look for a target path in the site.yaml file. The server will delete the contents of the target path and move the contents from the release path to the target path.
If you find a bug in your code after deployment, simply create a new release and allow it to be deployed as usual.
For production releases, the server will obey the production_deployment_window defined in site.yaml. You must define this window, or no production deployment will be made. If you find a bug outside the deployment window, the deployment window variable must be changed temporarily to include the time that you would like the code to be deployed. Read Time Period Format to learn how to specify these periods.
The server will log any deployments so that administrators can be aware if load or other issues arise. It will also log deployment activity to /usr/www/dev/$user/notices. The address in the adminemail variable of site.yaml will also be used to notify the developers, site owners, or other interested parties of the updates. Multiple addresses can be given by separating the variable with commas. If no adminemail variable is defined, the server will notify the $user@uga.edu address.
The deployment script will also execute any $repo/prescript or $repo/postscript script found. If the prescript fails, the deployment for that repository will not be attempted. These scripts can be used to change database schemas, make special notifications like tweets, or other customized action.
