From MozillaWiki
Jump to: navigation, search

Phabricator Releases

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.


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. TO DO: describe this in more detail.

3. The upgrade mechanic performs a simple smoke test: start up the demo container and log in, post a revision, accept the revision, verify that the attachment is created and r+ed in BMO.

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 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 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.