Ubuntu Touch release process: From code to image update

Milestone Preparation and Testing

Ubuntu Phone currently follows a six-week update cadence. This means that every six weeks a new OTA update is being prepared and released to the stable channel. Everything starts with a list of critical bugs that are targeted for the update – this list is created by the Product Team in cooperation with the Landing Team. Generally, the first four weeks are used for development, during which developers write code and release it through the CI Train.

At the fourth week, the release manager also calls out a feature and string freeze, similar to what's happening in the desktop Ubuntu before release. During this freeze period, no new features or changes to UI strings are normally allowed.

Next, in the week of the milestone, the Landing Team calls out the final freeze, closing the all Touch landings. From this point on, nothing except update-blocking fixes can land to the archives. The most recent rc-proposed image containing all changes up to this point is then handed over to the QA team for testing.

The diagram in Figure 5 outlines the testing procedures. The QA team takes the image for each of the production devices and first performs sanity testing. The sanity test suite's purpose is to check whether the basic functions of the phone are working correctly – things like calls, messaging, basic networking, location, etc.

Figure 5: Various stages of image testing done on a release candidate.

Once all production devices look correct, the QA team moves on to regression testing. This is a very detailed and time-consuming manual test suite; its purpose is to make sure no new unplanned user-visible regressions (variations from the usual behavior) are visible on the image. This step usually takes around two to three days, depending on the number of devices that need to be tested. At the same time, the Landing Team also consults the autopilot smoke-testing results, making sure that automated testing works as expected.

For some devices, the team also tries to build in time for manufacturers to perform their own testing before releasing the update for their platforms. This usually happens after the image has passed internal Canonical testing. This is also the time when all the candidate images are copied into the rc channel.

OTA Update

Once the test results are in, all the manufacturers are happy, and no blocking bugs have been found, the Landing and Product Teams make the final decision about image promotion. The release notes are finalized, and the images are prepared for release. Note that the update doesn't have to be published for all devices at once.

Sometimes, when one of the platforms is thought to not have sufficient quality, the Landing and Product Teams can decide to release the update only for selected platforms – with the rest later, after the fixes for the shortcomings are ready and landed. (See the "Product and Landing Teams" box for more information.)

Each standard update uses the so-called "phased upgrade" mechanism. Every new stable image is rolled out to users in phases, meaning not all of them get the update at once. This acts as a final safety net, allowing the team to roll-back the update in case there's something really broken that got missed by all the previous testing steps. In that case, the image only gets to a limited number of users.

The phased upgrade takes usually up to 24 hours, with the new version reaching more and more users with each hour. After that, all users should be able to see the new OTA update notification on their phones. Then, the freeze is lifted, and all the developers start preparations for the next update. And, the story starts all over again (see Figure 6).

Figure 6: An OTA update ready to be installed.