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):
It is the choice of the developers which source control system to use in VSTS (Git, SVN, TFS):
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:
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:
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.:
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:
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:
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:
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:
It is possible to add the Nuget Package Restore task to the very top:
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:
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:
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:
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.
Note that after you click ‘Add’ you need to click ‘Close’.
HockeyApp account credentials:
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.
2) Put in the App ID for the App you’re deploying to in HockeyApp
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).
After the Release Management definition is wired up, we just need to tell it to happen with every CI.
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.
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:
With HockeyApp looking like:
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.
- Universal Windows Platform
- iOS Platform (will be published shortly)
Never miss an update by following us and subscribing to our monthly newsletter!