This is a brief post because it’s the second time I’ve had to resolve the same issue and as I don’t think my memory is getting any better, it’s probably better this goes down on my permanent record. 😉
I love a good feedback loop…
Gene Kim talks about the importance of both internal and external feedback loops in his blog post, The Three Ways: The Principles Underpinning DevOps. This includes internal feedback loops such as the result of continuous integration builds, unit testing and application performance monitoring tools like Application Insights. It also incorporates feedback loops from end-users to leverage telemetry and error information to increase the quality of the delivery. This telemetry is the foundation required to prove the outcome of experiments and hypothesis driven development.
In a recent presentation at Xamarin Dev Days 2017 in Melbourne I demonstrated the ease in which teams could adopt DevOps in their mobile application development lifecycles. To do this I embraced our new platform, Visual Studio Mobile Center and showed how teams could leverage it’s API to implement the feedback loops required for hypothesis driven development.
Feedback loops are a critical component of any DevOps transformation. A highly automated build and release cycle is so important but when unexpected circumstances occur the team needs visibility in order to react accordingly.
I love how Visual Studio Team Services provides really powerful dashboards perform this exact role. Below is an example of some of the widgets that VSTS supports out of the box to provide an indication of build and release status. Hosted in a public area, the team can rapidly see what build is in what environment and whether anything has gone wrong.
With Visual Studio Mobile Center the story is a little different. Even if the source code to your Xamarin project is in VSTS, Mobile Center is still performing the build in its magic little black box. This is great because Microsoft maintain the build servers and there’s no need to configure complicated build definitions. The challenge is however, without watching for status emails or going to the Mobile Center portal it’s difficult to see the outcome of a build.
In addition, if the application has additional resources (such as a web API) I may want to see the status of all of the components on one dashboard. Thanks to some native features of VSTS and Mobile Center, we can do just that…
I’ve been working pretty seriously with the Desktop Bridge (Project Centennial) to help some of our partners get their Win32 applications into the Windows Store. As a bi-product of this I have come across a whole host of valuable resources on what the bridge is all about and how to use it in different scenarios.
Desktop Bridge – The bridge between desktop apps and the Universal Windows Platform – A general overview of the desktop bridge and why it’s so cool.
Desktop Bridge – Converting an installer with Desktop App Converter – Some guidance on the simplest strategy for converting desktop applications using the Desktop App Converter tool.
Desktop Bridge – Manually converting a desktop application – How to convert any bag of files (no installer required) to a Windows Store app.
Using the updated Desktop App Converter to manually convert a desktop application -Now the Desktop App Converter makes manual conversion easier by allowing you to point at a directory rather than an installer.
An easier way to generate the packages for a Desktop Bridge converted app – Manifest hacking and asset generation to simplify AppX generation.
Desktop Bridge (aka Project Centennial) samples – Some nice examples of features that can be leveraged from applications converted using the Desktop Bridge.
Desktop Bridge Debugging Project – A Visual Studio 2017 extension that adds support to help build and test Win32/.NET applications converted using the Desktop Bridge.
I have been involved in a Conversation as a Platform (CaaP) hack this week and the first thing that seemed to be valuable to the teams was to sort out a CI/CD pipeline for their projects. With the introduction of the Continuous Delivery Tools for Visual Studio from the marketplace this is actually surprisingly easy to do. The tool will perform the following activities:
- Create an App Service in your Azure subscription.
- Create a CI build for the bot.
- Create a CD release to the App Service.
With that in place, the teams could then hack away together with all of their changes going straight to a live app service that they could immediately visualise their updates with. Let’s take a look…
I’ve been hacking a fair bit on Visual Studio Mobile Center lately. The feature set is iterating pretty fast and recently the introduction of the ability to link Mobile Center to VSTS was added. Along with that, a couple of build tasks appeared in the vsts-tasks Github repository:
These new tasks enabled VSTS build or release definitions to trigger tests and upload build outputs for distribution through Mobile Center.
Since Mobile Center has been built API-first, I started wondering if I could make my own build task to actually trigger a build. Seems it isn’t too difficult.
I first started with an awesome post from Mitch Meunster where he used a Zamboni build tasks to upload builds to Mobile Center. If you want to learn how to configure Mobile Center and hack against the API then check it out.
With that knowledge under my belt I’ve written a build task and posted the code on GitHub. Let’s run through what I had to do to build the task and what you have to do in order to use it…
TLDR: You can either read the whole thing (which I recommend) or jump to the build/use sections:
Let’s have closer look… Continue reading
With the release of Visual Studio 2017 I made the decision to uninstall 2015 a couple of days ago. This immediately presented me with two challenges:
- My unit tests stopped working when run on my private build agents.
- I could no longer push to my VSTS Git repositories. This turned out to be my error but I’ll cover that one in a separate post…
In this post I’ll surface some options to resolve the issue and justify why I chose one particular solution.
As part of a hackathon last week I had the pleasure of playing with some technologies that I didn’t have an enormous amount of exposure to. The focus of my team’s part of the hackathon was the following:
- Analysing a video with Cognitive Services
- Processing the results from Cognitive Services
- Saving the results to a data store so it can be displayed
- Visualizing the results with Power BI Embedded
My personal work and this resulting post deals mainly with the second and third items as there were some unique challenges that came into play when utilising the output that came from streaming analytics. The flow of data looked a little something like this:
We hacked on Azure Media Services being analysed by Azure Cognitive Services and posted its results to Event Hub. We then used Stream Analytics to process and group the data before throwing the results into a Service Bus queue. We grabbed the data with a simple Logic App, inserted it into a SQL Azure table and rounded out the flow with a visualisation in Power BI Embedded. I know that’s a lot of ingredients to throw in an omelette but let’s go break a few eggs…
This is a follow up to my Microsoft Ignite 2017 session NET332. The primary purpose of the session was to demonstrate the ease in which an application with no identity management capabilities could leverage both the Active Directory Authentication Library (ADAL) and the new Microsoft Authentication Library (MSAL) to add authentication functionality to your apps.
It’s been a while between posts but the latest focal point for my attention has been HockeyApp. In this multi-part series I will detail my exposure to the framework and identify the solutions to any challenges I faced along the way. As HockeyApp currently doesn’t quite have the coverage across all application types (Android, IOS, Win81, WinRT, UWP, etc) there are some unique obstacles that need to be overcome depending on your application architecture.