Phabricator/UpgradeProcess: Difference between revisions

Phabricator/UpgradeProcess (view source)

Revision as of 18:55, 12 February 2018

1,032 bytes added , 12 February 2018

add deployment bugs

Mcote

Confirmed users

1,927

edits

@@ Line 5: / Line 5: @@
 == Process ==
-. At the end of every Conduit sprint, the team picks someone to handle the next upgrade.  This role should rotate among the team.  We'll call this person the "upgrade mechanic".
+. Approximately every two weeks, the team picks someone to handle the next upgrade.  This role should rotate among the team.  We'll call this person the "upgrade mechanic".  File a tracking bug filed under Conduit :: Infrastructure with the summary "Upgrade Phabricator to week {WEEK}", where {WEEK} is taken from the [https://secure.phabricator.com/w/changelog/ Phabricator Changelog], e.g. "2018 Week 6".
 . The upgrade mechanic should bump the Phabricator revision hash in a local clone and build the container.
@@ Line 41: / Line 41: @@
 . When the change is merged the new mozilla/mozphab image is built by circle ci and the new docker sha will be at https://hub.docker.com/r/mozilla/mozphab/tags/. Add the new hash to phabricator-extension's Dockerfile, commit and create the revision in Phabricator.
-After landing the revision file a bug under Conduit :: Infrastructure noting the new hash  of the phabext container which will be at https://hub.docker.com/r/mozilla/phabext/tags/.
+. After landing the revision file a bug under Cloud Services :: Operations: Phabricator, blocking the tracking bug filed in step 1 above.  The description should follow this template:
-. On the following Tuesday, operations will deploy to dev.  The upgrade mechanic should do the same simple smoke test on the dev system.
+    Summary: Please deploy Phabricator image {HASH} to dev
+    Description:
+    Phabricator Extension Container Hash: {HASH}
+    {extra instructions related to this deploy, including addition of new ENV vars}
-. On Wednesday (possibly the next week if there were bugs), operations deploys to stage and updates the bug, assigning it to QA (chartjes).
+{HASH} should be replaced by the new hash of the phabext container, which will be at https://hub.docker.com/r/mozilla/phabext/tags/.
-. QA runs the bigger [[Phabricator/TestPlan|test plan]] against stage. ''At this time there are issues with stage caused by BMO stage being behind a VPN.  We will use dev for QA's testing until this problem is solved.''
+. On the following Tuesday, operations will deploy to dev.  The upgrade mechanic should do the same simple smoke test on the dev system.  The mechanic should then file a stage deployment bug.  Use the same location and template as in step 7, replacing "dev" with "stage" in the summary.
-. If QA gives is a pass (in the bug), operations deploys to production on Thursday.  Otherwise go to step 4.
+. On Wednesday (possibly the next week if there were bugs), operations deploys to stage.  The mechanic should set a needinfo flag to the QA person (e.g. chartjes) on the tracking bug filed in step 1 indicating that the deployment is ready to test. ''At this time there are issues with stage caused by BMO stage being behind a VPN.  We will use dev for QA's testing until this problem is solved.''
+. QA runs the bigger [[Phabricator/TestPlan|test plan]] against stage (''dev for now'').  Results should be posted in the tracking bug, clearing the needinfo.
+. If the tests passed, the mechanic should file a prod deployment bug, again as in step 7 but with "prod" in the summary.  Otherwise go to step 4.
+. When prod is deployed, resolve the tracking bug as FIXED.