June 8, 2011

Write Once, Run Everywhere: Flash's Mission Accomplished

Events
MERGE User Conference

Everyone loves their smart phones and tablets – but how smart would they be without Adobe Flash? What began as FutureSplash, a drawing application for a pen-based computer, has evolved over the last 12 years to comprise the Flash Runtime. Beloved by YouTube users everywhere, the runtime includes Flash Player, Adobe Integrated Runtime (AIR) and Flash Lite (Mobile) – and brings the joy of cute kitten videos to hundreds of millions of desktops and devices.

“Everyone wants their smart phone to be number two behind iPhone or Android. To do that, they need the Flash Runtime, so they come to us,” said Jethro Villegas, senior engineering manager at Adobe Systems, presenting his platform proliferation story at the 2011 Perforce User Conference.

Adobe Flash's Build Status GUI
Adobe Flash's Build Status GUI

As often happens, success comes at a price. By 2008, the disparate product code lines were getting harder and harder to manage. “We were spending an enormous amount of effort porting features and fixes from one product to the other. Our ship schedules were totally unpredictable.” The fix? Consolidate the codebases into one common trunk called FlashRuntime/Main, and bring the mobile binaries up to the level of the latest desktop release.

“Our mission was ‘Flash Player 10 on all devices,’” said Villegas. With Perforce at the hub, that mission has been accomplished: Today, Adobe developers produce hundreds of different binaries, all compiling as straight C++, from a single code base separated into platform and core components.

In addition to making key decisions about branching structure, Adobe had to address the growing diversity of deployment configurations at the developer check-in level without requiring the developer to have every build environment or tool chain at her fingertips.

Using Perforce, Adobe enforces a rigorous check-in process that tests code to be integrated into the mainline trunk against hundreds of different devices and passes a rigorous code review.

“Here’s a quick view into one of many closets where we keep the various devices needed to fire up for testing. There are various phones, tablets with different operating systems, etc. One of the challenges we still face is scalability: Every time someone fires up a build, between 20 and 70 machines will start up. The closet can’t be closed any more or thermal failure will ensue,” said Villegas.


The Test Closet: Is it me or is it getting warm in there?

While having humans test many of the video aspects such as the fidelity of PNG or gradient rendering is impossible, other parts of the process can’t be automated.

A build status interface gives a visual of success or failure on flavors of Mac, Windows, Linux, Android, iPhone, Ape and DH with a daunting number of green or red squares. “Do you mean your developers can’t integrate into the mainline until all the required platforms are green?” asked an audience member.

“We decided there has to be a human doing the integration,” replied Villegas. “Even in some cases, when a platform is red, we can explain it away. This part of the process is not so high tech; it does require a human engineer to make the judgment call. In addition to the continuous build system, the mainline has a lot of people’s eyes on it.”

Another ongoing challenge is code throughput: “There are high odds that you make something that works everywhere but fails on Android. Before, as a Mac and Windows shop, we could get so much code through just testing on our own desktop machines. Now the challenge is, since we’re 24-hour shop across the planet, how to get more through without sacrificing build availability.”

The increasing complexity of the hardware/software matrix Adobe is testing against shows no signs of slowing. With a new gadget announced every week, it may be time for Adobe to consider … air-conditioned closets.