Firefox/Go Faster/Release Pipeline: Difference between revisions

← Older edit

Firefox/Go Faster/Release Pipeline (view source)

Revision as of 19:20, 4 August 2015

887 bytes added , 4 August 2015

→‎Shipping Infrastructure

Bhearsum

canmove, Confirmed users

6,439

edits

@@ Line 37: / Line 37: @@
 == Shipping Infrastructure ==
+We'll be using AMO + Balrog
-We'll be using AMO.
 See: mrrrgn, bhearsum, ??? (we'll probably need help from other RelEng members)
-===AMO Needed Features / Status: ===
+=== Overview ===
+Balrog will be in charge of making decision about which updates to serve. Firefox will talk to it periodically, and its response will point at AMO and other places where appropriate (eg, Kinto) to serve the actual updates.
+=== AMO Needed Features / Status: ===
 There are some difficulties around using it, but it seems possible to create a working prototype without actually changing its code base (though it will require a workflow with human intervention).
 tl;dr: We'll need a special "GoFast" addon type with improved permissions, and a few REST endpoints (instead of crufty old web forms).
-====Ability to host multiple addon versions at the same time.====
+==== Ability to host multiple addon versions at the same time. ====
 Status: This is supported but only for "listed" [public] addons.
-====Ability to partially roll out updates====
+==== API for uploading addons ====
-Status: The AMO system relies on manifests which map addon versions to supported platforms. Normally users will always get the latest version, but it is possible to package addons with a custom "updateURL" which firefox will use to search for new versions.
+This is currently a multi-part web form. This will need to be turned into an API asap.
-We will also need to build our own service for managing version manifests. The service could be a proxy (more flexible) or a web app (easier to manage) depending on what our needs seem to be as the project progresses.
+=== Balrog ===
+==== Ability to partially roll out updates ====
+Balrog already supports a rolling out changes at different rates. Eg, new Firefox versions are shipped to only 25% of update requests initially, and then rolled out fully later. This allows for widespread testing without rolling out to our entire userbase.
-To use updateURL with a listed update, we will need administrator intervention.
+Balrog does not currently support true A/B testing, as it cannot identify unique browsers across multiple requests for updates. Morgan has some ideas about we could build a proxy on top of Balrog that would allow us to do this, if desired.
-====API for uploading addons====
+==== Multiple types of updates in a single request/response ====
-This is currently a multi-part web form. This will need to be turned into an API asap.
+Balrog's current architecture makes it very difficult to return updates for multiple things in the same request/response. Each update ping can only match one set of data object (which is responsible for generating the response), which means that each unique combination of things that we may want to return requires a new copy of the data. To properly support all of the different types of updates we want to do (system addons, security policy, Fennec stuff, etc.) we will need to rearchitect Balrog to be able to map a single request to multiple pieces of data, and collapse those back into a single response.