Phabricator/UpgradeProcess: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (added an info that a mozphab repo needs to be commited)
(Removed the content)
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Phabricator Releases ==
This document is now moved to [https://mana.mozilla.org/wiki/display/EW/Phabricator+-+Update+Process Mana]
 
Phabricator is "released" approximately every two weeks when the developers merge changes into the stable branch.  Mozilla's instance is kept at a fairly recent revision so that we can catch changes that break our extension early and avoid them piling up, and so that if there is a security release we can upgrade quickly.
 
== Process ==
 
1. 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".
 
2. The upgrade mechanic should bump the Phabricator revision hash in a local clone and build the container.
 
2.1 Update the shas in `mozphab/Dockerfile` as described:  https://github.com/darkwing/mozphab/blob/master/Dockerfile#L11
 
2.2. In the mozphab clone, build the mozphab:test image with:  `docker build -t mozilla/mozphab:test .`
 
2.3. In my phabricator-extensions clone create the phabext:test image
 
* Modify `Dockerfile`, change the image to `mozilla/mozphab:test`
 
* Run: `docker build -t mozilla/phabext:test .`
 
2.4. In my bmo-extensions clone, change `docker-compose.yml` file's `phabricator->image` to `mozilla/phabext:test`
 
* make sure you do not override this in `docker-compose.override.yml`
 
2.5. Run `docker-compose up --build` in the `bmo-extensions` directory. This will spin up all containers with an additional one called shell with arc installed.
 
2.6. Make sure that the you configure your Firefox proxy to use the tinyproxy started on docker-ip:1090.
 
2.7. Go to http://phabricator.test in firefox - you should get an error message about a MySQL upgrade if this upgrade cycle had any.
 
2.8 Upgrade database: SSH into bmo-extensions' phabricator (`docker exec -it bmoextensions_phabricator_1 /bin/sh`), run db migration: `phabricator/ $ ./bin/storage upgrade`
 
3. The upgrade mechanic performs a simple smoke test: start up the phabricator.test container and log in, post a revision, accept the revision, verify that the attachment is created and r+ed in BMO.
 
* To run arc commands the upgrade mechanic can use the shell container: `invoke shell`
 
4. If the smoke test fails, the mechanic files bugs as appropriate.  At the next standup, determine the priority of these fixes and if they should fit into the current sprint, or if the upgrade should be delayed to the next sprint.
 
5. If the tests pass immediately, or if the bugs are fixed and the tests then pass, commit the mozphab with updated hash and file a bug under Conduit :: Infrastructure noting the new hash.
 
6. On the following Tuesday, operations will deploy to dev.  The upgrade mechanic should do the same simple smoke test on the dev system.
 
7. If the dev smoke test passes, note this in the bug.  If not, go to step 4.
 
8. On Wednesday (possibly the next week if there were bugs), operations deploys to stage and updates the bug, assigning it to QA (chartjes).
 
9. 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.''
 
10. If QA gives is a pass (in the bug), operations deploys to production on Thursday.  Otherwise go to step 4.

Latest revision as of 10:50, 1 May 2018

This document is now moved to Mana

Retrieved from "https://wiki.allizom.org/index.php?title=Phabricator/UpgradeProcess&oldid=1193085"