Distributing apps

For test, production and everything in between

When you’re developing iOS and android apps, your primary focus is on getting your apps out to end users. But when you’re making apps commercially, there are many stages they have to go through before they get anywhere near public release, and each stage requires our apps to be distributed in different ways. In this presentation, I’ll explain how we manage this at Intercept IP.

00:34

First of all, lets look at our requirements for app distribution.

00:37

We need to distribute our apps for various different purposes.

00:41

• Feature testing — are our code changes fit for purpose?
• Regression and integration testing — did we break anything, and does the app still talk to the other parts of the system it should?
• Product owner review — is our product team happy with our customers seeing this version of the app?
• User acceptance testing — is the user happy?
• Customer trials — we might want to make pre-release versions of the app available to customers
• Public release — releasing the app on the app stores

01:11

As part of our distribution strategy, there are some important features that we want to include.

01:17

• Versioning — we need to version our app so we know exactly which features are in which build
• Multiple environments — you might have a test environment, a user acceptance test environment, and a production environment, and our apps need to be available for people to use in each of those
• Access control — we want to make sure that the right people get access to the app after it has been through the right amount of quality control
• Process — we need a process to pull this all together, and get the right version, in the right environment available to the right people at the right time.

01:53

Let’s look at the first of these, app versioning

01:57

When a developer finishes a small chunk of work, they merge it to our main branch in source control. This starts an automated process, which first runs automated tests to make sure everything is ok. If it is, it will version the code. Versioning effectively stamps that cut of the code with a version number.

02:23

This version is set in the android or iOS project file, in source control as a tag on the commit and in our ticketing system as a fix version, so we can tie everything together.

02:38

That’s versioning

02:39

Next let’s look at multiple environments

02:43

For a given app that we want to distribute, we make multiple flavours. Each of these flavours is an app in its own right, and they can all be installed on a device at the same time. They are build from the same code at the same version, but they are packaged with different configuration, which lets us create these different apps, with different icons, and pointing at different environments.

03:11

We make these flavours using continuous deployment. When a new version of the code arrives, on the build we’ve got various different configuration files for our different app flavours, such test, UAT and production. The build server selects the combination of version and configuration that it needs, then it packages and deploys it to where it needs to go. And the same for each of the other flavours.

03:42

So that’s how we handle multiple environments.

03:46

Next let’s look at how handle access control.

03:48

First of all I’m going to talk about the different platforms we use. For public release on iOS we use the Apple App Store and for Android we use Google Play Store. For private and test versions we use TestFlight, which is built into the App Store, and we use the test features built into the Google Play Store.

04:11

TestFlight and the Play Store allow us to set up different test groups, or channels, to control access to different versions of the apps. First of all we’ve got the internal testing group. These are a small number of people, internal to our organisation, who need immediate access to new versions of our apps. We use this channel for feature testing, regression testing and integration testing.

Next we have private channels. We configure these according to our needs, but typically we might have a review channel. This is for a small number of people, internal to our organisation, who need early access to our apps, but after they’ve been through some level of quality control. Then we’ve got trial users. This is a wider group of people, who might be internal or external to our organisation. These people need access to pre-release versions of our app, but after it’s been through considerable amounts of quality control. We use these for product owner reviews, users acceptance testing and customer trials.

Finally we’ve got the public App Stores, where our app goes out to the wider world on public release.

05:36

Let’s look at how we get our versions into each of these channels. For internal testers, a new version will arrive automatically when a build is deployed. For the private channels, we manually make a version available when it has been through the right amount of quality control. For the App Store, the process is a little bit more involved. We create screen shots and update content for the App Store, and then submit the app for review. Once it has passed review, we can make it available to the wider world.

06:14

Each of these channels can, and will, have a different version in it at any given time.

06:21

That’s how we control access.

06:24

Finally let’s look at the process.

06:34

On the left hand side we’ve got our test groups, and across the top we’ve got our different app flavours.

When a feature is completed, we make a version and package and deploy it to the test flavour of the app, and here the internal testers will pick it up. They will test new features and bug fixes in this version. At some point we’ll package some features and decide that we want to make a release out of it, and then the testers will do a full regression test on that version.

When they are happy and all of the tests have passed, we’ll make it available in the UAT flavour. They’ll do some smoke tests, again in this internal test channel. When they’re happy, the review team will get access to the app. They’ll review the app and make sure they are happy with the features that are in it, and that they’re happy with the client seeing this version of the app.

If they are, we’ll make it available to our internal trial. We’ll run the app in internal trial for some amount of time, and we’ll monitor it to make sure that the app is working as expected.

And if it does, we’ll pick it up in our production flavour of the app. Again, we’ll do a smoke test here, and once that’s ok we’ll put it out to our customer trial. Here our customers can see the pre-release version of the app, and make sure that that are happy with their end users seeing it. And if they are, we’ll make it available on the app store.

08:08

We use this process across all of our apps at Intercept IP, but we customise it heavily depending on how complex the app is. This exact process is the one that we follow for our driving analytics product, IC6. That’s a complex product, it integrates with hardware components and back-end systems, and requires a lot of review and testing.

At the other end of the scale we might have a very simple app with only one environment. There the path through from internal test to UAT and on to the App Store is very simple. This is the process that we use for our Read the Signs app, which show road sign information on the Isle of Man.

08:56

So that explains the process, and ties up how we distribute apps for test, production and everything in between.

09:08

If you’d like to say ‘hi’ or ask me any questions, I’m @GabEarnsh on twitter.