Linux.conf.au 2016 – Wednesday – Session 1

Going Faster: Continuous Delivery for Firefox by Laura Thomson

  • Works for Cloud services web operations team
  • Web Dev and Contious delivery lover
  • “Continuous delivery is for webapps” – Maybe not just Webapps? Maybe Firefox too
  • But Firefox is complicated
  • Process very complicated – “down from 5 source control systems to 3”
  • But plenty of web apps are very complicated (eg Netflix)
  • How do we continuous deliver Firefox
  • How it works currently
    • Release every 6 weeks
    • 4 channels – Nightly -> Aurora -> Beta -> release
    • Mercurial Repo for each channel
  • Release Models
    • Critical Mass – When enough is done and it is stable
    • Single Hard deadline – eg for games being mass released
    • Train Model – fixed intervals
    • Continuous Delivery
  • Deployment Maturity Model
  • Updates
    • New Build -> Generate  a diff -> FF calls back -> downloads and updates
    • Hotfixs
    • Addons automatically updated
  • Currently pipeline around 12 hours long, lots of tests and gatekeeping
  • “Go Faster”
    • System add-ons
    • Test Pilot
    • Data Separate from code
    • Downloadable content
    • Features delivered as web apps
  • System addons
    • Part of core FF, modularized into an add-on
    • Build/test against existing FF build, a lot smaller test
    • Updated up to daily(for now) on any release channel
    • signed and trusted
    • Restartless updates
      • install or update without a browser restart
      • Restarts suck
      • Restartsless coming soon for system add-ons
    • Good for rapid iteration, particularly on the front-end
    • Wrappers for services
    • Replacing hotfixes
  • Problems with add-ons
    • Localalisation
    • Optimizing UX : Better browser faster vs update fatigue
    • Upfront telemetry requirements
    • Dependency mngt on firefox
    • Dependency management between system add-ons (coming soon)
  • Add-ons in flights
    • Firefox hello is already an add-on
    • Currently in beta in 45
    • First beta updates before 46
  • Test Pilot
    • Release channel users opt in to new features
    • Release channel users different from pre-release ones
    • Developed as regular ad-ons (not system add ons)
    • Can graduate to system add-ons by flipping a bit
  • Data should be seperate from code
    • Sec policy
    • blocklists
    • tracking protection list
    • dictionaries
    • fonts
  • Many times Data update == release , this is broken
  • Also some have their own updaters
  • Kinto
    • Lightweight JSON storage with sync, sharing, signing
    • Natice JSON over http
    • niceties of couchDB backed by postgressDB
  • How Kinto Works
    • pings for updates
    • balrog supplies link to kinto
    • signed data downloaded, checked, applied
  • Kinto good for
    • Add-ons block list
  • Downloadable Content
    • Some parts of the browser may not need frequently
    • May not be needed on startup
    • eg languages packs, fonts for Firefox on Android
  • Features delivered remotely
    • Browser features delivered as web apps
    • Pull in content from the server
    • in a early stage
  • Futures
    • Easy for projects to impliment
    • Better “knobs and dials” (canaries A?B, data viz)
    • Pushed based updates
    • Simpler localisation
  • Questions
    • They support rollbacks
    • Worst case: Firefox has a startup crash
    • Not sure sure ice weasel would fit in.
    • How will effect ESR channel? – Won’t change, they will stay security-only
    • Bad Addons – Hate ones that reporting user-data, crashers (eg skype toolbar at one point), Highjack your browser and change settings
    • There is much collaboration between [open source] browsers
    • You are avoiding the release cycle, planning to speed it up – Lots of tests that can’t get rid of all, working on it but not a simple thing to solve.
Share