08 April 2021 Ember Upgrade Sprints
Keeping our British Gas web applications up to date
Senior Product Engineer
8 April 2021 - 4 min read
In this post I will share how we update our apps and the benefits of the new upgrade sprint process we introduced last year.
We have over 25 EmberJS web applications at British Gas and keeping them up to date is very important to receive the latest security fixes in particular. The payments application, for example, handles over 10,000 payment transactions a week and it’s crucial that the latest patches are applied, so we stay PCI compliant. Failure to do so could result in us not being allowed to take card payments.
Previous upgrades were undertaken by product teams on an ad-hoc basis and it was hard for POs to plan the work. The new proposed approach was to run upgrade sprints in line with the Ember LTS release schedule below, with product teams working collaboratively to upgrade their Ember apps, engines and addons.
EmberJS is known as ‘a framework for ambitious web applications’ and adopts the convention over configuration approach providing libraries and APIs that have set rules for how developers should code, test and deploy their application. Ember has a strong commitment to stability and follows a 6 week release cycle with an LTS (long term support) version declared every 4 minor versions.
LTS versions have the following advantages:
- An LTS release is the best version to use if your app is not updated frequently
- Best for large, complex apps, since these versions get even more testing and scrutiny than usual
- Before a version can be called an "LTS" release, it has to spend at least 6 weeks as a stable release, where it is used and tested by thousands of developers
Current Ember LTS Schedule
|LTS version||Promotion date||Bugfixes until||Security patches until|
|3.24||February 25, 2021||November 4, 2021||March 10, 2022|
|3.20||August 24, 2020||May 3, 2021||September 6, 2021|
Bugfixes are provided for 8 months and security patches for a year. Assuming we are not affected by new bugs found after November, we could upgrade to the current version 3.24 and not have to upgrade again until March ‘22.
In order to catch any issues early, prior to running the sprints one of senior developers started the upgrade process for our largest app Online Account Management (OAM), as well as our shared repos. All apps consume 2 shared Ember addon repos which contain the following:
- Ember Data models
- Ember Data adapters & serializers to format network requests and responses
- Mock server (Mirage) models, adapters & serializers
- Shared services eg authentication, metrics & error tracking
- UI components
- Form validation libraries
- Template formatting helpers
Ember Data is a data persistence library used for formatting and normalizing responses from our 200+ web APIs and managing a local cache (store) of data in the browser. As well as EmberJS, we needed to make sure that Ember Data was also upgraded where possible. We use the Ember Data Model Fragments library extensively across our apps which can cause compatibility issues.
These were run last September for v3.4 => v3.16 and in March this year for v3.24. One developer from each of our product teams were assigned to a sprint and 2 sprints were run over a month. The OAM app was upgraded first, as well as other apps that take payments and the remaining were upgraded in the second sprint. A temporary Slack channel was created for each sprint which kept conversations focused and issues were communicated openly.
Apps are upgraded using Ember-CLI and the following procedure was taken by each team for their app:
- Upgrade using the Ember-CLI-Update addon via the CLI
- Ran Ember upgrade process if not already run previously
- Resolve conflicts as files will have been changed by the procedure eg configs and lint rules
- Ran codemods to automatically upgrade code & templating syntax
- Fixed local tests
- Upgraded code syntax where needed
Issues and challenges we encountered
Major version changes give us the most problems and it took us a long time to update from 2.18 => 3.4. These upgrades were for minor releases however, but we still had quite a few issues including:
- Changes introduced by the new Ember edition Octane
- Updates to the QUnit test framework resulting in a lot of CSS selector changes in tests
- Linting library & rule changes which introduced new test errors and warnings
- Removing deprecated Ember APIs which broke tests
- Updating addon dependencies, eg ember-moment, a date formatting library
Testing & Release
Once all our tests were passing in our CI environment, they were sent to QA for testing which typically took a week. For OAM, rather than deploy straight to production, we released a Canary version first to a limited number of users which we could control and revert if necessary. Canary releases mean having 2 branches deployed to production and is only practical for a few days as any releases to the main branch need to be merged to the epic branch as well.
By collaborating and sharing our knowledge in Upgrade Sprints, we can resolve issues faster, which may have been encountered before. Developers get to work with others outside of their team and see how we upgrade our apps and gain more experience with Ember. From an Agile perspective, by aligning our sprints with the Ember LTS release cycle, we know when the upgrades will be required, making it easy for POs to schedule the work.