8 min read
It’s no secret that developing, testing, and deploying requires a great deal of effort, time, and attention for teams, especially when manually making all these steps. You have to be careful with each step to avoid possible mistakes.
Here, automation of the whole development process seems to be a perfect way to increase your software product quality and save a lot of time for you and your team. Equally, it relates to the deployment process.
There are multiple means for configuring and proceeding with the complete continuous integration and distribution processes, with Jenkins and CircleCI being the most popular. This time, we’ll watch Bitrise in action.
No doubt, every automation tool performs in its own way. For me, there are several reasons why I pick Bitrise every time:
Yet, it’s highly possible that once you start to use Bitrise, you’ll find reasons to appreciate it.
Developing for iOS is not always easy, so we’ll walk through adding an iOS app to Bitrise, managing code signing files, and deploying an app to Firebase distribution, TestFlight, and the App Store.
Let’s look at the steps to bring your app to the tool.
So, now you have the first app added to Bitrise.
Depending on your app, one or two workflows are automatically initiated when you add a new app on bitrise.io. Those are the primary and the deploy workflows.
You can start builds on Bitrise by:
This part of the process requires our particular attention as there are multiple ways to manage triggering for the builds, such as:
We need to have two workflows for deployment: first for internal testers (QA team), using Firebase distribution service (dev-firebase-cd), and the second for client and AppStore release (prod-appStore-cd). We’ll study both of them.
Let’s start walking through the dev-firebase-cd workflow.
You need to have basic steps, then let’s see how we proceed with configuring for an appropriate deployment. Signing automatically on the projects seems to be a preferable way of managing the code. It’s therefore natural if our deployment workflow contains the “Automatic sign-in” phase.
Remove the “Certificate and profile installer” stage. The certificate and profile installer step is used while providing provision manually. On “Xcode Archive & Export for iOS,” select the “Automatic sign-in” option and choose the Automatic code signing method, where the Bitrise Apple service connection should be used for automatic code signing.
You can choose: api-key or apple-id
Also, in this step, you need to opt for “Distribution method” development.
Add the “Set Xcode Project Build Number” stage to the workflow. This step automatically increases your project’s build number to prevent conflicts.
Here, set the value of your iOS app’s bundle version in the Info.plist file to the selected version number. It’s a great way to keep track of versions when submitting bug reports:
Configuring the phase. Specify the file path to the `Info.plist` file in the `Info.plist` file path input. Add a value in the Build Number box. This puts the CFBundleVersion key to the defined value in the Info.plist file. Hence, we have $BITRISE_BUILD_NUMBER Environment Variable as the default value.
You can add a value in the Version Number input if desired. This will position the CFBundleShortVersionString key to the specified value in the Info.plist file. However, this input is not essential.
You can also offset your app’s build version numbers if you handled version tracking differently before for the same app: all you need to do is set the value added to the build number. The value can be either a fixed integer or an Environment Variable.
Suppose you have an app and run its fifth build on Bitrise soon. You’d like to offset the build number by six as the app had six builds before using Bitrise.
For instance, if you have a project and its Info.plist actual settings are:
…and your workflow contains the Set Xcode project build number step with the next setup:
Given this, your first build on this app ($BITRISE_BUILD_NUMBER == 1) will be added to the Build Number Offset. Hence, the first build versions will be 1.2 (7) and the like.
Set “Extracts Xcode project info” data to environment variables. This step will just extract Xcode project information (Version and Build) and export them into environment variables prefixed with XPI_. You just need to set the relative path from the Source directory to Info.plist file. Source directory is considered the root directory created by the Git Clone step.
Let’s say your Info.plist file is in RootDir/ProjectName directory. Consequently, you should place this input to ProjectName/Info.plist.
We also use the “Stamp AppIcon with version number” stage to efficiently work with app versions throughout the testing. This script will apply ImageMagick to stamp the version number to all icons. Stamps version “version (build number)” sets to the bottom of the icon.
Set “Firebase App Distribution.” This is a great option to upload app binaries to Firebase, attach release notes, and specify testers you’d like to notify. In the workflow editor, add the “Firebase App Distribution” stage. Then follow the instructions below (showing where to get values for the required input variables):
1. Firebase Token. Install the Firebase CLI if you haven’t got it yet.
To Use the CLI with CI systems, login into the Firebase and get a token ($ firebase login: ci).
Once the authentication process is complete, your token is published on the console. (Example token: 1/a1gqPSI3ryNcsDiZnCaHnY-hg9u9nJeosz3iNPe-S- RLdmqdypiJMOjoeOhOGsWK).
Now, open the Workflow Editor Secrets tab and add the given as a new Secret Environment Variable.
2. App Path. Select a path to the file you want to upload.
Note: If you go with default values, keep in mind that $BITRISE_IPA_PATH (iOS) are paths to the latest file.
3. Firebase App ID. Log in to the Firebase console, select your project and navigate to Project Settings ( //auto-install script for Mac OS or Linux users: $ curl -sL https://firebase.tools | bash)
The General tab will contain your App ID.
For now, we’re done with the input variables. There’s only App Distribution to activate for the project on Firebase.
Pick your project and click Get started. This allows us for testers to manage, providing access to distributions. Upon triggering a build and successful upload, you’ll see your app binary on the list.
There is only one job to do before running your workflow: Code Signing. Simply follow the instructions on the “Code Signing” tab in your Workflow Editor to see how fun
and easy it is.
So workflow dev-firebase-cd is already configured, and you can also add more steps like “Send a Slack message” or another step.
Now, let’s see how to set up the “prod-appStore-cd” workflow.
Use a previously configured Bitrise Apple Developer connection: Set the Bitrise Apple Developer Connection to automatic (the default setting), api_key, or apple_id.
Provide manual Step inputs: Add authentication data depending on which authentication method you wish to use, either Apple ID or API key authentication. Set the Bitrise Apple Developer Connection to off. Employ only one of the authentication methods:
Unless you use any dependency tool like CocoaPods or Carthage, the most critical steps in the workflow should look like those above.
Now, you are ready to deploy. Start running a new build by clicking the “Start/Schedule a Build” button from the app detail.
Hopefully, my guide on the deployment of an iOS application was helpful, and from now on, the process will be simpler for you.