3 of 19

Welcome to CI Airline

Your safest and fastest path to the next

Ubuntu image

I hope he didn’t see that wasn’t an Ubuntu phone.

4 of 19

Developer journey on the 5 main cases

Canonical – Strictly non confidential

Features delivery
Transitions handling
Fixes involving multiple components
(Major version of external component update)
Small bug fixes

5 of 19

Features delivery

Or anything which involved multiples components or a big change

6 of 19

What are we trying to do?

Canonical – Strictly non confidential

Ensuring safety of what we deliver
Being fast
Getting constant and quick feedback on your test results
Provide a service for policy and design reviews to happen in a single place and allowed them to be involved before we release that feature
Knowing to who bears responsibility
Getting a good vision on what we land and when and how far are you to deliver your features
Keep development closely aligned to trunk while not disrupting daily development workflow
Having the potential of unifying core devs and upstream engineering workflows under a single process

7 of 19

Step 1: checking-in

Canonical – Strictly non confidential

Writing in a bug/blueprint/any system what this change is about.

Getting a boarding pass (identification of this request)
Getting an ETA for it
List involved components (luggages): branches or source packages
You subscribe the tests that are needed to be run (for other apps and us)
You can always add more luggages later on

This is basically a blueprint registration, with milestone gates

8 of 19

Step 2: passing security gate

Canonical – Strictly non confidential

Once you are registered to the desk:

Create an semi-isolated environment for you to work and commit safely as:

You build in an isolated ppa (always know you can build your work)
Test are running on a image # set in stone (that you can update)
This temporary silo offers all modern CI infra (automated merge…)

While getting constant feedback on the moving pieces. You always know:

if you are mergeable to trunks or able to upload those components

if it’s the case: simulated merged to trunk, you know if your tests are still passing

if your components have their tests working against the latest proposed and promoted image

Upstream-merger on separate master trunk with private daily-build ppa on chosen image

9 of 19

Step 3: waiting to board

Canonical – Strictly non confidential

Getting a stamp

A custom image is built with your changes
Product Manager, Design and QA should test those changes and sign off.
If there are any packaging changes, a core developer from UE validates those.
You have feedback when a potential previous lock is released, processes are followed rightly and the landing team / distro team +1 on boarding.

No real equivalent, but potential ack from landing asks and release team

Note that depending on where we are in the development cycle, this stamp can be automated

10 of 19

Step 4: boarding

Canonical – Strictly non confidential

Assessment “my changes are ready to land now”

Get a lock on those components
You commit to track and resolve until the changes really land in the next image (or release pocket?)
Merging to trunk, building packages, rerunning tests, getting that to distro

Waiting for an available slot (but automated)

11 of 19

Step 5: flying

Canonical – Strictly non confidential

Ensuring a safe flight on your components

As you have a lock, you are sure to not have any external change to your code.
The tower control is helping you knowing where you code is (proposed, release, next image?)
If an incident occurs:

we avoid a crash and repair “on the fly”.
or we return to base and drop you off safely back in the boarding area.

Uploading/Copying to archive (-proposed, release pocket and even image creation?)

12 of 19

Step 6: landing

Canonical – Strictly non confidential

Everything went fine!

Locks are released (grabbing your luggages)
You get feedback on the ticket that is now used
You can continue your journey (connection) and proceed with another step of this feature landing

Merging back your changelog.

13 of 19

Summary of this workflow

Canonical – Strictly non confidential

You are getting a boarding ticket

Creates an isolated environment to focus on your work, but still knowing where you are at with the big picture

All parties involved ack before boarding once you are ready

We put locks on those components so that you own them

Upstream is involved thanks to the control tower to ensure we deliver in a safe and fast way

14 of 19

Isolated bug fixes

Should be the exception, we don’t have bugs ;)

15 of 19

Isolated bug fixes

Canonical – Strictly non confidential

Low cost ticket

Direct merge request as of today
Immediately delivered to distro
Tests ran before delivery

16 of 19

Benefits / Challenges

17 of 19

Benefits / challenges

Canonical – Strictly non confidential

What we really gain:

We can land and think about our delivery in a more transactional, and “quality-readiness” based way
We control what we deliver, no more interdependencies mix
We (management, community) can have a good view on what is delivered, what is currently in the delivery process, what doesn’t progress
More systematic and automated process
Happier, more relaxed landing

Challenges we need to be careful on:

Mind shift in the way we develop software. We have to guide our developers on that road. Not being tempted to use the fast track procedure for cases that aren’t qualified to it
Tune to get a fluid process with stellar feedback/communication on landings
Getting that working along source packages we are not upstream for when they are involved and community

18 of 19

Feeling guilty…

“We will pair the absolute resilience to failure and the precision of the aviation industry with modern software engineering”

19 of 19

Are you on board?

Thank you. Any question?

Didier Roche

didier.roche@canonical.com

didrocks@ubuntu.com