Skip to content

Typical Build Workflow with Security Release Notes

Jump to bottom
Joshua Mitchell edited this page Jul 9, 2020 · 10 revisions

Any change to a site hosted with our standard workflow should follow the steps below. Note that the composer update and drush updb related steps below are only required when applying an update—which includes security updates.

  1. In the developers local environment, git checkout master and git pull to make sure local is up to date.

  2. Run lando latest to get the lastest dev database backup.

  3. Create a feature branch with the ID of the related Jira issue by running git checkout -b powr-[ID]. Move your Jira issue to in progress.

  4. Run lando refresh to ensure all changes in the codebase apply.

  5. If this is a module or theme update (including security updates) add the follow steps:

    1. lando composer update will update all dependencies, but generally, we want to only update the packages affected by a security update. lando update drupal/core --with-dependencies would update just core and any dependencies for example.

    2. lando drush updb to update the database with any changes from the composer update.

  6. If this change includes configuration or code changes, do them at this step.

    1. If your change includes a scss or javascript code change, ensure that you are watching the changes (either lando yarn watch or lando yarn start) or have run lando run build to build the css and javascript assets for preview locally.

  7. lando drush cex to ensure you have any config changes—including changes caused by updates.

  8. git add -A to add the files to git, and git commit -m "POWR-[ID] concise change description".

  9. git fetch to get any changes since you started. git merge origin/master to ensure these changes are applied to your branch. Resolve any merge conflicts.

  10. git push -u origin powr-[ID] to push to GitHub and set it as the remote.

  11. From https://github.com/eGovPDX/portlandor/pulls, the developer should open the pull request and request reviewers. This will trigger a build to a multidev site and run automated behat tests.

  12. When build has passed (green), the developer should manually confirm their changes on the multidev environment and write up a test plan that should be performed by the QA team. When the multidev is present and ready for the test plan, move the Jira issue to QA and remove the assignment from the issue. This lets the QA team know the story is ready. If you know someone that has been waiting for this work, assigning them as QA is acceptable.

  13. The QA team member (content and support team members primarily, but anyone on our team can QA) should follow the test plan and provide notes to the developer on issues. Since the developer has already tested their code locally and on the multidev, it is the responsibility of QA to help ensure that the test plan is complete enough to ensure the story does not include regressions. Be thorough! 😄 If the multidev looks good, the QA team member may move the story to merge and accept and remove the assignment.

  14. When the story is in merge and accept, and there is at least one team member approval on the pull request, the build lead can merge the PR. This will build to the Dev environment. The build lead should move the jira ticket from Merge and Accept to Done. We consider a story done for the purpose of sprint planning when it has merged into our dev instance and is ready for deployment on Pantheon. When a PR is merged the branch may be deleted. If a PR is closed and will not be reopened, the branch may be deleted.

  15. The build lead may choose to allow several changes to merge to our dev instance before deploying to test. When ready for a build to test and then live, open the Test environment within the Pantheon dashboard, from the Deploys tab, add a deployment note (usually the PR commit message), and trigger build to copy up code from Dev and a database down from Prod. Update database and cache clear will run from a Quicksilver script so these should be left unchecked.

  16. Build lead should repeat deploy steps to the live instance preferably outside of the hours of 8 am to 5:30 pm—our peak traffic. (The site won't completely crash on a production build, but it can cause strange errors for editors currently working on the site.) Because we do not have automated tests on live, it is recommended that the build lead review the changes in the build and manually spot check that the related pages still perform as expected. Double checking the status report and configuration synchronization pages are recommended.

Clone this wiki locally