-
Notifications
You must be signed in to change notification settings - Fork 2
Deployment
DataMade hosts a staging version and production version of Metro Councilmatic.
Both sites reside on the LA Metro Councilmatic - Upgrade server. Metro developers should be able to shell into this server, e.g., for executing management commands. If you cannot, then talk to your friendly DataMade devops team.
Triggering a Metro deployment follows the typical DataMade pattern: merging or pushing to master deploys to the staging site, and pushing a tag deploys to the production site. The Metro deployment scripts, however, do not follow the contemporary "zero downtime" deployment pattern, but rather they use the "classic" style of DataMade deployment. As a result, the Metro site raises a 500 error for a couple minutes, during the course of a CodeDeploy lifetime.
So, when can you trigger a deployment to production? DataMade does not need to communicate to the folks at Metro the exact timing of deployments. However, we do take a couple precautions:
- Do not deploy during meetings, since we do not want the site to go down for a couple minutes, when users need access to event info.
- Do not deploy on support Fridays, since we do not want the site to behave unexpectedly, when Metro admin adds data on Friday night.
These practices have exceptions, of course, particularly, if Metro needs an urgent bug fix.
Deployments rarely require special intervention or deviation from the standard CodeDeploy pipeline. Only one aspect of Metro Councilmatic requires attention upon deployment: regenerating the Solr schema. It is necessary to regenerate the schema (or in other words, rebuild the Solr index) whenever the schema or search_indexes.py changes.
The README contains comprehensive, step-by-step instructions on how to handle changes to the Solr schema. Notably, you must remove and rebuild the Solr containers, since the deployment scripts do not (cannot) handle this step.