Hello all, man what a summer! It's only the beginning of August and I have to tell you the last 6 months have really gotten away from me. I've been really busy working on a variety of exciting things, and some not so exciting things. Some of the high notes will be making it to this blog, so stay tuned for that.
Specifically, I've been doing some work with Mobile, and Xamarin. For those who have been watching my blog and twitter accounts, you know that I've been a big supporter of Xamarin for a while, and generally speaking, think it's one of the more powerful mobile technologies out there. Don't get me wrong, PhoneGap and technologies like it definitely have their place, but when you are looking at the enterprise or an application that has some real "meat" to it, in that you are trying to build something to help a business. I just find that you tend to run into a wall pretty quickly when you are using those html5 technologies.
The reason being that for my money, the fact that Xamarin wraps the native libraries makes it more valuable as you aren't having things lost in translation.
Worked for Bill Murray's career, but in AppDev, it just makes all our lives harder.
Now being that I'm a big devops guy, to me when I set out to do mobile work, right after I created the project in Visual Studio, I did two things.
- I created an automated build with continuous integration
- I setup a release pipeline straight to Azure
To me, these should be the things you try to setup as soon as possible. ESPECIALLY if you are doing mobile. Cause let's face it, those simulators are nice, but would you trust a pilot who only flew a simulator. My experience has always been simulator testing is only good for is there anything immediately wrong with my code. Nope... then off to the device.
So that being said, for as great as Xamarin Studio is, deploying to a mobile device is a painful and tedious process. One that I desperately want to avoid. So I went and setup my automated deployment using HockeyApp to push releases to Azure and my phone as I work on the application.
First things first though, let's take a look at the build. Given that this solution contains both the Web API services that the application will be leveraging, and the Android app I'm developing, my resulting build looks as follows:
A couple of things to note here are as follows:
- The "Build Solution" step is using the following build arguments /p:CreatePackageOnPublish=true /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)" /p:AutoParameterizationWebConfigConnectionStrings=False
- I do NOT have the use "Activate Xamarin License" build step. This was a confusing note that I had to figure out. For my builds, I have a "local" agent installed on a VM in Azure, and then I leverage this VM as my build server. For this, I went out to my build server and installed Xamarin Studio alongside Visual Studio 2015.3. After doing so, the build will automatically leverage the installed version. The only reason you would need the Active / Deactivate steps is if you are using a "Hosted" server, because they are not configured with your license and would have to be activated at the time of the build.
- Another important step here was the "Signing and aligning APK file(s)" without this step you are not able to push to your Android device without receiving an error message.
Now that takes care of the build, so let's look at the release. My release is configured as below:
Now a couple of things you are probably noting is the 7z and tokenization tasks. These are tasks I contributed to with Total ALM. You can find more details about these steps out there.
Now for the sake of my own sanity, I broke this into two environments, a PreProd environment and a Production environment. Now the principle difference between the two is that "PreProd" covers the web services, which on each checkin I would like to have them updated. But in the case of the mobile app, I don't necessarily want that in the beginning. As I plan on working on the web services to support the app first. So production is pushing the actual mobile app to my phone. I'm going to focus on that environment, as shown below:
As you can see, this is pretty slim. I'm leveraging the HockeyApp task which can be installed into VSTS using the Marketplace.
Now once installed, this was pretty easy and straight forward to get configured. If you follow the process of creating an app using their getting started guide, it's surprisingly easy to get configured.
Once you've created your first app, it's as simple as configuring the settings provided. The only two required if you are new to hockeyapp are the Binary File Path, and the HockeyApp connection. This can be done by clicking the "Manage" link within the task and then adding a connection name and api token that you get from the HockeyApp portal. Below are the configuration settings for the hockeyApp task.
From there, it's as simple as doing a checkin to trigger a build. For downloading, your clients will have to download the "HockeyApp" app for iPhone or Android phones. This will manage their downloads and allow them to download new versions when available.
It's also worth noting here that I've talked about what it takes to get an Android app deployed here, the process is more involved for iPhone / iPad and would require a mac, or a macincloud VM and a provisioning profile and other steps. Apple seems to make EVERYTHING more complicated.
Like I said, pretty simple overall. Enjoy and happy development!
Also, while I got you here, I thought I'd recommend a book for those of you in the devops world, I think it should be required reading for all IT professionals if you want to be effective at your job.
It's called the Phoenix Project, and it's a book written like a novel about managing IT and operations to provide support in a world of changing expectations. Fantastic read! Especially for those who want to help their organization move away from bad practices, it will arm you for those conversations.
Another strong recommendation I have is for The Goal by Eliyahu Goldratt. It talks about ongoing improvement and in-terms-of plant management. Which you wouldn't think applies to IT but it does, and it does a great job of helping to identify problems in your current IT processes and software development process. These truths are timeless.
Well, that's all for me and I hope to be updating again soon.
