← CMS

Deploying CMS

Making the build

  1. Make sure all desired branches are merged into the master branch.
  2. The banno-cms pipeline job should detect the merge and kick off a new build. You should see a message in #auto-curry saying the build has started.

Staging

  1. The pipeline will automatically deploy to staging.

UAT

  1. The pipeline will pause and wait for confirmation to deploy to UAT. Check #auto-curry for a link to confirm and proceed.
  2. If the build contains changes to static assets like javascript, css, images, or changes to CMS transformer code (basically anything that would make changes to rendered content without user intervention) then you should also restart Varnish on UAT. Monitor may detect the changes otherwise and send out false positive alerts to users that their site has changed unexpectedly. You can do this by either using the Restart Marathon App Jenkins job or directly restarting the cms-varnish Marathon job.

Production

  1. The pipeline will pause and wait for confirmation to send release notes. Check #auto-curry for a link to confirm and proceed. An email will then be sent out to approvers.
  2. Once two approvers have approved the release it may be deployed via bbot. Drop a message in #org-deployments for @approvers if you’re having problems getting approvals.
  3. To deploy the release use the command @bbot deploy `<email subject goes here>` in #org-bbot. Progress on the deployment will be reported in #org-bbot and #org-deployments.
  4. Just like on UAT, if the release contains changes that would affect rendered pages without user intervention a cms-varnish restart should be performed. Use Restart Marathon App Jenkins job to do so.

Emergency deployment

  1. If an update needs to go out ASAP and/or it’s after normal working hours follow the above steps up through waiting for approvals.
  2. Contact someone on the tech-ops team in #org-tech-ops to deploy the change for you. You may have to page them if it’s after hours using the Slack command /pd-tech-ops. bbot will refuse to deploy the change without approvals otherwise.
  3. Tech ops will deploy the change.
  4. Make sure you get retroactive approvals for the release.