How we publish the Klarna Point of Sale app, Part 5/5

Distributing it to Apple App Store and Google Play.

The store manager by the window knows that their feature requests are rolled out with ease.

TL;DR

• It’s smart to pause the pipeline to allow a product manager to confirm each release.
• App Center doesn’t completely automate the process. You still need to “promote” the release in App Store and Google Play.

Two-step Process To Distribute App

To release your app to Apple App Store and Google Play you need to two two things: Create a release and distribute the release.

More on that in a sec, but first a quick sidetrack…

Quick sidetrack: Release notes and Go/No-Go

When the pipeline is triggered on every commit to the master branch it is usually important to not automatically distribute the resulting build to Google Play and App Store. You probably don’t want to bother your users with updates to the app more than, say, once per week (and you probably merge feature branches to master more often than that).

You want to explicitly decide if a certain build should be released or not. Luckily, Jenkins has a very nice feature for this: input steps which pauses the pipeline until a human makes a decision.

The above snippet will pause the pipeline/job for 24 hours and:

• allow someone to write some release notes which will be sent to the app stores along with the app,
• allow someone to click Yes to confirm that this build should indeed be released to app stores.

This accomplishes two important things:

1. The build pipeline is paused until someone explicitly clicks the button “Yes, release to production”. This ensures that you never “accidentally” release something to production.
2. You get a nice way of supplying release notes. The above code example would store the input, i.e. the release notes, in a variable called releaseNotes.

This means that the build is paused at this point until someone looks at the build’s console in Jenkins and clicks the “Yes, release to production” button.

The release notes will show up under the What’s New section in Apple’s App Store, so phrasing the release notes in a positive way is a good idea since people interested in downloading your app will see them.

Note: The pipeline/job will be aborted if no one clicks Yes within 24 hours.

Note:

After confirming that we want the app to be release we move on to actually distributing the app to Apple App Store and Google Play.

Now back to the main topic of this post…

Two-step process to release through App Center

App Center distributes your app in two steps:

Clicking on the Distribute button for a build is manual work. Let’s automate it!

1. Invoke the Distribute action on a Build. This initiates the creation of a “release”.
2. Once the “release” has been created you can “distribute” it to different “destinations”, like app stores or groups of users. Setting up destination Stores and Groups are one-time tasks and automating it might not be worth the effort (which is why it’s not covered in this blog post).

This is where you access and create your releases, and destinations like user groups and app stores.

First step: Start distributing a build

Ok. Let’s automate step 1: Triggering the Distribute action in your Jenkinsfile. It’s pretty much a single curl call:

Note that BUILDID would get its value from earlier steps in your CI/CD pipeline. You would get it from the result of the POST to
​/v0.1​/apps​/{owner_name}​/{app_name}​/branches​/{branch}​/builds you did to compile the app.

The DISTRIBUTIONID requires a bit of explanation: It is an UUID identifying the “user group” or the app store to which you want to distribute the app (see earlier screenshot).

You need to GET /v0.1​/apps​/{owner_name}​/{app_name}​/distribution_stores and then find the UUID for the distribution (group or app store) you are interested in. You can make that call once with curl, find the UUID and hardcode it as your DISTRIBUTIONID value.

Or you can automate it… This Groovy script uses curl and jq to look for a distribution called “Production” and return its UUID:

Find the distribution id by querying the distribution_stores endpoint.

After you’ve triggered the distribution you need to wait for the release to first be created and then to be completed.

Second step: Promote the release

App Center will push your final app to both App Store and Google Play but you still need to manually log in to the stores to “submit the new version for review” (App Store) or “promote to production” (Google Play).

These additional steps in the admin interfaces for the two app stores bring up an interesting point about deployment automation of native apps: You cannot automate it fully. Kind of. Your options are very limited with Apple and it is hard to automate full process. You have more options when it comes to Google and if you really want to automate the whole process, including automatically releasing your app to all your users, you should take a look at Google’s Tracks documentation.

That being said, automating everything is probably not a good idea since you will probably want some kind of go/no-go step at the end anyway. Just to be sure you’ve dotted all the i’s and crossed all the t’s.

After the app stores processes are complete you finally have the latest version of your app released to your users. It was a long process but now it’s done.

The next steps

Time to start working on the next release :-)

Previous posts:
Blog post 1/5: Why automate?
Blog post 2/5: How does Jenkins orchestrate the process?
Blog post 3/5: How is App Center configured?
Blog post 4/5: How to run tests in Browserstack?