App Masters

App Masters

  • English
  • Português

›Tools

App Masters - Core

  • Home
  • Content

Backend

  • Node Express
  • Node Worker Threads

Database

  • GraphQL

Javascript Fundamentals

  • Asynchronous Javascript
  • Typescript

Design Patterns

  • Presentational Container Design Pattern

Frontend

  • AMP (Accelerated Mobile Pages)
  • Bubblewrap
  • Gatsby.js
  • Next.js
  • PWA
  • Styled Components

Mobile

  • React Native
  • Store Testing

Server

  • Netlify

Testing

  • Cypress
  • Jest

Design

  • Human Interface
  • Material Design

Tools

  • Bitrise
  • Docker

Bitrise

What it is

Bitrise is a really simple CI focused on mobile build and deployment, allowing Android and iOS build and deployments using pre-build actions and drag-and-drop interface.

How to use it

Android typical flow

  • Activate SSH key (RSA private key) - Bitrise will already add this step, it will just setup the SSH key so you can clone the project on the CI and usually you don't have to do anything;
  • Git Clone Repository - This step is also automatically added after the setup, leave as it is;
  • Run yarn command - This step can be used to run any yarn command (bitrise have a npm too) but this one is used to do the install. Set the working directory as mobile if the project is not the root.
  • Install missing Android SDK components - Be sure that the virtual machine have everything necessary to run the build (most of the time this step is skippable, but it's better to keep it), this step NEED to be runned on root, so don't change the folder before this step;
  • Change Working Directory for subsequent Steps - Helper step if the mobile project is not on the root. Change the directory to mobile;
  • Install React Native - Make the react-native-cli available;
  • React Native bundle - Bundles the react native app. Select android as the platform and define the entry file as index.js if necessary;
  • Change Android versionCode and versionName - Tricky step. Use this one to define the version of each build. Usually is nice to use the variable $BITRISE_BUILD_NUMBER to change the version on each build, but you can also add your own logic. If the app is already deployed, you can set the offset to avoid conflicts with the deployed versions. You will need to set the path as $BITRISE_SOURCE_DIR/android/app/build.gradle;
  • Android Build - This will generate the build. Set Module as app and Variant as release and chose the correct build type (apk or aab). Maybe you will also need to chage the Project Location to $BITRISE_SOURCE_DIR/android because this step is not "react native aware";
  • Android Sign - Step to sign the app. You don't need to add any information if you already uploaded the the keystore on the signing tab (with the alias and password);
  • Deploy to Google Play - Upload the app to the Google Play. You will need to setup a few things on this step:
    • Service Account JSON key file path: created by the proprietary account of the Google Play team. You can generate the file like this and upload it on the Code Signing tab under the Generic File Storage, making a new evironment variable available with the url;
    • Package name: Define the desired package name;
    • Track: How the app will be available on the Store. This is a string with production, beta, alpha, internal or pre-release, but some of the values are only available when you previously uploaded a version on this track manually, so be aware of this when you're receiving errors because of the track;
    • App file path: You will not aways need to change this value, but depending of the order of the creation of the steps, you will need to change this path to the signed one. Bitrise will make it available on $BITRISE_SIGNED_APK_PATH;
  • Deploy to Bitrise.io - Apps, Logs, Artifacts (optional) - This will make all generated artifacts available to download directly on the Bitrise interface after the build. Useful for fast tests;

iOS tipical flow

  • Activate SSH key (RSA private key) - Bitrise will already add this step, it will just setup the SSH key so you can clone the project on the CI and usually you don't have to do anything;
  • Git Clone Repository - This step is also automatically added after the setup, leave as it is;
  • Bitrise.io Cache:Pull - Since the iOS build usually takes a long time, is nice to have a cache management on the workflow. This step will pull previous created cache to be used on the next steps;
  • Run yarn command - This step can be used to run any yarn command (bitrise have a npm too) but this one is used to do the install. Set the working directory as mobile if the project is not the root. Enable the cache if you added the cache steps;
  • Run CocoaPods install - This step will do the pods instalation. Usually you don't need to setup anything here, but take a look on the Source Code Directory path;
  • Certificate and profile installer - Before this step you will need to upload the certificates and profiles on the Code Signing tab. The easiest way is to have a build and deployment already working on a local machine and use the codesigndoc to get and upload everything necessary;
  • Set Xcode Project Build Number - This step will update the version of the build. Update the value of Info.plist file path and add a logic to generate the version number. The value of Version number can't contain any strings, it's recommended to use the version as x.x.x format;
  • Xcode Archive & Export for iOS - This step will take a long time but will generate the build. You will need to set these value to get the fastest build possible;
    • Configuration name: Release;
    • Select method for export: app-store;
    • Rebuild from bitcode: no;
    • Include bitcode: no;
    • Disable indexing during the build: yes;
    • Debug > Do a clean Xcode build before the archive?: no;
  • Bitrise.io Cache:Push- This step will push any cache created on previous step. You can change the order of the steps so this one will be the last one, but since is common to have problems with long build times on iOS, it's better to cache everything early so your next build will have more chance to successfully stay bellow the limit time;
  • Deploy to iTunes Connect - Application Loader - This step will upload the generated app to

Extra usefull steps

  • Trigger Bitrise workflow - This step can trigger another (or the same) workflow, defing the name (Workflow ID) and the API token, that can be get on the Code tab of the app;
  • Node Version Manager (NVM) - Bitrise will use the latest stable version of node, so you may need to set a version of node using the NVM, which can also just read the .nvmrc version;

Possible problems

  • React native projets have sub-folders with android and ios. The React Native commands of Bitrise don't have any problems with this, but the pure Android and iOS blocks have some trouble. When the project have the mobile folder, is double trouble, so be aware of this when you're getting missing files errors.
  • Using it for free will make you try to stay bellow the build time, but some versions of React are making it really hard. On the last build we removed the Flipper because is was being built (but not added) on the Release build on iOS, making it slower.
← Material DesignDocker →
  • What it is
  • How to use it
    • Android typical flow
    • iOS tipical flow
    • Extra usefull steps
  • Possible problems
App Masters
App masters
Content
More
BlogGitHub
Copyright © 2022 App Masters