1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Adding Mobile Devices to Your Azure DevOps Strategy

DEMO: App Center Azure DevOps Integration

Contents

keyboard_tab
Introduction
1
Course Introduction
PREVIEW5m 14s
Mobile Build Services
2
Distribution Groups
Analytics and Diagnostics
Conclusion

The course is part of this learning path

AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
course-steps
18
certification
1
lab-steps
5
description
1
play-arrow
Start course
Overview
DifficultyIntermediate
Duration1h 6m
Students176
Ratings
3.8/5
starstarstarstar-halfstar-border

Description

This course dives into creating a DevOps strategy for mobile applications using the Visual Studio App Center. The App Center gives us a centralized location where we can implement build services, carry out mobile UI testing with multiple devices sets, create public and private distribution groups, and perform release management for our distribution groups.

Build services include tvOS, iOS, Android, Xamarin, and more. UI testing includes UI testing across many popular flagship devices and uses a tier system to gradually cycle out older devices as newer ones become available. Distribution groups allow for deploying new releases to multiple types of users and can be utilized across multiple applications or projects. This course explains many of the options and services available in the App Center and provides guided demonstrations with a mobile app to show how each of these available services works.

By the end of this course, you should know how to utilize App Center to implement a DevOps strategy for integrating and deploying a mobile application. If you have any feedback relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Create an App Center account and build a new application
  • Perform UI tests in both the App Center CLI and Azure DevOps pipeline
  • Create public and private distribution groups and release apps to them
  • Understand and use the analytics and diagnostics provided by App Center

Intended Audience

This course is intended for DevOps and IT professionals who are looking to implement a DevOps strategy for mobile applications using Visual Studio App Center to build, test, distribute, and deploy their mobile applications. This course is also useful for those preparing to take Microsoft's AZ-400 exam.

Prerequisites

To get the most out of this course, you should know how to build and upload mobile applications if you are not using the build tools provided by the App Center. You should know how to work with Node package manager and have NPM installed or know how to install it. You should also be fairly comfortable with using command-line interface tools.

Resources

You can find the project files for a sample mobile application in the following GitHub repository: https://github.com/kelsosharp/MobileDevOps

 

Transcript

In our previous demo, we used the App Center CLI to upload and run our unit tests from our Xamarin.UITest project. Now, I will show you how to add the App Center Test task to a pipeline in Azure DevOps. This task is the equivalent to the App Center CLI command, and it uses the same REST API that the App Center CLI used. We will use this task to upload our project to the App Center and test it on the device set we called master. But before we can do this, there are a few things that we need to do to enable us to run this task successfully.

Before we head to Azure DevOps, we need to create an API access token for the App Center. This token will grant Azure DevOps access to our App Center organizations and applications. We can do this by clicking on our profile icon in the top-right corner of the page, selecting account settings, and then scrolling down and clicking the API tokens. This will open a page that lists our existing API tokens, if we have any.

Now, we need to click the New API token button in the top-right. This opens a configuration page and here we need to give our token a name and set the access level to full. Once we have done that and clicked the add, this will bring up a dialog box that has our access token displayed, and gives you the opportunity to copy your token to the clipboard. This is the only chance you'll get to copy this token, so make sure to copy it and save it to a safe place.

We can now head to Azure DevOps and open our project settings page. From the list of options now displayed, we click on the service connections menu option. This will display a list of current service connections and a new service connection button will be in the top-right. Clicking this button will give us a list of options to choose from. We wanna scroll down and select Visual Studio App Center. After selecting this option and clicking the next button, we need to paste our new API key here in the API token box and add any details that you'd like to add. The checkbox under the security heading, if checked, gives all pipelines immediate access to this service connection upon creation. If unchecked, you need to authorize each pipeline that uses this service connection individually the next time you build those pipelines. Click save, and you now have a new service connection to the App Center.

Azure DevOps pipelines are the CI/CD or Continuous Integration Continuous Delivery automation process for building our projects. The first thing we're gonna wanna do is to create a variable group and variables to hold our security information for signing our build. We will use encrypted variables to prevent them from being saved as plain text in our code repository.

So we will click on the Pipelines option from our project menu on the left side, and then click Library. The Library is where we can create variable groups, environment variables, and upload secure files, like our Android Keystore. We can also set up access roles for these files and variables and assign users to those roles.

Now we click on the Add Variable Group button. This will bring up a configuration page for creating a new variable group. I'm gonna call this group Android key group, and we're going to add each of the variables we need for signing our build. The variables that we need are the Keystore password, our key alias, and our key password. If your App Center or Azure DevOps organization is linked to an Azure subscription, we would be able to use the Azure Key Vault here to store these values and access them.

Unsigned Android builds are only allowed to run in an emulator. So if you wanna be able to test on a real device, you're required to sign your builds. In order to sign a build for an Android application, you need to create a Keystore file using Android studio. If you'd like to know more about how to sign your Android builds for use outside of an emulator, you can get more information at the following URL.

The first variable we will create is going to hold our Keystore password. We will name the variable keystore.password. And by clicking a lock on the right here, it will encrypt this variable and change the input to a password text box type. Next, we'll create the variable for the key alias and we will name it key.alias. Finally, we will add the variable for the key password itself and name it key.password. Oh, I forgot to save my variable, so when I clicked on the Pipeline's menu option, I got a popup that asked me if I really wanna leave the page. So, I will click no, and I will save my variables now by clicking on the save icon at the top of the page.

The last thing that we would need to do is upload our Keystore file to the secure files area of the library section. We will click on the secure files link here, and this is where you would upload your Keystore file. I've already done that, so I do not need to do it again. And if we click on the file, we see that we can add additional properties and we can authorize its use for all pipelines.

Now that we have our sensitive data configured, we will edit our Azure Pipeline by updating our YAML page. YAML is the configuration markup language Azure DevOps uses to configure tasks for its pipelines. You can find out more about YAML and the schema that Azure DevOps uses at the following URL.

We will need to modify our YAML page so that we can add our App Center Test Task. It requires a bit of setup to be able to run successfully. We'll do that next.

We will click on the pipelines link on the left. That will take us to a list of builds that we've run previously. We can click on any one of these, since we will be creating a new branch for our edited pipeline. Then we will click the edit button in the top-right, which will bring up the YAML configuration page for our default master branch.

Now that we have our YAML page up, we can begin editing it. Because we are adding a variable group to the variable section, we need to be a bit more specific in how we define our other variables. So we need to add the name and value properties to the variable declarations.

These variables are buildConfiguration, which is set to Debug, and outputDirectory, which is set to our bin directory, using the built-in build variable, build.binariesDirectory. Wow, that was a mouthful. Then a slash and our buildConfiguration variable that we just said. This is the standard path Visual Studio uses when compiling projects. By using this built-in build variable, it points our outputDirectory variable to the correct path for the project we're building. That way, we only need to set it once for both projects. We can now add our variable group. YAML is very particular in how the commands are laid out in regards to spacing and how things are defined.

After we've added our variable group, we need to modify the NuGet Command to specify our directory to put our NuGet packages into. One of the challenges of implementing an App Center Test Task is that Xamarin projects no longer use a NuGet.config file, and it no longer copies the NuGet packages into a packages directory in the project by default. So we need to force the command to do that, so we know where to find the cloud-test.exe file that App Center needs in order to upload and run our Xamarin.UITest project.

The hosted build agent, however, does use the Nuget.config file. And we can fix this by adding the restoreDirectory property to the NuGet Command task and pointing it to our main project folder slash packages. We can do this using the built-in build.sourcesDirectory. This variable always points to the current project's main directory.

The next thing we need to do is to create separate build tasks for each of our projects. By default, the main Xamarin.Android task tries to build all projects within our solution, assuming that they are all Android applications. This will not work for our test project. So we need to enter the name of our specific project file for our Android main project. We will keep our output directory and configuration the same, since they are already pointing to the variables we set up. Although not completely necessary, I like to specify the Java Developers Kit version here, since I have multiple versions of this STK on my computer. JDK Version sets this to the most current version.

The next task we want to prepare is signing our build so that we can test our application on real devices. So if we go over here to the right, and at the top, we see that there's an Android signing task. When I click this, it shows the configuration page for this task.

The first thing you need to do is enter the path to the APK file that's created from our previous build task. That value is stored in our outputDirectory variable. So we can just use that here rather than hard-coding a path. Hard-coding a path can be very brittle and can cause the build to break if it changes.

Next, we need to make sure the Sign the APK checkbox is checked, and for the Keystore file, we just need to enter the name of the file we uploaded to the secure files area of the pipeline library. We will likely need to authorize this later when we go to run the build. For the Keystore password, alias, and key password, we just need to enter the variables that we previously added to our variable group in the library. Doing this prevents us from needing to add them here as plain text and storing it in our repository.

There's a few additional properties here, apksigner is used if you wanna use a different signing library for our applications. The Zipalign checkbox is used when we wanna conserve RAM. And the last property is our location for a custom application for Zipalign. We can just use the defaults that are part of the Android SDK and click the Add button to add our task.

Our next task is to build our test project. We need to do this because the binaries need to be uploaded to the App Center for our final App Center Test Task. I'll just scroll down to the Xamarin.Android task and click it to bring up the configuration page. The last time we modified the YAML directly, this time we'll configure a new task and add it to our YAML page. I could just copy the Xamarin.Android task, but I wanted to show you both ways to add a task.

First, we enter our project file name. Next, we have the target property. This is why we need to use a separate task for building this project. When you build an Android application, it expects a target. And since this is not an Android application, we will not have a target, causing our build to fail. So we need to set the prepare package property here to false so that it doesn't look for a value in the target property and cause an error.

Next, we put our outputDirectory variable into our output directory property, and our buildConfiguration variable into our configuration property. Again, we could change our JDK version here and as you can see, there's multiple options we can choose, but we'll just use the default. And now that we've configured our task, we just click add.

Now to the main topic of this demo. The rest was all done to prepare our build process to be able to run our App Center Test Task. We can just click on the task, since it's at the top of the list on the right here. And as usual, we get our task configuration page. First thing we wanna do is specify the path to our APK file that was created when we built our main Android project. We just need to add our outputDirectory variable, and a slash, and our APK file name. What we could have done previously is create a variable to hold the name of the APK file or the full path. That would have saved us some keystrokes.

We wanna make sure that the checkbox for Prepare Tests is checked, because if we miss this, when the App Center tries to run the UI test, there won't be any binary files in the output directory. The Artifacts directory has already been set up for us and points to the App Center staging directory. We have no access or control over this directory on App Center. However, we could set up our own Artifact's directory in either Azure DevOps, or if we were using a self-hosted build agent, we could specify one on the agent machine. I explained build agents in mode depth in my course on implementing and managing Azure build infrastructure here on cloudacademy.com. Be sure to check that out, if you wanna know more about managing your build infrastructure in Azure DevOps.

The next property we need to set is the testing framework we're using. This is Xamarin.UITest. Now, we set the path to our build directory. In our case, we can use our outputDirectory variable. Now, we could have added our Keystore file and signing credentials here, but I like to keep this separate. It makes the task smaller and easier for us to change later on without potentially impacting our testing task. It's just a matter of personal preference, you're free to configure it here without any additional Android signing tasks.

At this point, we come to the part that can make this task in the App Center CLI command challenging to get working properly. This property here is the reason we added the restoreDirectory property to the new command previously. Since Xamarin.Android project's default NuGet package style has migrated to using NuGet as a PackageReference, it no longer copies the packages into a package folder in your solution. This can make it very difficult to find the cloud-test EXE file consistently, as it will be in a different location for each developer on your team and for each version of the package.

We need to enter the path to our tools directory. That will be the built-in build.sourcesDirectory environment variable, /packages/Xamarin.UITest/3.0.3, which is the version of our Xamarin.UITest NuGet package. And then a /tools.

For Xamarin.Android projects, I highly recommend that you add the file to the project as a resource and check it into your code repository so that it's always in the same location for everyone. This just makes it easier to find when testing your project either in App Center CLI or Azure DevOps. Just remember to update your file, if you change the version of the Xamarin.UITest NuGet package.

Next, we select our Visual Studio App Center service connection, and then the App Center Slug property is the App Center's way of identifying which application we're trying to test. It consists of the project owner, in this case our organization, and then a forward slash and our app name in App Center. This might not be the same name as our project. Our devices property value, depending on if we are using a saved device set or a random identifier created by App Center is the identifier. Or if we have an organization, it's our organization name, a forward slash, and then the name of our device set, which is master. Our test series is also named master. The dSYM directory is for iOS, and we're not gonna be using it. Our language is set to English United States, and this will set our locale to en_US.

Now we can click add and have a look at our task in YAML. As we can see, all of our settings have been configured. Although the Prepare tests property is set to true by default, I like to add it here to make sure that it's clear. If it's set to false, then the Test Task will fail because there's not any binary files for the App Center to use to run our tests.

Now we can click save, and Azure DevOps will ask us if we wanna update our existing branch or create a new one. I'm gonna create a new one here and add a commit message. I'm not gonna create a pull request for this change, since I'd be the one that has to approve the change request anyway. Now, we will click run and see what happens. The build process takes about 17 or 18 minutes, so I'm gonna speed this up until we get to the end of the App Center Test Task. We can see from the build log, it ran successfully. And we can now go into the App Center and have a look at the test results. We can see that all the tests ran successfully and we have our report in App Center.

In this demo, we integrated Azure DevOps with our App Center testing by adding an App Center Test Task to an Azure DevOps pipeline. This runs our project unit tests against the device set we created in the App Center. Having the ability to use Azure DevOps to run our App Center UI tests certainly makes it much easier to implement a mobile DevOps strategy. It is just a matter of adding a few additional tasks to our CI/CD pipeline, and we have a completely automated build process for our mobile applications.

In our next module, we will talk about distribution groups and how to get your mobile application to your testers and your users. I hope to see you there.

About the Author
Students606
Courses2

As well being the owner and CTO of Sharp Solutions Group, a software development and IT staffing company based in the Philippines, Kelso is a Microsoft Certified professional and an avid knowledge seeker. His belief is that you need to learn something new each day to stay on top of the constantly changing IT world. He is an avid gamer (both video games and board games) and lives in the Philippines with his wife and soon-to-be-delivered son.