Continuous Integration and Deployment of an iOS app with Bitrise
We are using Bitrise in our mobile projects at The Agile Monkeys to automate basic processes like validating that a Pull Request builds properly and the tests are passing (Continuous Integration) and to upload the .ipa to the App Store Connect so it can be be reviewed by Apple or by our testers through TestFlight (Continuous Deployment).
Continuous Integration & Deployment
If you haven’t added an app to Bitrise yet, do it first. Remember to check the shared scheme toggle in your target scheme and push the change to your repo before adding the app to Bitrise:
Connect your Apple Developer account with Bitrise:
If you added your app to Bitrise with App Store configuration (you are asked about this when adding an app), you will have a default workflow like this one:
Remove the script step if you don’t need it and rename the primary workflow to a more descriptive name, like Production.
Add steps to auto-increment the build number of your targets (2 in my case) and to deploy to iTunes Connect. I’ve also added a testing step:
Configure the Deploy to iTunes Connect step with your data:
Be sure you activate the app-store configuration in the Xcode Archive & Export for iOS step:
I wasn’t able to make the code-signing step work in Bitrise when the Automatically manage signing toggle in the Xcode target settings was enabled. Uncheck it, create all your needed provisioning certificates manually (it’s not the scope of this article) and configure your target with them. Remember to push your Xcode changes.
Go to the Code Signing tab in Bitrise (next to the Workflow one). Paste the script displayed there into your terminal and follow the instructions. Accept Bitrise to upload your certificates at the last step:
Next, create another Bitrise workflow for development. We don’t need the build number or archiving phases here:
In Github, create branch protection rules for your development and master branches. This is the configuration I’m using:
As you can see, PRs can only be merged if they are up to date, approved by at least one team member, and Bitrise checks pass.
In the workflows editor, go to the triggers tab and add a Push trigger to the master branch pointing to the Production workflow:
This way, whenever a PR is merged into the master branch, the Production workflow will be triggered, building the app with the app-store configuration and uploading it to the App Store Connect. Remember that you need to increase your target versions and the new app version record must exist too in the portal before merging the PR:
Now add Pull Request triggers to the development and master branches with the development workflow configuration, so when a PR is created in Github, the development workflow will be triggered, blocking the merge if it encounters problems along the way:
And that’s it!
I must say that this is the first time I use Bitrise for CI/CD, and I’m pretty satisfied with the result. Feel free to leave a comment if any part is misleading or you think that more details are needed.
Thanks for reading!
Originally published at https://dev.to on June 5, 2020.
