If you want to build this pipeline yourself then you’re going to need a number of things.
First of all, if you want to reuse the code, I’ll make available here, you can jump directly to the next paragraph. If not, here are the first prerequisites:
- A Mac
You will also need a number of additional elements:
- An Internet connection
- An Azure DevOps account (free to create)
- A Git repository (either hosted directly on Azure DevOps or on another online source code manager such as GitHub, Bitbucket and GitLab)
If you’re covered there, you’re set to go – let’s get creating the pipeline.
10 Steps to an Azure DevOps Pipeline
1. Defining triggers
Because a pipelines role is to automate actions, it requires triggers. To begin a pipeline, you can use a number of different triggers:
- A change in a Git branch or tag
- A change to one or more specific files
- The creation or modification of a pull request
- Another pipeline
Of course, for any of these triggers you can include additional interconnected triggers, too.
For this example, I will use the modification of a Git branch as the trigger, namely the modification of the “develop” branch. If you follow the Git Flow model, this implies that the pipeline will be triggered only after the merge of a branch where the pull-request (or merge request) has been previously validated.
2. Defining your Pipeline tasks
Within Azure DevOps, there are two ways to define the actions of a pipeline: via the user interface or via a YAML file.
The user interface is very convenient as a simple slide/deposit allows you to compound a pipeline. However, this method is not recommended by Microsoft as it does not allow versioning the evolution of the pipeline or allow you to make templates.
This is not the case with YAML files. Admittedly, YAML is a little rougher to deal with at first touch but it has some significant advantages over the user interface:
- It is possible to version the tasks of the pipeline
- It is possible to have a different state of the same script on several branches (in order to test or to generate different behaviors as required)
- You can create templates that can be used in multiple pipelines while maintaining a similar body
- It is not dependent on a user interface that is likely to evolve over time
- It has more advanced functionality including compiling code, launching unit tests, signing applications, and communicating with third-party environments.
In our case, we want to be able to complete the following steps:
- Launch unit tests
- Compile a version for the App Store signed with our certificates
- Recover output elements (IPA in our case) if you are on the “develop” branch
- Deploy the app on TestFlight if on the testing branch
- Deploy the app to the App Store if you’re on the master branch
3. Selecting your environment
Clearly, when creating an iOS app, we don’t have any choice about our computer: we need a Mac to compile our code. Fortunately, Azure DevOps offers three environments, namely Windows, MacOS, and Linux, and all in several versions. As I write this article, when it comes to MacOS, two different versions of OSX are available: MacOS X Mojave 10.14 and MacOS X Catalina 10.15.
If you do not have specific requirements related to the compiler’s operating system or test machine, my advice is to always select the latest one. To achieve this, you can employ the following code:
4. Signing the app
In order for the application to be published directly on the App Store or on TestFlight to be testable within an organization, it is necessary that the application be signed with a valid profile of that organization. Without this step, it’s impossible to go on, and so it will be necessary to recover a development or production certificate (in my case it’s production) as well as a provisioning profile for this application.
Of course, Azure DevOps has the ability to handle secure files such as the certificate and the provisioning profile. These files allow for the publishing of apps on your behalf on Apple’s App Store so it’s imperative to protect those same files. What’s more, depending on your organization, many peoples might have access to your pipeline.