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.
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”.
On “Target” -> “Build Settings” -> “Signing” -> “Provisinong Profile” -> “Release” we have to choose our Provisioning Profile Ad-Hoc (generate previously on developer.apple.com).
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.
We create a “New app” on the main page of 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
We have to wait until Bitrise check the repository. I will take a few minutes.
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.
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.
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.
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.
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