Deploying a new version to an existing instance
If any step below fails. Stop the deploy and ping Monorail chat.
- Check for signs of trouble
- GAE dashboard
- Error Reporting
- If there are any significant operational problems with Monorail or ChOps in general, halt deploy.
- Update Schema
- Check for changes since last deploy:
tail -30 schema/alter-table-log.txt
- Copy and paste the new changes into the master DB in staging. Please be careful when pasting into SQL prompt.
- Also copy and paste updates to the master DB in the
- Upload Staging Version
- Test on Staging
- For each commit since last deploy, verify affected functionality still works. Test using a non-admin account, unless you're verifying admin-specific functionality.
- Make Live on Staging
- Update module
besearch to be the live version on staging.
- Update the other modules,
- Upload Production Version
- If you updated the staging schema, disconnect from the staging master DB so that command prompt is not left open in a terminal window.
- On console.cloud.google.com, try out the new version using a version specific URL:
- Test some of the expected changes.
- Add a comment to an issue.
- Enter a new issue and CC your personal account.
- Verify that you got an email (at the “all” email address specified in settings.py).
- Try doing a query that is not cached, then repeat it to test the cached case.
- Make Live on Prod
- Repeat the same schema changes on the prod database.
- Click on a bunch of projects to generate some traffic to the new version.
- Split traffic 1% with new version using cookie-based traffic splitting.
- Important: Make sure to split traffic for all 3 modules, starting with
- Wait an hour.
- If nothing looks off, proceed slowly to 25%, then 100%. Start with
besearch each time.
- If you updated the prod schema, disconnect from the prod master DB so that command prompt is not left open in a terminal window.
- Monitor Viceroy and Error Reporting
- Modest latency increases are normal in the first 10-20 minutes
- Check /p/chromium updates page.
- Chromiumdash, should work after deployment.
- Announce the Deployment.
- Copy changes since last deploy:
git log --oneline .
- Add a new row to the Monorail Deployment Stats spreadsheet to help track deploys/followups/rollbacks. It is important to do this even if the deploy failed for some reason.
Creating and deploying a new Monorail instance
- Create new GAE apps for production and staging.
- Configure GCP billing.
- Create new master DBs and 10 read replicas for prod and staging.
- Set up IP address and configure admin password and allowed IP addr. Instructions.
- Set up backups on master. The first backup must be created before you can configure replicas.
- Fork settings.py and configure every part of it, especially trusted domains and “all” email settings.
- You might want to also update
- Set up log saving to bigquery or something.
- Set up monitoring and alerts.
- Set up attachment storage in GCS.
- Set up spam data and train models.
- Fork and customize some of HTML in templates/framework/master-header.ezt, master-footer.ezt, and some CSS to give the instance a visually different appearance.
- Get From-address whitelisted so that the “View issue” link in Gmail/Inbox works.
- Set up a custom domain with SSL and get that configured into GAE. Make sure to have some kind of reminder system set up so that you know before cert expire.
- Configure the API. Details? Allowed clients are now configured through luci-config, so that is a whole other thing to set up. (Or, maybe decide not to offer any API access.)
- Gain permission to sync GGG user groups. Set up borgcron job to sync user groups. Configure that job to hit the API for your instance. (Or, maybe decide not to sync any user groups.)
- Monorail does not not access any internal APIs, so no whitelisting is required.
- For projects on code.google.com, coordinate with that team to set flags to do per-issue redirects from old project to new site. As each project is imported, set it's moved-to field.