Skip to content

App Deployment

Jump to bottom
Mikunj Varsani edited this page Feb 23, 2018 · 17 revisions

This page of the Wiki describes how deployment works and the steps required to deploy the app.

How deployment works

The way deployment is set up is very simple.

Changes in Develop branch.

All changes to the app must first occur in the develop branch, by default this is also where all the PRs are merged into. Once a change occurs in develop, Travis is triggered and it will do the following:

  • Update versionCode(android) and buildNumber(iOS) to match the travis build number.
  • Commit those back into the repository.
  • Build alpha versions and submit.

NOTE: Since iOS doesn't really have an alpha track, the build is submitted to TestFlight. This is fine as we can still control who gets the builds in TestFlight unlike with Google Play where anyone who signed up for the alpha will automatically get the update (we can't force users out of alpha/beta phases, where as on iOS we can).

Changes in Release branch.

The release branch is the second step in the deployment process. The only way this branch should change is by merging the develop branch into it. Travis will do the following on this branch:

  • Build beta versions and submit.

NOTE: This branch will NOT update the versionCode and buildNumber automatically so if you directly make some changes on this branch without going through develop then there might be issues with the distribution of the beta builds. Both platforms require the versionCode and buildNumber to be greater than the previous build.

Changes in Master branch

This is the final step in the process. Any changes here WILL be pushed to the store as a Release, so be very careful. The only way this branch should change is by merging the release branch into it. Travis will do the following on this branch:

  • Build final versions and submit.

NOTE: There are a few extra steps that need to be done, which are listed below, to ensure that the app is released properly. Any kind of change (hot fixes, release) should follow those steps.

Things to do before releasing

There is only 1 thing that needs to be changed before we can merge everything into master for release, The app version. The app version is the string that will be displayed when users visit the store. Once everything has been changed/tested, you can decide on what the next version will be (i.e 1.0 -> 1.1 or 1.0 -> 1.0.1).

After changing the version, you should make a PR into the develop branch and follow the deployment process above to get the changes in.

How to change version on Android

  1. Open android/app/build.gradle.
  2. Replace versionName with the new code. DO NOT touch versionCode.

How to change version on iOS.

There are 2 ways to change version in iOS, pick the one that you prefer.

Way 1: XCode

  1. Go to ios/ and open kitsu_mobile.xcodeproj.
  2. Click kitsu_mobile at the very top of the left file panel.
  3. Click the general tab.
  4. Change the version listed under Version.

Way 2: Direct pList editing

  1. Go to ios/kitsu_mobile.
  2. Open Info.plist.
  3. Find CFBundleShortVersionString.
  4. Replace the string value below it with the version string.
<key>CFBundleShortVersionString</key>
<string>**Version String Here**</string>

After merging into master

Once all the changes have been merged into master the following has to be done:

  • Create a new GitHub release with the tag that is incremented from previous version.
    • In the notes include what iOS and Android version was released as well as the release notes.
  • Go to iTunes Connect and create a new version release, set the meta data and submit for review.
  • Go to Google play console and click on the app.
    • Follow https://support.google.com/googleplay/android-developer/answer/7159011 from Step 3 onwards.
    • Make sure the Prerequisite section is done.
Clone this wiki locally