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.
