diff --git a/docs/conf.py b/docs/conf.py index acf55217..cfbf4cc3 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -87,16 +87,16 @@ # built documents. # # The short X.Y version. -version = '3.0' +version = '2026' # The full version, including alpha/beta/rc tags. -release = '3.0' +release = '2026' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. # # This is also used if you do content translation via gettext catalogs. # Usually you set "language" from the command line for these cases. -language = None +language = 'en' # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: @@ -316,18 +316,10 @@ #texinfo_no_detailmenu = False linkcheck_ignore = [ - # These links require you to be behind the VPN. - 'http://sentry.mktmon.services.phx1.mozilla*', - 'http://dashboard.mktadm.ops.services.phx1.mozilla.com*', - 'https://mana.mozilla.org*', - # For some unknown reason, TravisCI gets a 404 for calendar URLs. - # They require a login so maybe that's why. + # Calendar URLs require a login. 'https://calendar.google.com/calendar/embed*', - # This is a private URL. - 'https://github.com/mozilla/addons-server-security', # TravisCI doesn't like CircleCI (or otherwise) so we get a 404 'https://circleci.com/gh/mozilla*', - 'https://app.datadoghq.com/*', # Ignore this as the fragment id is non-existent. 'https://chat.mozilla.org/#/room/#amo:mozilla.org', # Ignore about: pages diff --git a/docs/index.rst b/docs/index.rst index 1f17a5d1..1102fa7c 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -16,14 +16,13 @@ Contents: repositories.rst browser/index.rst l10n.rst - server/index.rst + push_duty/index.md ux/index.rst random/index.rst Filing bugs: -* Github on `this repository `_. -* Bugzilla +* See [repositories](./repositories.rst) Indices and tables ================== diff --git a/docs/server/push_duty/cherry-picking.md b/docs/push_duty/cherry-picking.md similarity index 100% rename from docs/server/push_duty/cherry-picking.md rename to docs/push_duty/cherry-picking.md diff --git a/docs/push_duty/extension-workshop.md b/docs/push_duty/extension-workshop.md new file mode 100644 index 00000000..9bccc411 --- /dev/null +++ b/docs/push_duty/extension-workshop.md @@ -0,0 +1,6 @@ +# Deploying extension-workshop + +extension-workshop is deployed separately by folks who update its contents +without the involvement of the push hero. + +See [https://github.com/mozilla/extension-workshop#deploymentsreleases](https://github.com/mozilla/extension-workshop#deploymentsreleases) diff --git a/docs/push_duty/index.md b/docs/push_duty/index.md new file mode 100644 index 00000000..d92803a9 --- /dev/null +++ b/docs/push_duty/index.md @@ -0,0 +1,48 @@ +# Push Duty + +Production deploys are scheduled every other week. Push duty rotates each deploy to another developer. The current rotation is: + +- eviljeff +- mat + +## Before the push + +Before a push, we continuously land and deploy code to dev by merging PRs to master in respective repositories. During this time, individuals and/or the push hero might update the upcoming release document with notes for pre/post deployment tasks. Refer to the [release docs](./release-docs) for more information. + +On Tuesday around [09:00 PT](http://www.timebie.com/std/pst.php?q=9), we deploy to stage. This is the time to publish the release that will be deployed to stage (see [release docs](./release-docs)). + +QA will then check stage for defects. + +### Cherry-picks + +If any follow-ups are needed after the release has been deployed to stage, (see [cherry picking](./cherry-picking)). + +## During Push + +On Thursday around [09:00 PT](http://www.timebie.com/std/pst.php?q=9), we deploy to production. This is the time to: + +- Meet with QA in the `#addons-production` slack channel +- Approve the stage deployments to push to production +- Push extension-workshop to production if needed (see [tag-services](./tag-services)) +- Monitor the push in sentry and grafana for any issues (see [monitoring](./monitoring)) + +## After the push + +- Create a new release document for the next push hero (see [release docs](./release-docs)) +- Update the topic of the `#addons-production` slack channel to include the handle of next week's push hero + +## Runbooks + +This section will outline the steps to take for specific actions that you might need to perform before, during and/or after a push. The push runbook is a living document and should be updated as needed. Please reference it in the push notes for each push. As well as in the above push duty document. + +```{toctree} +:maxdepth: 2 + +release-docs.md +tag-services.md +cherry-picking.md +monitoring.md +project-dependencies.md +security-fixes.md +extension-workshop.md +``` diff --git a/docs/push_duty/monitoring.md b/docs/push_duty/monitoring.md new file mode 100644 index 00000000..23dab7cb --- /dev/null +++ b/docs/push_duty/monitoring.md @@ -0,0 +1,15 @@ +# Monitoring + +QA will perform a sanity check on the site once the push is done. + +The best places to monitor the results of the push are: + + * `Sentry `_ + * `Grafana `_ + * `SRE dashboard `_ + * `Prod Health dashboard `_ + * `API usage/performance dashboard `_ + +The site performance graphs should show no large spikes or changes. +Sentry should show no new errors, although it will show intermittent errors and the occasional +error as the push occurs. diff --git a/docs/push_duty/project-dependencies.md b/docs/push_duty/project-dependencies.md new file mode 100644 index 00000000..1cf4e630 --- /dev/null +++ b/docs/push_duty/project-dependencies.md @@ -0,0 +1,15 @@ +# Project dependencies + +Project dependencies are not tagged as part of the push duty responsibilities. +If you're working on a feature in a project that's a dependency of a project +e.g. ``addons-linter``, then it's *your* responsibility to make a release and +update the project that consumes that dependency in time for the tag. + +This way we can ensure that: + + * Dependency packages are built and released in time for the tag. + * The new feature in the new version of a package has been validated on + -dev. + +Making multiple releases of a package during a weekly milestone is totally +fine since this helps with testing smaller sets of changes. diff --git a/docs/server/push_duty/release-docs.md b/docs/push_duty/release-docs.md similarity index 61% rename from docs/server/push_duty/release-docs.md rename to docs/push_duty/release-docs.md index 29c82234..03abeb84 100644 --- a/docs/server/push_duty/release-docs.md +++ b/docs/push_duty/release-docs.md @@ -1,4 +1,4 @@ -# release-docs +# Releasing AMO Until August 22nd 2024, we managed our release documents manually in the addons repository (see [release-docs.rst][addons-releases]). @@ -8,18 +8,22 @@ Currently, [addons-server][addons-server] is the only repository deploying via [ To create a new release, use the [draft release workflow][draft-release-workflow]. - + This will create a new draft release in the repository. This release can be updated with instructions and things to note for the next push. -You need to set the push hero (see [push-duty](./index.md) for the rotation) as the assignee for the draft release. -You also need to specify the next push date. This will be roughly 2 weeks after the current push. The exact date will correspond -with the next jira sprint. +You need to set the push hero (see [push-duty](./index.md) for the rotation) as the assignee for the draft release. and the next push date, in `YYYY.MM.DD` format. This should be 2 weeks after the current push, the exact date will correspond with the next jira sprint. -## Publishing a release +## Deploying to stage -During the tag, we can trigger a staging deployment for `addons-server` by publishing the current draft release -that should have been created at the end of the last push. It will likely be the first release in the [list][addons-server-releases] -and will match the current push tag date. +During the release process, we can trigger a staging deployment for `addons-server` by publishing the current draft release that should have been created at the end of the last push. It will likely be the first release in the [list][addons-server-releases] and will match the current push tag date. + +### Handling addons-frontend + +addons-frontend is currently not using GitHub Actions, so manual tagging is required. See [tag-services][./tag-services.md]. Once the tag has been pushed, CI will run and eventually a new docker image should be built and deployed to stage. + +You can then go back to addons-server draft release to update the compare link to the previous tag for addons-frontend. + +### Publishing a release In order to publish the release, click the edit icon at the top right of the release card. @@ -27,13 +31,13 @@ In order to publish the release, click the edit icon at the top right of the rel - Publish the release by clicking the `Publish release` button. - Include the compare link for `addons-frontend`. See [tagging](./tag-services.md) for details. - + ```{warning} Make sure that the release is tagged as "latest". This is the default behavior but don't accidentally un-check it. ``` - + Publishing a release will trigger the [release workflow][release-workflow]. @@ -52,9 +56,14 @@ to see workflows triggered by a release event that failed. We should include slack notifications for failed CI, especially on deployment triggering workflow runs. ``` +## Deploying to production + +Follow [documentation in Confluence about how to deploy with ArgoCD][deploy-argo-cd]. + [failed-ci-query]: https://github.com/mozilla/addons-server/actions/workflows/ci.yml?query=event%3Arelease+is%3Afailure [release-workflow]: https://github.com/mozilla/addons-server/actions/workflows/release.yml [draft-release-workflow]: https://github.com/mozilla/addons-server/actions/workflows/draft_release.yml [addons-server]: https://github.com/mozilla/addons-server [addons-server-releases]: https://github.com/mozilla/addons-server/releases [addons-releases]: https://github.com/mozilla/addons/tree/main/releases +[deploy-argo-cd]: https://mozilla-hub.atlassian.net/wiki/spaces/SRE/pages/27921597/AMO+Dev+Resources#ArgoCD diff --git a/docs/push_duty/security-fixes.md b/docs/push_duty/security-fixes.md new file mode 100644 index 00000000..e631e7c8 --- /dev/null +++ b/docs/push_duty/security-fixes.md @@ -0,0 +1,14 @@ +# Security fixes + +Security issues against AMO are currently reported in Bugzilla. When someone is +assigned to work on one, they should open a new draft security advisory +describing the security issue and linking to the bugzilla bug, but not publish +it. That unlocks the ability to have a private PR and fork to work on the +issue. + +The corresponding private PR should is reviewed as normal but once it has been +reviewed, it should *not* be merged right away. Instead, it should be called +out in the release notes for the next release. Merging to ``master`` is part +of push duty and happens right before tagging, using GitHub regular merge +functionality on the PR. The advisory can then be closed (it's never +published). diff --git a/docs/server/push_duty/tag-services.md b/docs/push_duty/tag-services.md similarity index 100% rename from docs/server/push_duty/tag-services.md rename to docs/push_duty/tag-services.md diff --git a/docs/repositories.rst b/docs/repositories.rst index b79b6907..ecee3b7d 100644 --- a/docs/repositories.rst +++ b/docs/repositories.rst @@ -17,31 +17,31 @@ An API for building add-ons that works with e10s and is compatible with Google C GitHub ------ -Almost everything else is on GitHub and issues are tracked in GitHub. This is a non-exhaustive list. Other repositories and libraries do appear around these main libraries: +Almost everything else is on GitHub and issues are tracked in GitHub. This is a non-exhaustive list. Other repositories and libraries do appear around these main repositories: addons ~~~~~~ `These docs `__ and an issue tracker. `This repository `__ serves as an umbrella for everything add-ons. -Bug tracker is in GitHub and can be used for almost anything add-ons related. `Existing bugs `__. +Bug tracker is in GitHub and can be used for almost anything add-ons related. `Existing issues `__. + +addons-frontend +~~~~~~~~~~~~~~~~~~~ +The `addons.mozilla.org `__ website. The `repository `__ is on GitHub. addons-server ~~~~~~~~~~~~~ -The `addons.mozilla.org `__ website. The `repository `__ and `issue tracker `__ is on GitHub. Documentation is `on github pages `__. +Complement to addons-frontend, this contains API, Developer Hub, Reviewer Tools and Admin Tools for AMO. The `repository `__ is on GitHub. Documentation is `on GitHub pages `__. In the past this repository has been known as *remora*, *zamboni* or *olympia*. -addons-code-manager -~~~~~~~~~~~~~~~~~~~ -A web application to manage add-on source code, such as reviewing code for add-ons submitted to addons.mozilla.org. The `repository `__ and `issue tracker `__ is on GitHub. +addons-blog +~~~~~~~~~~~ +Static content generator for AMO's blog, `addons.mozilla.org/blog `__. addons-linter ~~~~~~~~~~~~~ The linter checks WebExtensions for common errors and potential problems. It is used on `addons.mozilla.org `__ and `web-ext `__. It can also be run in stand-alone mode. The `repository `__, `issue tracker `__ and `documentation `__ is on GitHub. -dispensary -~~~~~~~~~~ -The dispensary collects and offers hashes of popular JavaScript libraries, mainly for the Mozilla's `addons-linter `__. The `repository `__ and `issue tracker `__ is on GitHub. - web-ext ~~~~~~~ This is a command line tool to help build, run, and test `WebExtensions `__. The `repository `__ and `issue tracker `__ is on GitHub. The `documentation `__ and `command reference `__ is on Extension Workshop. diff --git a/docs/server/index.rst b/docs/server/index.rst deleted file mode 100644 index d0058a30..00000000 --- a/docs/server/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -Server -====== - -About the `add-ons server `_. - -Contents: - -.. toctree:: - :maxdepth: 2 - - push-duty.rst - push_duty/index.md diff --git a/docs/server/push-duty.rst b/docs/server/push-duty.rst deleted file mode 100644 index f9ded63c..00000000 --- a/docs/server/push-duty.rst +++ /dev/null @@ -1,206 +0,0 @@ -Push Duty -========= - -The pushing of the server rotates each week to another developer. Current rotation is: - -* eviljeff -* mat -* kmeinhardt - -Check out the `Add-ons calendar `_ for a list of events. - -Before the push ---------------- - - -The code that will go in production on Thursday is tagged on Tuesday -at `09:00 PT `_. -The following repositories are tagged: - - * `addons-server `_ - * `addons-frontend `_ - * `addons-code-manager `_ - -The following repositories are immediately deployed to production when -they are tagged. As such, one can update these projects at any time: - - * `extension-workshop `_ - -Project Dependencies -++++++++++++++++++++ - -Project dependencies are not tagged as part of the push duty responsibilities. -If you're working on a feature in a project that's a dependency of a project -e.g. ``addons-linter``, then it's *your* responsibility to make a release and -update the project that consumes that dependency in time for the tag. - -This way we can ensure that: - - * Dependency packages are built and released in time for the tag. - * The new feature in the new version of a package has been validated on - -dev. - -Making multiple releases of a package during a weekly milestone is totally -fine since this helps with testing smaller sets of changes. - -Security Fixes -++++++++++++++ - -Security issues against AMO are currently reported in bugzilla. When someone is -assigned to work on one, they should open a new draft security advisory -describing the security issue and linking to the bugzilla bug, but not publish -it. That unlocks the ability to have a private PR and fork to work on the -issue. - -The corresponding private PR should is reviewed as normal but once it has been -reviewed, it should *not* be merged right away. Instead, it should be called -out in the release notes for the next release. Merging to ``master`` is part -of push duty and happens right before tagging, using GitHub regular merge -functionality on the PR. The advisory can then be closed (it's never -published). - -Tag the repos -+++++++++++++ - -Tags are of the format: ``YYYY.MM.DD``, - -.. note:: The date is the date of the push, not the date of tagging. - -.. note:: Once addons-frontend has been tagged a new docker image will be - built on `CircleCI`_ and is - required to deploy to stage. - -It's usually the main branch that is tagged:: - - $ git checkout main - $ git pull - $ git tag 2015.09.10 - $ git push upstream 2015.09.10 - -.. note:: Here we are using "upstream" as the remote. If yours is different - you can substitute "upstream" for whatever you call the ``mozilla/addons-server`` - repo remote. - -Get a compare link from github to compare this tag to the last tag. Add that -compare link to the push doc so that people can clearly see what is pushing. - -If tagging the main branch can't be done (some feature is already on main, -but not ready for production), then the commits that need to be released -should be cherry-picked - -If you're adding cherry-picks to a tag that already exists, it makes sense to -create a new tag rather than overwrite the old one. The reason for this is that -re-using a tag makes it less easy to see the process that was involved in arriving -at that tag. Also, it's entirely possible to make a mistake by using an old tag -that exists locally rather than the newer version on the remote when tags are -re-used. - -When creating a new tag you can use the format ``YYYY.MM.DD-SUFFIX`` where suffix -is a number that's incremented with each revision. The first time this is done -will look like this:: - - $ git checkout 2015.09.03 - $ git cherry-pick # as many times as you need - $ git tag 2015.09.10-1 - $ git push upstream 2015.09.10-1 - -And the second:: - - $ git checkout 2015.09.03-1 - $ git cherry-pick # as many times as you need - $ git tag 2015.09.10-2 - $ git push upstream 2015.09.10-2 - -Then update the push doc with the new comparison link for the updated tag. - -Extension Workshop -__________________ - -As of April 2024, Extension Workshop only has two environments: - -* `stage `_ - auto-deployed on every commit pushed to the main branch -* `prod `_ - deployed with a tag (``YYYY.MM.DD``) - -You should manually sense-check the stage environment is currently okay -before tagging, and then creating and pushing a git tag to the Extension -Workshop repository will deploy it to production. You should manually -verify the site on prod after the push has been completed. Visit -https://extensionworkshop.com and view any pages that have been changed -since the last push to verify they exist and are rendering properly. :: - - $ git checkout master - $ git pull - $ git tag 2024.04.18 - $ git push upstream 2024.04.18 - -Push to stage -+++++++++++++ - -Our infrastructure automates pushing the tags to stage once the tags have -been pushed up to the repository. - -The only required step is to check that the tag has deployed by looking out for the automated push messages in the internal slack channel. - -You can also check ``/__version__`` or ``/__frontend_version__`` on a given service which shows the currently -deployed revision and tag e.g: - - * `Addons Server (stage) `_ - * `Addons Frontend (stage) `_ - * `Addons Code Manager (stage) `_ - -Extract locales -+++++++++++++++ -Once you are done pushing the tags to stage: - - * Run the ``./bin/run-l10n-extraction`` command in ``addons-frontend`` repository (`documentation `_). - * Run the ``./scripts/extract-l10n.sh`` command in ``addons-server`` repository. - -Because the `addons-server` is meant to be used inside the docker container, it doesn't have access to your `git` credentials, so you'll need to enter the container, run the script, exit the container and push the branch created by script. The `addons-frontend` one does that for you, but in both cases you'll need to open the pull request yourself. - -Before the push -+++++++++++++++ - -Keep an eye out for any blocking bugs. Add them to the etherpad and find -someone to work on them. - -Push ----- - -The tag is pushed to production by ops (wezhou), once approved by QA (Krupa), on Thursdays. -It is the responsibility of the push hero to follow-up with QA and ops, -and be around during the push for any unexpected issues. - -Monitoring the push -+++++++++++++++++++ -The best places to monitor the results of the push are: - -* `Sentry `_ -* `Grafana `_ - - * `Ops dashboard `_ - * `Prod Health dashboard `_ - * `API usage/performance dashboard `_ - -The site performance graphs should show no large spikes or changes. -Sentry should show no new errors, although it will show intermittent errors and the occasional -error as the push occurs. - -Once complete -+++++++++++++ - -Create a new github document for the *next push*, for example: - -https://github.com/mozilla/addons/blob/main/releases/2019/05/09.md - -You can use this handy template: - -.. literalinclude:: /server/push_notes.tpl - -Set the topic of the `AMO Matrix channel `_ and `#remora` slack channel to include the new github doc link and the relevant nickname of next week's push hero. - -Future Goals ------------- - -Move to continuous deployment and change the way this is done dramatically. - -.. _`CircleCI`: https://circleci.com/gh/mozilla/addons-frontend diff --git a/docs/server/push_duty/deployments.md b/docs/server/push_duty/deployments.md deleted file mode 100644 index ab88fb00..00000000 --- a/docs/server/push_duty/deployments.md +++ /dev/null @@ -1 +0,0 @@ -# deployments diff --git a/docs/server/push_duty/extension-workshop.md b/docs/server/push_duty/extension-workshop.md deleted file mode 100644 index 202ac0fc..00000000 --- a/docs/server/push_duty/extension-workshop.md +++ /dev/null @@ -1 +0,0 @@ -# extension-workshop diff --git a/docs/server/push_duty/extract-locales.md b/docs/server/push_duty/extract-locales.md deleted file mode 100644 index 59fd4556..00000000 --- a/docs/server/push_duty/extract-locales.md +++ /dev/null @@ -1 +0,0 @@ -# extract-locales diff --git a/docs/server/push_duty/index.md b/docs/server/push_duty/index.md deleted file mode 100644 index 2bf1a11d..00000000 --- a/docs/server/push_duty/index.md +++ /dev/null @@ -1,54 +0,0 @@ -# Push Duty (Next) - -Push duty rotates each week to another developer. The current rotation is: - -- eviljeff -- mat - -Check out the [Add-ons calendar](https://calendar.google.com/calendar/embed?src=mozilla.com_lr5jsh38i6dmr72uu4d1nv7dcc@group.calendar.google.com) for a list of events. - -## Before the push - -Before a push, we continuously land and deploy code to dev by merging PRs to master in respective repositories. During this time, individuals and/or the push hero might update the upcoming release document with notes for pre/post deployment tasks. Refer to the [release docs](./release-docs) for more information. - -On Tuesday at [09:00 PT](http://www.timebie.com/std/pst.php?q=9), we deploy to stage. This is the time to: - -- push tags for manually deployed services (see [tag services](./tag-services)) -- publish the release document. (see [release docs](./release-docs)) -- QA and cherry pick if necessary (see [staging QA](./staging-qa) and [cherry picking](./cherry-picking)) - -## During Push - -On Thursday at [09:00 PT](http://www.timebie.com/std/pst.php?q=9), we deploy to production. This is the time to: - -- meet with SRE and QA in the remora slack channel (see [remora](./remora)) -- approve the stage deployments to push to production (see [deployments](./deployments)) -- push extension-workshop to production if needed (see [tag-services](./tag-services)) -- monitor the push in sentry and grafana for any issues (see [monitoring](./monitoring)) - -## After the push - -- create a new release document for the next push hero (see [release docs](./release-docs)) -- update the topic of the AMO Matrix channel and the #remora slack channel to include the handle of next week's push hero (see :doc:`remora <./remora>`) - -## Runbooks - -This section will outline the steps to take for specific actions that you might need to perform before, during and/or after a push. The push runbook is a living document and should be updated as needed. Please reference it in the push notes for each push. As well as in the above push duty document. - -```{toctree} -:maxdepth: 2 - -release-docs.md -tag-services.md -staging-qa.md -cherry-picking.md -deployments.md -remora.md -monitoring.md - -project-dependencies.md -security-fixes.md -extension-workshop.md -push-to-stage.md -extract-locales.md -``` diff --git a/docs/server/push_duty/monitoring.md b/docs/server/push_duty/monitoring.md deleted file mode 100644 index 35325515..00000000 --- a/docs/server/push_duty/monitoring.md +++ /dev/null @@ -1 +0,0 @@ -# monitoring diff --git a/docs/server/push_duty/project-dependencies.md b/docs/server/push_duty/project-dependencies.md deleted file mode 100644 index d18b3d32..00000000 --- a/docs/server/push_duty/project-dependencies.md +++ /dev/null @@ -1 +0,0 @@ -# project-dependencies diff --git a/docs/server/push_duty/push-to-stage.md b/docs/server/push_duty/push-to-stage.md deleted file mode 100644 index 78f97d8f..00000000 --- a/docs/server/push_duty/push-to-stage.md +++ /dev/null @@ -1 +0,0 @@ -# push-to-stage diff --git a/docs/server/push_duty/remora.md b/docs/server/push_duty/remora.md deleted file mode 100644 index c55a0f7b..00000000 --- a/docs/server/push_duty/remora.md +++ /dev/null @@ -1 +0,0 @@ -# remora diff --git a/docs/server/push_duty/security-fixes.md b/docs/server/push_duty/security-fixes.md deleted file mode 100644 index e6b54fd8..00000000 --- a/docs/server/push_duty/security-fixes.md +++ /dev/null @@ -1 +0,0 @@ -# security-fixes diff --git a/docs/server/push_duty/staging-qa.md b/docs/server/push_duty/staging-qa.md deleted file mode 100644 index d0f1fcb5..00000000 --- a/docs/server/push_duty/staging-qa.md +++ /dev/null @@ -1 +0,0 @@ -# staging-qa diff --git a/docs/server/push_notes.tpl b/docs/server/push_notes.tpl deleted file mode 100644 index be594c24..00000000 --- a/docs/server/push_notes.tpl +++ /dev/null @@ -1,26 +0,0 @@ -# AMO Release Thursday 13th September 2018 - -This week's push hero is @GithubUsername - -## Notable things shipping: - -## Blockers: - -## Cherry-picks: - - - -## Pushing: - -- https://github.com/mozilla/addons-server/compare/YYYY.MM.DD...YYYY.MM.DD -- https://github.com/mozilla/addons-frontend/compare/YYYY.MM.DD...YYYY.MM.DD -- https://github.com/mozilla/addons-code-manager/compare/YYYY.MM.DD...YYYY.MM.DD - -## Before we push: - -## Before we start: - -## Before we promote: - -## After we're done: