[TechSpeak] Azure Pipelines: Using It for Xamarin Apps and Configuring a Local Agent

Creating a Xamarin app implies the development of a common logic for several platforms, which is quite convenient, but may cause some troubles as well.

In this article, I will tell you how you can easily configure a part of continuous integration and continuous delivery (CI/CD) while engaged in cross-platform development with the help of Azure Pipelines. You will also learn how to build projects on your local machines instead of Microsoft-hosted agents.

Why Build a Xamarin App with Azure Pipelines?

Xamarin is a framework for cross-platform mobile app development that targets Android, iOS and Windows using C#, .NET and Visual Studio. Xamarin allows a large portion of code to be shared between platforms, with only a small percentage that needs to be platform-specific.

Imagine this situation: you’ve implemented some changes for the iOS part, but they have disrupted something in the Android part, and you can’t even launch it. Of course, separate compilation and testing of several solutions are possible, but it would be time-consuming.

So, the best way out is to use Azure Pipelines — a cloud service that allows you to automatically build and test several jobs in parallel and make them available to other users. This option is quick, easy and safe.

In simple words, I push changes to the branch and then observe in Azure how the builds are compiling. If I see that the build for iOS is done, and the build for Android failed (a red icon), I understand that there is an issue and can immediately fix it.

Instruction for Azure Pipelines Configuration

To use Azure Pipelines, you need to have:

• A Microsoft account
• An organization in Azure DevOps
• Your source code stored in a version control system

For the first step, sign in to your Azure DevOps organization and navigate to your project. From the left menu select Pipelines, then click New button and select New build pipeline.

Select the Version control system and the necessary repository.

On the Configure step, you can select Starter pipeline (to start with a minimal pipeline) or Xamarin.Android\Xamarin.iOS (to start with minimal logic of building a Xamarin Android\iOS project). Let’s choose Xamarin.Android. It generates the following YAML file:

#Xamarin.Android
#Build a Xamarin.Android project.
#Add steps that test, sign, and distribute an app, save build artifacts, and more:
#https://docs.microsoft.com/azure/devops/pipelines/languages/xamarin

trigger:
master

pool:
vmImage: 'macos-latest'

variables:
buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'

steps:
- task: NuGetToolInstaller@0

- task: NuGetCommand@2
inputs:
restoreSolution: '**/*.sln'

- task: XamarinAndroid@1
inputs:
projectFile: '**/*droid*.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'

Let’s briefly take a look at it and fix some lines:

• Trigger (as the name suggests) works on a push to specific branches. In the code above, the build will start only when we push something to the master branch.
• Pool is an agent pool on which build will run; by default, it uses Azure Agents Pool. (Later in the article I will describe how to configure your own pool on your local machine).
• Next, we can pass some variables. For example, build configuration and output directory.
• In the section steps, we start working with our project. We install NuGet (NuGetToolInstaller@0), install and update packages (NuGetCommand@2) and Build Xamarin Android project (XamarinAndroid@1).

After some changes the file looks like this:

#https://docs.microsoft.com/azure/devops/pipelines/languages/xamarin

pool:
vmImage: 'macos-latest'
variables:
 buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:
- task: NuGetToolInstaller@0
- task: NuGetCommand@2
 inputs:
restoreSolution: '**/HelloWorld.Droid.sln'
- task: XamarinAndroid@1
 inputs:
projectFile: '**/HelloWorld.Droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'

Click Save and Run. The build pipeline is created and automatically starts building.

You can find more information about the Android part here.

Now we need to create an iOS build. There are two possible approaches:

• Create a separate build pipeline
• Add another job inside the current pipeline

The difference is that if we have two separate builds, we can run them in parallel. But for the first variant, we need another agent. Just repeat steps described above, but choose Xamarin.iOS on the Configure step.

For the second variant (another job in one pipeline file), edit our Azure Pipeline file according to the screenshot below:

jobs:
- job: Android
 pool:
vmImage: 'vs2017-win2016'
 variables:
buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
steps:
- task: NuGetToolInstaller@0
- task: NuGetCommand@2
inputs:
restoreSolution: '**/HelloWorld.Droid.sln'
- task: XamarinAndroid@1
inputs:
projectFile: '**/HelloWorld.Droid.csproj'
outputDirectory: '$(outputDirectory)'
configuration: '$(buildConfiguration)'

- job: iOS
 pool:
 vmImage: 'macos-latest'
 variables:
 buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller@0
inputs:
versionSpec: '4.3.0'
- task: NuGetCommand@2
inputs:
restoreSolution: '**/HelloWorld.iOS.sln'
- task: XamariniOS@2
inputs:
solutionFile: '**/HelloWorld.iOS.csproj'
configuration: '$(buildConfiguration)'
buildForSimulator: true
packageApp: false

You can find more information about the iOS part here.

Click Save and go to Pipelines – Builds. It’s automatically started. Now we can see the building process of our solution. It’s separate for two jobs (Android and iOS). If the job has a red status, it means that something has gone wrong. You can click on the failed job and expand the failed step to see full information about it. In my example, everything goes well and I can see the Succeed status.

Steps to Configure the Local Agent on a Mac

If you want to run builds on your local machine or run two builds in parallel or save the results of your program (.ipa and .apk files for example), the best solution for you is to create your own self-hosted agent. Below, I described steps you should take to configure it yourself on your local machine.

STEP 1

First of all, you need to generate a PAT (Personal Access Token). For this, go to Azure DevOps and click on your profile (in the upper right corner of the screen), then click on Security:

Create a personal access token by clicking the New Token button. Enter the name, select expiration, for the scope select Agent Pools (read, manage) and make sure all the other boxes are cleared. Click Create and copy the token. You’ll use this token when you configure the agent.

STEP 2

Now we should create the Agent Pool. For this, click project settings (in the lower left corner of the screen), select Agent pools and click the Add pool button.

In the window that appears, enter a name and click Create. The Agent Pool is created. Now we should download and configure the agent on the machine.

STEP 3

To download the agent, select the pool you’ve just created from the list, then click New Agent. In the modal window select your OS (on which the agent will be located) and click Download the agent. It starts downloading.

Unpack the agent into the directory of your choice. Then run config.cmd.

• When setup asks for your server URL, for Azure DevOps Services, answer https://dev.azure.com/{your-organization}.
• When setup asks for your authentication type, click Enter (it will choose PAT). Then paste the PAT token you created into the command prompt window.
• And finally, choose run the agent as a service.

After you finish configuring the agent, the console is closed automatically. To run the agent, open run.cmd. 

To check your agent status, do the following:

• Go to your Azure DevOps portal
• Then go to project settings
• Select agent pools list
• Select your pool
• Finally, go to Agents tab

Our agent should be shown there and the status should be online.

Build should run automatically on your local machine when you push something to your repository.

That’s all. Hope, this information is useful for your work.