Even though this was the coolest thing ever I didn't want to go changing all of my pipelines, but it did encourage me stop doing random branches for releases and streamline my tagging and releases when publishing NuGets. This is surprisingly easy to do with the new GitHub Release task. It is a very nice extension that allows you to create a tag, or re-use a tag, add a changelog file, specify release name, add artifacts, and a bunch more.

In my continuous delivery pipeline I have the following workflow:

My strategy here is to ensure that when I go to NuGet (beta) I create a pre-release tag and release and then when I go to full production I simply update that existing release/tag with updated information.

Uploading a Changelog

Traditionally I never uploaded anything to the drop folder except for the NuGet packages, but a nice thing with the the release task is that you can attach a changelog file (or manually enter it). Since I have a changelog file checked in to each of my repositories that I regularly update, I can just add it to the drop folder in my CI pipeline. In the Copy Files task I simply added:

**\bin\$(BuildConfiguration)\**
**\CHANGELOG.md

Adding a Pre-Release Tag & Release

After I release my pre-release package to NuGet, I want to create my very first Tag and Release. First step is to simply add the GitHub Release task:

Now, it is time to fill in the information for the tag and release:

• Select GitHub connection
• Select GitHub repository
• Action: Create
• Target: $(Build.SourceVersion)
• Tag Source: User Specified Tag (if you want to you can have it use an existing tag)
• Tag: v$(Build.BuildNumber)
• Release Title: v$(Build.BuildNumber)
• Release note source: Release notes file
• Release notes file path: $(System.DefaultWorkingDirectory)/**/CHANGELOG.md
• Assets:

$(System.DefaultWorkingDirectory)/**/drop/beta-public/*.nupkg

• Options: Pre-release & Add changelog

Editing a Release

Now, when I go into my final phase to publish my packages to stable on NuGet I want to modify the release I just created. You could optionally create a new release and different tag, but this makes no sense to me currently (leave comments below to let me know what you think).

You can simply add the same exact Task and instead of specifying Create for the Action specify Edit. You will fill in all of the same information except at the end:

• Assets: Instead of beta-public folder, I change it to public
• Replace existing assets
• Uncheck pre-release

And just like that you will have beautiful releases automatically when you publich to NuGet in pre-release or stable:

PList Transform

The first feature you will see is a brand new PList Transform Task. Andrew sent down this pull request and it is super slick. Basically just set any property name and value you want to set in your iOS plist file and you are good to go!

Unix Timestamp

When versioning apps I always had the assumption that developers wanted to manually configure version numbers. However, sometimes you want an auto incrementing number such as a timestamp. When versioning iOS and Android apps you now have the ability to select a custom version number or auto numbering with the Unix time in seconds. This matches App Center functionality, which is super cool :)

Misc Updates of Joy

Beyond that we fixed a few other items such as adding the iOS Bundle Identifier to the package name task, fixed issues when comments were in the Android Manifest, handled escaped paths, and updated to the latest packages.

Grab the Extension

You can grab the latest update of the Mobile App Tasks from the Visual Studio Marketplace right now!

Watch Me & Donovan

Last year my good friend Donovan Brown asked me to come on Visual Studio Toolbox to show off the awesome extension and talk Mobile DevOps. Check it out as I walk through the extensions:

How It Was Developed

If you want to see more on how it was developed be sure to check me out on Twitch where I live code. I recently did a full live stream where I added the unix timestamp feature to iOS and Android build tasks. You can watch the full video on YouTube right now!

So, first things first.. The backend.

My Items on ASP.NET Core

If you head over to your Visual Studio for Mac you will see a “Connected App” template. This outputs an iOS and Android app that can talk to a localhost ASP.NET Core application that runs on your macOS machine! Whoa Cool!. Now make sure you have the latest RC4 of .NET Core installed. It isn’t the one on the home page of .NET Core.. it is hidden in a GitHub readme: https://github.com/dotnet/core/blob/master/release-notes/rc4-download.md

If you just want the source code for the app to play around with you can grab it from my GitHub. Now, once we have the source code we can run the site and navigate to /api/item to retrieve the default lists of items:

Linux App Service

Looking good! Next up, Let’s create our Azure App Service that will run on Linux (in preview today). Head to your Azure Portal and hit New -> Web + Mobile + Web App on Linux (preview):

This will go through the standard setup process and bring you in to your standard app service settings. The first thing that we need to do is adjust our Docker Container. We want to select .NET Core v1.0 runtime stack and REALLY REALLY IMPORTANT to set the startup file. This file is the main DLL of our application. We will be uploading our files to the wwwroot.

Build

I decided to throw all of my code in Visual Studio Team Services (VSTS) and do some good DevOps work to make Donovan Brown proud. You could also just put your code on GitHub if you would like and VSTS will also build it. To actually build it, is crazy easy actually, just select ASP.NET Core (PREVIEW).

This literally does everything for you! I have disabled tests and I have my dotnet commands pointing to a subfolder, but that is about it:

Release

Now, let’s publish this thing. The build will give us a zip file to use and normally you would use Web Deploy and done… but that doesn’t work on Linux just yet… and Kudu… not yet.. and all the continuous git stuff… not yet… so let’s FTP the files! In the azure portal you can grab your FTPs user name and password that you will need.

There are 4 steps needed in the release definition:

1. Stop App Service

2. Extract Zip File

3. Upload Files

4. Start App Service

1, 2, and 4 are easy with minimal config, but #3 you must specify the remote directory of /site/wwwroot

Whoa!! we did it!!

Fun fact… Preview inside of VSTS and the Azure portal in this blog post alone are cased 3 different ways :)

If you are looking to get your Xamarin apps setup in VSTS then checkout my blogs for Android and iOS that offer a full walk through. This blog will work with any iOS or Android app regardless of how you build it :)

ALM Build & Release Tools

There unfortunately is no out of the box support from what I have seen to actually bump versions, but we can leverage a marketplace extension from Colin called ALM Build & Release, specifically the “Version Assemblies” step.

Android Version Bumping

In my Android manifest my name and code look like this:

android:versionCode="1" android:versionName="1.0.0"

These are important, as we will use a regex to update them.

We will want to add the “Version Assemblies” task TWICE, once for the version name and once for the version code.

Once added, we will bump the name.

First insert the following (with examples):

• Source Path: src/MobileApps/MyDriving/MyDriving.Android/Properties
• File Pattern: AndroidManifest.xml
• Build Regex Pattern: (?:\d+.\d+.\d+.)(\d+)

Under Advanced:

• Build Regex Group Index: 0

• Regex Replace Pattern: versionName=“\d+.\d+.\d+

• Prefix for Replacements: versionName=”

What this will do is update the version name to the Build number format found under “General”, which mine is set to 1.0.0$(rev:.r)

Now for the next one, which is the version code:

• Source Path: src/MobileApps/MyDriving/MyDriving.Android/Properties
• File Pattern: AndroidManifest.xml
• Build Regex Pattern: (?:\d+.\d+.\d+.)(\d+)

Under Advanced:

• Build Regex Group Index: 1

• Regex Replace Pattern: versionCode=“\d+

• Prefix for Replacements: versionCode\

And just like that you are good to go. This will simply update it with the current version revision :)

iOS Version Bumping

This one is a bit trickier and requires some specific things set in the Info.plist. We will need to ensure that the following are set to these very very specific version numbers in the actual Info.plist:

• CFBundleShortVersionString: 1.0.1

• CFBundleVersion: 1.1.1 

Don’t ask me why, just trust me!

Under General I have set my build number format to 1.2.$(rev:.r):

I think we just happened to be on 1.2 which is why it is like this, your mileage may vary here. Now we will add the Version Assemblies task TWICE, just like we did for Android.

Let’s first bump the CFBundleShortVersionString:

• Source Path: src/MobileApps/MyDriving/MyDriving.iOS
• File Pattern: /Info.plist
• Build Regex Pattern: (?:\d+.\d+.)(\d+)

Under Advanced:

• Build Regex Group Index: 1

• Regex Replace Pattern: 1.0.\d+

• Prefix for Replacements: 1.2.

That will bump it to 1.2.BuildNumber. 

Let’s then bump the CFBundleVersion:

• Source Path: src/MobileApps/MyDriving/MyDriving.iOS
• File Pattern: /Info.plist
• Build Regex Pattern: (?:\d+.\d+.)(\d+)

Under Advanced:

• Build Regex Group Index: 1

• Regex Replace Pattern: 1.1.\d+

• Prefix for Replacements: 1.2.

As you can see I have to execute these in a specific order to not bump versions differently. It is tricky, but so are regex. And there you have it, bumping versions for both iOS and Android inside of Visual Studio Team Services.