Years ago someone asked me what the fastest way to stand up an App Marketplace was. After considering that we already had several Add-on Types in AMO I replied that it would be
to create another Add-on Type for apps, use the AMO infrastructure as a foundation for logins/reviews/etc. and do whatever minor visual tweaks were needed. This was a pretty quick
solution but the plan evolved and "minor visual tweaks" turned into "major visual changes" and soon a completely different interface. Fast forward a few years and we have two
separate sites (addons.mozilla.org and marketplace.firefox.com) running out of the same code repository but with different code. Much of the code is crudely separated (apps/ vs
mkt/), but there are also many shared files, libraries, and utilities, both front and backend. The two sites run on the same servers but employ separate settings files.
There has been talk about combining the two sites so that the Firefox Marketplace was the one stop shop for all our apps/add-ons/themes/etc. but there was reluctance to move down
that path due to the different user expectations and interfaces - for example, getting an app for your phone is a lot different flow than putting a theme on Firefox. While the debate
has simmered with no great options the consequences of inaction continue to grow. Today's world:
An awkward layout where both sites live in the same repository, but only Marketplace talks to Persona and has it's own separate
front-end. Aside from lopsided services, it suffers:
- Automated unit tests which take far longer than necessary to run because they run for both sites.
- Frustration for developers who change code in one area and affect a completely different site.
- Confusion for any new employees or contributors as they struggle to set up the site (despite our decent documentation).
- A one-size-fits-all infrastructure approach with no ability to optimize for the very different sites (API/service based vs standard MVC)
The best way to relieve the stress points above is complete separation of addons.mozilla.org and marketplace.firefox.com. Below is a new
diagram describing the short-term and long-term vision as well as a step-by-step plan for getting us there.
Episode IV: A New Repository
- ✔ DoneClone zamboni into a new repository (named olympia)
- ✔ DoneClone the lightweight theme review queue back into AMO. We're totally Charlie Browning this queue, but it won't be wasted in the Marketplace because we'll need to support wallpapers there soon.
Episode V: The Infrastructure Strikes Back
- Split marketplace-dev and amo-dev to deploy from the separate repositories. Clone the database and point amo-dev to the new database.
- Split the supporting services where needed: separate rabbit, celery, redis. They can run on the same -dev box, but should have their own services.
- Split mana documentation, split dreadnot. Distribute new URLs where appropriate.
- Deploy olympia to Jenkins. Make sure the Marketplace instances are only trying to run Marketplace tests.
- At this point the two are 100% separated
- QA vigorously
- Repeat from step 1 on stage, then production
Episode VI: The Return of the Code
- Spend some time stripping out Marketplace specific code from the new repository. It doesn't need to be perfect yet.
- Spend some time stripping out AMO specific code from Zamboni. It doesn't need to be perfect yet.
- While doing the two steps above, identify and extract code into libraries where possible which can be shared between the two sites. File bugs for these.
- Split the documentation, get the new docs running on rtd.
- Update the contributing docs
Episode I: The Menacing Clones
- Write some migrations to split data. File bugs for them.
- Reviewer Stats (be careful about this, as theme reviews have been going into Marketplace). Let Reviewers know to expect a drop in scores.
- Remove add-ons from Marketplace; Apps from AMO
- Remove add-ons stats from Marketplace; Apps stats from AMO
- Remove _amo and _mkt postfixes on waffle tables. Also amo_log tables.
- Remove mkt/amo specific tables where appropriate