Deployment Best Practices
When deployments go smoothly, everyone is happy. But sometimes they don't go according to plan, or it isn't clear to everyone when and how the deployment will take place, so there are opportunities to improve the process as we learn what to avoid, and what to make sure we do before "pressing the button".
Things to Avoid:
- Saying one thing and doing another
- Having a loose/undefined deployment schedule
- Pushing code to LIVE during peak traffic times
- Having only 1 person online/active during the deployment
- Deploying without written signoff
- Deploying without a full backup (Code/DB/Files)
- Deploying on a Friday
Things to Always Do:
- Have a clear deployment plan with step-by-step outline of what needs to happen
- Have a scheduled time or window of time when the deployment will take place
- Have at least one stakeholder online during the deployment (in case there is a need to rollback or update content)
- Get written signoff from the client or PO acknowledging/approving the deployment (schedule and steps)
- Have a QA checklist to run through once the new code is live
- Have a "Content Cut-off Time" after which Content Editors can't update content in the database
- Always run a full back-up before deploying (Code/DB/Files)
- Communicate frequently and often what we are going to launch in the slack channel, with client eyes-on
Steps:
Feel free to use the following checklist as a reference during deployment. You can edit this page, and copy to the project's Deployment Notes doc if you find that helpful.
- Pick the parties who will be involved
- Deployer: _____
- Product Owner/Project Manager: ______
- Stakeholder: ______
- Create a "Deployment" story on the Jira board, linking this Deployment Notes Confluence page
- Work with the Product Owner to have a QA check list in the deployment story
- Visit Pantheon and create a Backup
- Create a Pull Request from sprint to master in GitHub, named "PROJ-# Deployment", where:
- PROJ represents the project code
- # represents the story number
- Get a +1 from the Product Owner to bring the code and latest database to TEST on Slack
- Merge the Pull Request from sprint to master on GitHub
- Visit the Pantheon TEST environment and:
- Bring the code from DEV to TEST
- Bring the database from LIVE to TEST
- Label the deployment "PROJ-# Deployment"
- Update the database
terminus drush proj.test updatedb
- Check for Feature conflicts
- admin/structure/features
- Review and Fix the conflicts if needed
- Revert Features
terminus drush proj.test fra --Â -y
- Clear Caches
terminus drush proj.test cc all
terminus env:clear-cache proj.test
- Assign the Jira story over to the Product Owner and move to QA
- "Latest is on TEST for you to QA. Let me know if it's good to go LIVE"
- Product Owner to go through QA check list
- Schedule a calendar event with the Deployer, Product Owner/Manager and Stakeholder for when the deployment will good LIVE, at which point...
- Product Owner to tell Stakeholder that content should freeze an hour beforeÂ
- Stakeholder to approve timeÂ
- Assign back to original owner of the deployment
- Move back to In Progress
- Comment saying "Good to go"
- Visit Pantheon and push the code up to LIVE
- Go through deployment steps #6 on LIVE
- Move the Jira story back to QA
- Assign to the Product Owner
- Comment saying "Site has been deployed to LIVE, please proceed with QA and any other needed content changes"
- Product Owner to run through QA Checklist and connect with Stakeholder about the deployment