Confirmed users
396
edits
Jetpack/Release Process: Difference between revisions
→Update AMO Validator
No edit summary |
|||
| (41 intermediate revisions by 4 users not shown) | |||
| Line 7: | Line 7: | ||
== Clone Checklist == | == Clone Checklist == | ||
Click on 'Create' ( below ) to copy this checklist to a new wiki page at Jetpack/SDK/Release_Checklist/VERSION (f.e. [[Jetpack/SDK/Release_Checklist/1.10]]), and choose people to fill the Release Manager (RM), Release Engineer (RE), Technical Lead (TL), and Documentation Lead (DL) roles. Use the checklist to track the status of the release. | |||
<createbox> | |||
align=left | |||
type=create | |||
preload=Jetpack/SDK/TEMPLATE/Release_Checklist | |||
default=1.xx | |||
prefix=Jetpack/SDK/Release_Checklist/ | |||
</createbox> | |||
| | The template for this form is [[Jetpack/SDK/TEMPLATE/Release_Checklist|here]]. | ||
==Past SDK Release checklists== | |||
{{Special:PrefixIndex/Jetpack/SDK/Release_Checklist}} | |||
== Merge Master to Stabilization == | == Merge Master to Stabilization == | ||
| Line 123: | Line 34: | ||
git checkout stabilization | git checkout stabilization | ||
git merge --no-commit master | git merge --no-commit master | ||
# resolve conflicts, if any | # resolve conflicts, if any (don't resolve install.rdf yet!) | ||
git commit -m "merge master into stabilization to start the N.N release cycle" | git commit -m "merge master into stabilization to start the N.N release cycle" | ||
| Line 166: | Line 77: | ||
== File Tracking Bug == | == File Tracking Bug == | ||
File a bug to track the release using [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to= | File a bug to track the release using [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=jgriffiths@mozilla.com&bug_file_loc=https://wiki.mozilla.org/Jetpack/SDK/Release_Checklist/X.X&bug_status=ASSIGNED&comment=We%20should%20release%20Add-on%20SDK%20X.X.%0D%0A%0D%0AUse%20this%20bug%20to%20track%20release%20blockers%20and%20the%20release%20checklist%20%3Chttps%3A%2F%2Fwiki.mozilla.org%2FJetpack%2FSDK%2FRelease_Checklist/X.X%3E%20to%20track%20release%20tasks.%0D%0A&op_sys=All&product=Add-on%20SDK&rep_platform=All&short_desc=release%20Add-on%20SDK%20X.X this release tracking bug template]. | ||
== Notify Relevant Parties == | == Notify Relevant Parties == | ||
| Line 180: | Line 91: | ||
=== PR === | === PR === | ||
Notify the Mozilla PR team ( | Notify the Mozilla PR team (communications@mozilla.com). | ||
PR likes to have the email, despite sitting in the planning meetings. | PR likes to have the email, despite sitting in the planning meetings. | ||
| Line 232: | Line 143: | ||
Notify testers about the build via a post to the discussion forum. Have them run automated and manual tests (including submitting generated XPIs to the [https://preview.addons.mozilla.org/ AMO test server]) and report any bugs they discover. (Mention that testers should not try to submit add-ons built from the test builds to AMO, as it won't pass the validator.) | Notify testers about the build via a post to the discussion forum. Have them run automated and manual tests (including submitting generated XPIs to the [https://preview.addons.mozilla.org/ AMO test server]) and report any bugs they discover. (Mention that testers should not try to submit add-ons built from the test builds to AMO, as it won't pass the validator.) | ||
File a bug in the Builder component to get the test build uploaded to the -dev server. | |||
== Stabilize Codebase == | == Stabilize Codebase == | ||
| Line 387: | Line 300: | ||
== Update AMO Validator == | == Update AMO Validator == | ||
Requirements: working checkout of AMO-validator & prerequisites. Please see the [https://github.com/mozilla/amo-validator/blob/master/README.rst AMO Validator Readme] for the gory details. We should fork the amo-validator repo and then for each release do the following: | Requirements: working checkout of AMO-validator & prerequisites. Please see the [https://github.com/mozilla/amo-validator/blob/master/README.rst AMO Validator Readme] for the gory details. We should fork the amo-validator repo and then for each release do the following: | ||
| Line 398: | Line 309: | ||
./generate_jp_whitelist.sh | ./generate_jp_whitelist.sh | ||
cd ../ | cd ../ | ||
</pre> | |||
Make extra-super sure the pickle file can be git add'ed. If it doesn't show up: | |||
<pre> | |||
rm validator/testcases/jetpack_data.txt.pickle | |||
nosetests</pre> | |||
Then go ahead: | |||
<pre> | |||
git add validator/testcases/jetpack_data.txt | git add validator/testcases/jetpack_data.txt | ||
git add validator/testcases/jetpack_data.txt.pickle | |||
git commit -m "Updated amo-validator with hashes for SDK version x.x.x" | git commit -m "Updated amo-validator with hashes for SDK version x.x.x" | ||
git push origin master</pre> | git push origin master</pre> | ||
Step 2: We issue a pull request to the mozilla/amo-validator and <del>pester</del> engage the AMO devs to accept our updated hash file. | Step 2: We issue a pull request to the mozilla/amo-validator and <del>pester</del> engage the AMO devs to accept our updated hash file, *and* add the tracking bug to the milestone for the next push. '''WARNING: unless the tracking bug is added to the milestone for the next push, the change will not be deployed!!!''' | ||
Step 3: We do some testing on AMO's existing test infrastructure on allizom.com. The test should be essentially: | Step 3: We do some testing on AMO's existing test infrastructure on allizom.com. The test should be essentially: | ||
| Line 409: | Line 328: | ||
Step 4: The changes are pushed with the regular Thursday AMO push. | Step 4: The changes are pushed with the regular Thursday AMO push. | ||
Step 5: Once the AMO push is done, generate an XPI using the release candidate and validate it using AMO in order to verify that the validator has been updated and is working. | |||
== File Builder bug to push build == | |||
Once the Build has been blessed, we need to ensure that it is made available to Builder users as well. The process seems to be: | |||
* File a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=addons.mozilla.org|against AMO] with the 'Add-on Builder' component, to add the new version to production. | |||
* In a branch of your forked repo for Flightdeck, run these commands to add the new version as a submodule to the FlightDeck repo, then issue a pull request: | |||
git submodule add git://github.com/mozilla/addon-sdk.git lib/addon-sdk-(VERSION) | |||
cd lib/addon-sdk-(VERSION) | |||
git checkout (VERSION) | |||
cd ../.. | |||
git add lib/addon-sdk-(VERSION) | |||
#Don't forget to update LOWEST_APPROVED_SDK and TEST_SDK in settings.py for the new SDK version! | |||
git add settings.py | |||
* ensure that seanmonstr / zalun / arron accepts the pull request and tags it. IT can then take this tag and complete the deployment. | |||
* get IT[1] to run the 'add sdk' command on -dev, make sure things work. Also, stephend should be pinged to ensure tests pass on -dev with the new revision: | |||
./manage.py add_core_lib addon-sdk-1.x --useversion=1.x | |||
* Schedule a push with IT[1] and push the site | |||
* Run the 'add sdk' command[1] in production | |||
[1] It seems to help to assign a bug to IT (oremj specifically?) to get things done on IT's side, including a description of what needs to be done. | |||
== Update Latest Builds Redirect == | == Update Latest Builds Redirect == | ||
| Line 439: | Line 381: | ||
Update the IRC topic on #jetpack to announce the new release. | Update the IRC topic on #jetpack to announce the new release. | ||
File a bug in the Builder component to get the new release pushed to the production Builder server. | |||
= Bask = | |||
Bask in the glow of the latest and greatest release! | |||
Physically or virtually high-five or fist-jab contributors. | |||
= Review = | |||
Review the release process via a post-mortem, solicitation of feedback in the weekly meeting and discussion forum, and other methods as appropriate. Identify things that went well and we should continue to do, things that went badly that we should do differently next time, and parts of the process that have changed and for which this document needs to be updated. Make changes as appropriate. | |||
= Panic = | |||
Hot-Fixes are releases that are made directly on the "release" branch, rather | |||
than the usual "stabilization" branch, and contain just one or two fixes | |||
relative to the previous release. The Release Manager may decide to handle | |||
critical bugs in e.g. 1.5 by creating a hot-fix release (1.5.1) instead of | |||
waiting for the next scheduled release cycle (1.6). | |||
To create a hot-fix release, start by creating a branch based off the most | |||
recent release tag, cherry pick the important fix to it from master, make the | |||
release, then merge back to stabilization. | |||
The basic idea is that the "release" branch should always be a descendant of | |||
the "stabilization" branch, so that normal releases (made on stabilization) | |||
cause the "release" branch to be fast-forwarded to the new revision. The | |||
normal release cycle takes care of this automatically: the code is developed | |||
and tagged on stabilization, then "release" is moved forward to point to the | |||
same revision. But since hotfixes are developed on "release", an extra | |||
post-release merge step is necessary to bring "stabilization" up-to-date. | |||
The general process is: | |||
* git clone git@github.com:mozilla/addon-sdk | |||
* cd addon-sdk | |||
* git checkout release | |||
* cherry-pick fixes from master to fix the bug, repeat until it works | |||
* git tag NEWRELEASE | |||
* use 'git archive' to create tarballs | |||
* upload tarballs (644 permissions!) | |||
* git checkout stabilization | |||
* git merge release (this may require conflict-resolution) | |||
* git push origin NEWRELEASE release stabilization | |||
It may be easier to use a personal branch while developing the fix, to share | |||
release candidates with others (especially when asking the original bug | |||
submitter to validate the fix). In that case, the process will look something | |||
like: | |||
* git clone MYGITHUBREPO ; cd MYREPO | |||
* git remote add official git@github.com:mozilla/addon-sdk | |||
* git fetch official | |||
* git checkout -b hotfix official/release | |||
* cherry-pick fixes, share RC builds | |||
* git push origin hotfix (to share code) | |||
* git checkout release | |||
* git merge --ff-only hotfix | |||
* git tag NEWRELEASE | |||
* make+upload tarballs (644 permissions!) | |||
* git checkout stabilization | |||
* git merge official/release (and resolve conflicts) | |||
* git push official NEWRELEASE release stabilization | |||
* git branch -D hotfix | |||
After you make the hotfix, you'll need to get the hotfix pushed to Builder and update the AMO Validator, as detailed further up this page. | |||