App Deployment

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.

Note: When you push changes into develop or master, Travis will automatically set the versionCode or buildNumber to be that of the travis build. This ensures that the build numbers always increase.

---

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 Build alpha versions and submit.

NOTE: Alpha builds are basically builds which get sent out to a closed group of people. If you want to submit to a larger group of people then you need to make a Beta release. Beta releases will have to be submitted manually for both platforms and that can be done in TestFlight or Google Play console.

NOTE2: If a iOS build has the same version string or lower as the one in the store then it will be denied when uploading to iTunes connect. To get past this you have to change the version string to something higher.

---

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 develop branch into it. Travis will 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>

---

Update versioning in source files

We need to update the version in some source files as well. These are not necessary but it's good practice so that the versions match up. These version number is what gets sent in a request under the UserAgent header, so for making debugging api calls easier, this should be updated.

1. Edit version in src/config/env.js
2. Edit version in package.json

After merging into master

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

• 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.
  • Go to Release Management > App Releases.
  • Under the Alpha heading, make sure the build matches the travis build for master branch. If it does then go to Manage Alpha, promote that build to production and follow the prompts.

After update has been released publicly

• Create a new GitHub release with the tag that is the version that was released.
  • If different versions were released on iOS and Android then write that in the notes.
  • In the notes add the list of changes if possible.