Deployment Workflow - uclibs/treatment_database GitHub Wiki

To deploy to production:

Pre-Deploy steps

  • Prepare the QA environment
    • drop QA database
    • run QA migrations
    • run QA seeds (includes creating the needed accounts)
  • Merge "qa" into "main"
    • git fetch origin
    • git checkout main
    • git pull origin main
    • git merge qa
    • resolve any conflicts
    • git push origin main
  • Create a "Release" on Github. When this is published and not just a draft, it will create a "tag" with the version number you used in the release, removing the need to manually push a tag number. Set this as a pre-release.
  • Submit security scan - requested date back is at least one week before you intend to present to change management.
  • Submit accessibility scan if needed
  • Submit Change Request, setting the deployment date at least one week after presenting to change management.
  • Notify the TD team (Holly Prochaska) of incoming changes and the expected deployment date
  • Make sure the correct version of Ruby is installed on libapps

Deploy Steps

  • Run cap main deploy
  • Verify app is running correctly:
    • App can be accessed at the production website.
    • CSS is present - grey banner on logging in, red trash can icons on the records index page.
    • Admin can log in.
    • Admin can access appropriate menus.
    • A report can be generated and viewed.
    • A record can be viewed.
    • Admin can log out.


  • Check that migrations were run if needed.
  • Look at file structure in libapps and see if public files were correctly generated.

Reverting Changes

If deploy is unsuccessful, revert to latest tagged version as follows:

On local terminal:

  • download most recent tags with git fetch --tags
  • checkout the correct tag with git checkout 1.0.2 (Assuming 1.0.2 is the tag you want to revert to)
  • change config/deploy/main :branch from main to 1.0.2
  • deploy with cap main deploy
  • change the cap lock in config/deploy.rb if required by prompt in the terminal (likely to 3.18.1) and re-deploy
  • verify successful re-deployment

Post-Deployment Steps:

  • Close the milestone if not already done
  • Close the Github deployment issue
  • Mark the change request as completed
  • Set the Github release as the most recent version instead of pre-release
  • Update the App Portfolio