loading...
Cover image for Continuous Integration and Deployment of an iOS app with Bitrise
The Agile Monkeys

Continuous Integration and Deployment of an iOS app with Bitrise

jfsagasti profile image Juan Sagasti ・3 min read

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:

Shared scheme

Connect your Apple Developer account with Bitrise:

Apple Developer

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:

Workflow

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:

Production Workflow

Configure the Deploy to iTunes Connect step with your data:

iTunes step

Be sure you activate the app-store configuration in the Xcode Archive & Export for iOS step:

App Store
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.

Xcode

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:

Code Signing

Next, create another Bitrise workflow for development. We don't need the build number or archiving phases here:

Development Workflow

In Github, create branch protection rules for your development and master branches. This is the configuration I'm using:

Branch Protection Rules

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:

Push Trigger

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:

App Store Connect

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:

Pull Request Triggers

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!

Discussion

pic
Editor guide
Collapse
jorgemasta profile image
Jorge Masta

Thanks for sharing!

I have seen that you have 2 workflows:

  • production (push to master) where you generate a build
  • development (PR to master/development) with only tests

Have you considered the option of creating a test build in the development workflow? To be able to do QA (in app) of each release/feature

Collapse
jfsagasti profile image
Juan Sagasti Author

That's a great approach! We have used it in the past with other clients as well (with BuddyBuild tho).

We are bootstrapping a very simple app and we found that just doing the QA phase with the TestFlight build fills our current needs. But if this grows a bit more in features and QA resources, for sure :)

Thank you for pointing it out!