Android Continuous Deployment of Xamarin Apps

This Article will explain how to set up Android Continuous Deployment using Xamarin. It describes the automated build process and deployment of a Xamarin application. Also it is explained how to create a package for deployment to the Android Platform.

The general concept is described in the previous article Continuous Deployment of Xamarin Projects.

Step 1 – Set up the ContinuouS Integration build

Creating a new Xamarin.Android build definition In Visual Studio Team Services (VSTS):

Continuous Deployment of Xamarin Applications for Android

It is the choice of the developers which source control system to use in VSTS (Git, SVN, TFS):

Continuous Deployment of Xamarin Applications for Android

4) Important (It is strongly recommended to turn on Continuous Integration here because should you need it later it takes quite some tinkering to enable it)

5) If you’re building with a hosted agent (agent queue = Hosted), you will be using your allotted build minutes. If you want to avoid this, you can run the build agent on your own machine/VM, put it in the ‘Default’ queue (or another custom-named queue) and target that here.

After this step the build definition is created, but not yet saved to your project. Now’s the time to review the settings created by the wizard:

Continuous Deployment of Xamarin Applications for Android

1) These tasks must be left in place or you won’t get your Xamarin solution to build because the Xamarin tools on the machine you’re targeting (especially in the Hosted queue) won’t have licenses applied to them. If you’re using your own box, however, you could of course have a license already applied on that machine and could possibly get rid of these tasks. Keep in mind, though, that you only have a limited number of active build machines for your Xamarin account. What I tend to do with these is tighten them as much as I can around the other tasks in the project that I might add/ move around. You’ll notice how the deactivate happens *before* the publishing of the artifacts. That’s a good example.

2) These lines are, the username and password for your Xamarin account. They are present in both the Activate and Deactivate tasks. Later I’ll show you how to protect these from prying eyes if you share your VSTS privileges with other people.

3) This step can be removed if you’re not using Xamarin Test Cloud for your testing purposes.

4) Notice this build methodology. It’s building each .csproj file – not the whole Solution as we’re used to in the MSBuild process. For this reason, I recommend you put any Android-specific projects in the same sub-folder (eg: “Android”). This would be things like your Android app & any “bridging” libraries. The other chunk of projects you’ll want to make sure you can target in this manner are any “common” or “portable” ones. A good idea for these is a “Portable” sub-folder in the repository. The important thing to remember is that you don’t need the Xamarin license activated while you build Portable Class Libraries. This enables you to tighten that Activate/Deactivate loop in the build definition later.

To protect your Xamarin account password:

Continuous Deployment of Xamarin Applications for Android

Head over to the ‘Variables’ tab on the build definition, click ‘Add variable’ then type ‘xamarinpwd’ in for the variable name, and put your password in to the ‘Value’ field.:
Continuous Deployment of Xamarin Applications for Android

Clicking the little ‘lock’ icon (alt tag “Secret”) makes this variable value hidden, and irretrievable once the build definition is saved. This means even after you’re done, if another admin, or even YOU, comes back in to the build definition and tries to make that variable non-secret by clicking the icon again, it does not show the value. Rather, it clears it out. Now, we use this variable as our password by simply doing:
Continuous Deployment of Xamarin Applications for Android

Head back to the ‘Build’ tab, go to the Xamarin Activate and Deactivate tasks, and put $(xamarinpwd) in the Password field.

Let’s assume we have a repository set up like so:


Now we can see from this that we can build the Portable projects before everything else, of course – that’s the point of portable projects. The caveat here is we don’t want to build the iOS or Windows projects during the Android CI. So let’s tweak up our build definition for this situation. First, add a new build for our Portable projects:

Continuous Deployment of Xamarin Applications for Android Continuous Deployment of Xamarin Applications for Android

Move the Portable build to be the first step in the definition, outside the Xamarin license activation. We set up this VS Build as shown. Telling it to build all csproj files under the Portable folder. Build it for the ‘Android’ platform, and for the Configuration specified on the Variables tab (see above). This allows us to configure each of the portable libraries for Android if necessary (think #if directives).

In line with our (advised) repository structure, we also need to change the target of the Xamarin.Android build:
Continuous Deployment of Xamarin Applications for Android

For unit tests, you can leave the MSTest task in place, otherwise feel free to remove it.
Now the build definition’s should look something like this:
Continuous Deployment of Xamarin Applications for Android

Nuget Packages:
It is possible to add the Nuget Package Restore task to the very top:

Continuous Deployment of Xamarin Applications for Android Continuous Deployment of Xamarin Applications for Android

At this point, the Xamarin.Android project will do Continuous Integration builds on Microsoft’s Hosted build controllers!

Step 2 – Set up the Release Management definition

The critical part of our build definition as far as continuous deployment is concerned is the last one

– Publish Build Artifacts:
Continuous Deployment of Xamarin Applications for Android

After the APK package has been signed it puts the resulting APK file into a folder named ‘drop’ on the Server. Once we have got this artifact on the server in a known place, our Deployment task can find it and use it.

Head to the Releases tab and create a new Release:
Continuous Deployment of Xamarin Applications for Android

Unfortunately, there’s no straight up Template to get us started so we start Empty and add in the tasks needed from there.

It is possible to create Deployment –> QA –> Production steps with Release Management, or even gating for approval capabilities.

Add a new Release definition:

Give it a name, then click the ‘Link to Build Definition’ link:
Continuous Deployment of Xamarin Applications for Android

3) Make sure to choose the Build Definition created in the previous steps, then click ‘Link’.

Add Deployment Tasks:
After clicking the ‘Add tasks’ button, choose the HockeyApp task to add if you wish to deploy to the the HockeyApp service
or Any Other Deployment service options.
Continuous Deployment of Xamarin Applications for Android

Note that after you click ‘Add’ you need to click ‘Close’.

HockeyApp account credentials:
Continuous Deployment of Xamarin Applications for Android

1) Manage your HockeyApp service connections by clicking the ‘Manage’ link, then putting in your API Token from your HockeyApp Profile page and giving it a name you want to show up in this drop down. Once you’ve got the connection created in VSTS, come back here and click that ‘Refresh’ button then pick the connection name you specified.
Continuous Deployment of Xamarin Applications for Android

2) Put in the App ID for the App you’re deploying to in HockeyApp
Continuous Deployment of Xamarin Applications for Android

3) For the binary file path, click the ‘…’ button to give you a head start, then finish it off with ‘*.apk’ (because know we’ll want only the APK file sent over to HockeyApp).
Continuous Deployment of Xamarin Applications for Android

After the Release Management definition is wired up, we just need to tell it to happen with every CI.

Continuous Deployment of Xamarin Applications for Android

1) Head to the ‘Triggers’ area of the definition

2) Check the ‘Continuous deployment’ box

3) Choose the build definition created earlier

4) Send it to the ‘Default Environment’ already configured in this Release definition

After saving, CI should now be working after each check-in.

 

CONCLUSION

Once completed with all of our steps we now have a complete functioning Source Code and Version Control with Continuous Integration and Deployment working.

Check in some code to the branch you targeted and you should see output something like:

Continuous Deployment of Xamarin Apps for iOSContinuous Deployment of Xamarin Apps for iOS

With HockeyApp looking like:

10

As mentioned in the optional steps we can customize the deployment process greatly and add or remove steps when deploying our app packages. The choices can include our own internal web server for example or HockeyApp’s deployment service etc.

Since we can add PowerShell scripts to run in our process the customization options are quite numerous.

Thank you for reading, I hope this article was useful and will come in handy for any future Xamarin Developers or Deployment specialists.

Please take a look at the Continuous Deployment guides for the other Platforms as well.

Never miss an update by following us and subscribing to our monthly newsletter!

Summary
Continuous Deployment of Xamarin Applications for Android
Article Name
Continuous Deployment of Xamarin Applications for Android
Description
This Article will explain how to set up the automated build process and deployment of a Xamarin application and create a package for deployment for the Android Platform.
Author
Publisher Name
Atos Consulting HU
Publisher Logo

3 thoughts on “Android Continuous Deployment of Xamarin Apps

  1. Pingback: iOS Continuous Deployment of Xamarin Apps

  2. Pingback: iOS Continuous Deployment of Xamarin Apps

  3. Pingback: Windows Continuous Deployment of Xamarin Apps

Leave a Reply

Your email address will not be published. Required fields are marked *