Ad-Hoc distribution of an iOS app using Bitrise

Bitrise is continues integration system and a continues deployment system.

What is a continues integration system?

The continues integration it is a development practice that allows to check the if the code developed is complete functional.
This mean check if the code compile and also if the test pass.
If the project do not compile correctly or the tests fails the continues integration system notify to the team that there is a problem.
With this approach we can detect problem sooner than if we execute the tests in a manual way. At the same time we are pretty sure that the uploaded code works as it should.

What is a continue deploy system?

A continue deploy system compile the code and also distribute the binary to the pre-production or production environment on an automatic way.
This increase the efficiency because usually the distribution of a new version use to be in a manual way and that needs a lot of time.

Most popoular continues integration/continue deployment systems

  • Bitrise
  • Jenkins
  • TravisCI
  • Bamboo

Introduction to Bitrise

On our case we will use Bitrise as continue distribution system. We will distribute an iOS app as Ad-Hoc having the code uploaded to GitHub (we also can use other Git repositories like Bitbucket or GitLab).

Bitrise works using “Workflows” where you can put several “Steps” one behind the other.

You can, for example, execute first the tests of the app and if the tests works then distribute the app because if the tests does not works we will distribute a not stable app.

Workflow Example

We can see the “Workflow” in visual way but really it is bases on a YML file where we can also modify things or copy “Steps” from one “Workflow” to other.

Ad-Hoc distribution

After this introduction to Bitrse we will se how to distribute an iOS app on Ad-Hoc way.

From this point we assume that the reader have enough knowledge about the different types of Certificates and Provisioning Profiles to distribute Apple apps.

We will create a “Workflow” to distribute the apps in Ad-Hoc way. For that we will use the easiest way that have Bitrise to do that that it is use their own “Steps”. This force us to have the Xcode project ready for Ad-Hoc distribution. Also exist the possibility to distribute the IPA using Fastlane.

In our case we have to desactivate the Automatic Signing on “Target” -> “General”.

Automatically manage signing

On “Target” -> “Build Settings” -> “Signing” -> “Provisinong Profile” -> “Release” we have to choose our Provisioning Profile Ad-Hoc (generate previously on developer.apple.com).

Provisioning Profile

 

With all those changes on our GitHub repository we can start to configure Bitrise. The first thing that we should do it is create a Bitrise account that will give us 14 days for test the platform.
Once connected with our user on “Account” -> “Settings” we have to give access to Github in order to Bitrise can connect with our repository.

Connect Github Account

We create a “New app” on the main page of Bitrise.

Add new app Bitrise

– Choose our repository

– Add on automatic way a new SSH key to access to the repository

– Choose a default branch where Bitrise will make the necessary checks

Add new app steps

We have to wait until Bitrise check the repository. I will take a few minutes.

Valitating Bitrise

Now Bitrise allows us to choose the kind of distribution that we want to use. On our case Ad-Hoc. This will create a default “Workflow” configured for Ad-Hoc distribution.

AdHoc default config

Tap over “Skip the Webhook registration”. This is useful if we want Bitrise reports about the tests on our repository on ever Push in order to show a “Status” on every pull request. Those status can block the merge of a code if Bitrise can not pass the tests or compile the app. We will not use it.

Now we can edit our “Workflow”. By default it is name “primary”, we should rename it. For example we can call it “Deploy-Ad-Hoc”. This will help us if in the future we have several workflows created.

Code Signing

Before we should:
– Generate a Distribution Certificate on the Apple Developer Portal.
– Export the Distribution Certificate from our Keychain.
– Create a Mobile Provisioning Ad-Hoc on the Apple Developer Portal with all the devices registered where we want to install our app.alar nuestra aplicación.

Now we have to fo to the “Code Signing” section on our “Workflow”.
On this section we have to upload our p12 Distribution Certificate and also the Mobile Provisioning Ad-Hoc.

Code signing

Inside of our “Workflow” we have a “Step” called “Deploy bitrise”. This step is the one who distribute the app.
On the section “Notify emails” we can add all the emails of the people who have the devices added on our Mobile Provisioning Ad-Hoc in order to allow them to receive the IPA to install on their devices.

Now we have everything ready and we can start to execute our “Workflow”.
To execute it we have two ways to do it:
– Automatically
– Manually

Automatically requieres a trigger that execute it. Bitrise can execute a “Workflow” when:
– A new commit is pushed to our repository
– A new pull request it is created
– A new tag is created

All cases can be parametrized and only executed on a certain branch or when the new tag start with “release*” for example.

Bitrise Triggers

Depending for what we want to distribute the Ad-Hoc we should execute our “Workflow” in a one momment or other. Ever we can have severa Workflows in order to distribute the binary to QA on one “Workflow” and in other to the Sales Team.

Manually. On our “App” we have a button “Start/Schedule a Build” where we can execute the a certain “Workflow” choosing also the branch that we want to use. If we tap over “Advanced” also we can specify the hash of the commit or ever we have a CURL command to execute the “Workflow” directly from a command line. If we use the CURL command we can also create a CRON job that execute the “Workflow” periodically.

Start Build

With this now we can start to distribute in a fully automatic way our IPAs inside our team on an easy and fast way.

 

Related Articles

Fast and natural Continuous Integration with GitLab CI

Related Video (Spanish)

Leave a Comment

¿Necesitas una estimación?

Calcula ahora

Privacy Preference Center

Own cookies

__unam, gdpr 1P_JAR, DV, NID, _icl_current_language

Analytics Cookies

This cookies help us to understand how users interact with our site

_ga, _gat_UA-42883984-1, _gid, _hjIncludedInSample,

Subscription Cookies

These cookies are used to execute functions of the Web, such as not displaying the advertising banner and / or remembering the user's settings within the session.

tl_3832_3832_2 tl_5886_5886_12 tve_leads_unique

Other