Wikimedia Apps/Team/iOS/CI/Deployment

Deploying a build

Deploying Builds is done using git to communicate with the Jenkins Build server. Jenkins is watching for changes in specific branches. Making changes to these branch will kick off a build process.

Beta Builds

To deploy a new beta build:

1. Checkout the develop branch from https://github.com/wikimedia/wikipedia-ios/ and pull in the latest changes
2. Checkout the release-beta branch
3. Merge develop into release-beta
4. Push release-beta

This will start the build within 5 minutes. When the build starts, Jenkins will post a notification in the #wikimedia-ios-notifications channel. Before deployment, Jenkins will run tests on the platforms/OSs specified in the fastfile. Note that beta builds have special configuration to expose development menus and use beta API Keys. These should never be submitted to the App Store.

When the build is complete:

1. Jenkins will merge release-beta into the beta branch and push the changes
2. Jenkins will create and push a new tag for the release in the format: betas/5.x.x.build_number
3. Jenkins will push the build to iTunes Connect / Testflgiht. The build will be available to internal beta testers as soon as it is processed

Release Builds

To deploy a new release build:

1. Checkout the beta branch from https://github.com/wikimedia/wikipedia-ios/ and pull in the latest changes
2. Checkout the release branch
3. Merge master into release (this ensures no conflicts when the build server merges the release branch into master)
4. Merge beta into release
5. Push release
6. Native json master

This will start the build within 5 minutes. When the build starts, Jenkins will post a notification in the #wikimedia-ios-notifications channel. Note that this build is configured for App Store deployment - it has all production keys and no developer tools are enabled.

When the build is complete:

1. Jenkins will merge release into the master branch and push the changes
2. Jenkins will create and push a new tag for the release in the format: releases/5.x.x.build_number
3. Jenkins will push the build to iTunes Connect / Testflgiht. The build will be available to internal beta testers as soon as it is processed.

Providing external testers access to a beta

Access to builds for external testers is a manual process. To make a build available, log into iTunes Connect. The iTunes connect UI changes frequently, so you should refer to Apple's documentation for instructions - or just ask an iOS engineer.

Note: the first build of any new version must be reviewed by Apple before it can be sent to external testers. Because of this, it is a good practice to submit a build for beta app review at the first possible opportunity even if you have no intention of deploying it externally. This will ensure there are no delays when you want to send a build to external testers. (If you forget it is ok, the process is quick… usually a day or less)

Submitting to the App Store

Submitting a build to the App Store is a manual process. To submit a build, log into iTunes Connect. The iTunes connect UI changes frequently, so you should refer to Apple's documentation for instructions - or just ask an iOS engineer.

Notes on TestFlight and versioning

TestFlight makes provisioning much easier… no more UDIDs but there are some tradeoffs that directly affect the design of our CI workflow:

1. All build numbers must be numbers… no letters. 885 is a valid build number, 885b is not and will be rejected.
2. Two builds cannot be submitted with the same number, if you already submitted 885, you cannot replace it with a new build 885.
3. Build numbers must increase for every build. You cannot submit build 900 after a build 920. You can also not submit build 900.1 after 902.
4. Only the latest build is available to internal testers, there is no way to make older builds available to internal testers.

Because of these restrictions, the following "rules" apply to our builds:

1. You should not deploy a new beta while a build is in regression testing, otherwise the testers may loose access to the build.
2. Our build numbering scheme denotes a beta by with a "normal" build number: 885, 900, 1020.
3. Our build numbering scheme denotes a release candidate with a decimal build number: 885.1, 900.1, 1020.1.
4. Betas and releases with the same integer part, like 885 and 885.1, are identical except:
   • They have different API Keys
   • The Development menu is one visible in betas
   • Assertions (crashes explicitly made by developers when the app is in an inconsistent state) are only enabled in betas