Wednesday, 25 May 2016

Getting started with LaunchDarkly and client-side feature flags

These days it is extremely easy to start using Feature Flags, especially with a service like LaunchDarkly.

In my case, I just wanted to setup a quick demo of client-side feature flags using only plain JavaScript and LaunchDarkly – I am pleased to say it is extremely easy even for a Web 0.9 chap like me! (Yep, I never really got into the Web 2.0 and the WhateverJS frameworks craze of the last few years Smile)

Let’s start with a few assumptions:

  • I want to use LaunchDarkly to manage my Feature Flags (and there might be many reasons behind this choice)
  • I want to show features only for authenticated users

I am not going to authenticate users myself  so in this case I am going to rely on LaunchDarkly acting as an authentication backend as well. This is totally done on purpose – when a feature is going public then no authentication is required to use it, otherwise a user would be authenticated against LaunchDarkly.

So, I need to create Feature Flags on launchdarkly.com:

image

Each Feature Flag has a key (feature-* might be a good naming convention), and it is important to set any feature as Available in client-side snippet to access them via JavaScript.

image

Then add the JavaScript SDK as per the documentation:

image

Now, all I am doing is extremely easy: starting with the empty ASP.NET Application, I am going to remove the views statically referred by the Controller in the list on the navbar, and I am going to add an id attribute to this list:

image

Then I am going to add this series of scripts:

image

The EnableFlags() function is going to retrieve the potentially authenticated user from the Local Storage (I am using it as a mean to save the authenticated user – there is no real backend in this application Smile), authenticate this user against Launch Darkly, clean the list, and then check if any of my feature flags is turned on for the user. If so, the aforementioned list is dynamically populated.

Bear in mind – this works also for non authenticated users.If a feature is available for them it will show up.

The two other functions are Login() and Logout() – the first sets the user in the local storage and the second one deletes the user. Again, this is not cool or production JavaScript but it is for demo purposes and it works Smile

What happens is very nice: I can start deploying my application only to the users I want to:

image

Once I am confident with my code, I can rollout the feature to all or a percentage of my anonymous users:

image

This is just a starting point, the coolest part about LaunchDarkly is that you can integrate it with VSTS so you can rollout a feature at release time:

image

Use Feature Flags, implement them with either OSS libraries or with Launch Darkly, they make life so easier when it comes to delivering value for your customers!

Sunday, 8 May 2016

Simple pipeline with UWP and HockeyApp

Everybody needs a starting point here and there, so this post would be pretty much about what I did with a very similar situation – a very basic pipeline to push UWP builds to HockeyApp

What I wanted was a carefree, easy way of pushing CI builds to HockeyApp so I could enable manual testing for users. Let me add another requirement to the mix – in my case, we are talking about sideloaded apps, and only for x86 and x64. This doesn’t change the actual result though, we’ll talk about ARM at the end.

image

This is the pipeline I was talking about.

The first step is a PowerShell script – what it does is to change the value of the last build number in the appxmanifest so that each build will upload a new version of the app to HockeyApp. The service identifies a new build from its build number, so what I did is just changing the revision number with the BuildId of my Build. Simple as that.

Then the build restores the NuGet packages, and builds my app for x86 first and x64 then. The reason why I went down this route is because I wanted to keep things as simple as possible, with a very intuitive tree structure and preparing the folder for the Zip task I used next.

I decided to use a Zip Directories task from fellow MVP Peter Groenewegen. Building a task from scratch wasn’t in the cards because of time constraints in this case, and Peter’s did the job as required.

image

The task would create a zip file of the App_1.0.0.$(Build.BuildId)_Test folder. This zip file contains the build artifacts I am feeding to VSTS and HockeyApp.

Small shortcut, but this works well Smile basically this name comes out from the AppxBundle process, and the BuildId is there because I changed the appxmanifest file with it so it is nicely available everywhere in my build. This could be extended with a build variable though.

After uploading the symbols, the build uploads the artifacts:

image

from the folder I used as a destination when building, the build engine searches for the zip file I created previously with the task. It is a Server artifacts, meaning it is stored in VSTS.

Eventually, HockeyApp is fed with this file:

image

image

The connection comes from the Service Endpoint you need with HockeyApp. The App ID is the one you’ll find on HockeyApp and the Binary File Path is where the source for the zip file you need to upload is. Simple as that.

In HockeyApp you’ll see the build as soon as the process is over:

image

The zip files the build uploads contains these files:

image

which is exactly what you would get from the Create Package wizard in Visual Studio. Running the PowerShell script installs the app on the target system.

I mentioned ARM at the beginning – to add ARM to this pipeline you’ll need to add another build step for ARM, and then uploading the appx file generated by the build.

It is a slightly different process at the moment, and this requires a different provision on HockeyApp as well: the ARM app needs to be separate from the UWP one at the moment so you can upload the build artifact.

Tuesday, 3 May 2016

Application Insights Live Metrics Stream with ASP.NET 5

The single feature I deeply loved from the old Visual Studio Online Application Insights (before it was handed over to the Azure Team) was the Developer Dashboard, a real-time overview of how your application was faring.

Improve your product by analysing real world usage data with Visual Studio Online Application Insights

There is a replacement though: Live Metrics Stream. It is very powerful, way more than the old Developer Dashboard:

image

The problem is that if you try to configure it with an out-of-the-box ASP.NET 5 Application you will never manage to make it work:

clip_image002

…even if you have the latest Application Insights SDK package installed.

The reason is because not all the features of Application Insights are supported out-of-the-box with ASP.NET 5 – if you run it against .NET Core 5.0.

If you want to integrate LMS in an ASP.NET 5 application, you need to add this code snippet to your startup.cs file and remove dnxcore50 from your project.json file.

image

I totally expect a full support for all the Application Insights’ features to come soon, but for now if you really need LMS in your application you need to stick with DNX 4.5.1+ as a runtime.

Friday, 22 April 2016

A look at the new Work Item Tracking features in VSTS

I usually don’t do this, but the VSTS teams are overhauling this area at such a pace that makes a knowledge refresh really needed Smile

Aside from the cards layout a few months ago, there are really compelling features added to the platform. It isn’t easy to define what compelling is for WIT, as it is much of user interaction scenarios more than pure technical stuff doing magic, but I find them very, very interesting.

First of all, how many times during a planning meeting you create a Work Item and you then realise you chose the wrong type? Believe it or not, it happens all the times. Now you can just change the type from the UI, easy as that:

image

image

image

Another feature worth mentioning is the possibility of moving a Work Item between Team Projects. There might be a ton of reasons behind this need, I even heard of a Team Project used for support and escalation requests for multiple products.

Anyway, it is just like this, and you can also change the type here:

image

 image

You can also create a new branch from a Work Item (very handy for feature-based development):

image

image

This is a fantastic way of keeping the planning aligned with development, IMHO.

Eventually, you can now follow a Work Item.

image

This means you’ll get an email whenever this Work Item is updated by other members of the team – I can already see Product Owners’ hands clapping!

Tuesday, 12 April 2016

Considerations on HockeyApp and exception management strategy for apps

I started to look at HockeyApp recently, and I reckon it is quite an impressive piece of software. Microsoft acquired it in 2014, and now they are pitching it as the solution for Application Monitoring for apps, regardless of the platform, while Application Insights is the APM solution for web application and services.

With that in mind, the first thing we need to know is that we need to join HockeyApp’s Preseason program – it is an early access program (they are quite into hockey over there Smile). With that you will get access to the UWP support but also to another key feature: custom events.

The thing with HockeyApp is that being an app-centric tool the main usage scenario they developed the product around is when the app crashes in an unmanaged way.

image

Unmanaged is key here: without Preseason SDK (NuGet package actually) you can only gather crash data at the next application launch. And what if I would like to collect data from exceptions I manage on my own?

image

That is where Custom Events come around. They are not as descriptive as unmanaged exceptions (HockeyApp collects stack trace data, device information, etc.) but they are a very handy way of keeping track of this important data distribution.

The exception management strategy here becomes two-folded: unhandled exceptions go straight to HockeyApp with all the trimmings, while instead you need to separately log the exception data you need when you manage to catch them, and then send the relevant event to HockeyApp.

image

In the future I am expecting features to be added from both Application Insights and Xamarin Insights to HockeyApp. The latter two teams merged as of a few weeks ago, and this can only reinforce an already very good platform.

Saturday, 9 April 2016

Getting started with Kusto a.k.a. Application Insights Analytics

Last week Brian told us about Kusto, an internal data analytics tools which then became a component of Application Insights.

You can start using it right away, there is nothing to configure. You’ll find an Analytics button in the Application Insights blade on the Azure portal:

0

1

There are lots of samples ready to go – let’s take the first one (distribution of response times in the last 24 hours, by response code):

2

The language is very straightforward – there is also a guide here. The result will be charted at the bottom:

3

4

This is another good one – application requests comparison over a 24 hours period:

5

6

Data like this is critical for proactive monitoring as well, you can periodically monitor this dashboard and understand where the bottlenecks are in your application.

It is really a great tool!

Wednesday, 30 March 2016

On the potential of Bash on Windows in a DevOps world

One of the announcements of todays’ //build is the availability of Bash on Windows, thanks to Ubuntu. I share the excitement as well, but focus on individual developers left something behind IMHO: it is a great step ahead for development purposes on development machines, but also from a DevOps perspective.

Let’s put it in this way – if you are developing a cross-platform application, which can run on both Windows and Linux, you now have the potential of a single set of scripts for automation.

image

You won’t have to maintain two different sets of scripts. You will be targeting both Windows and non-Windows machines, with the same logic, reducing maintenance costs by roughly half and standardising on procedures which would work on both.

I really see it as a game changer in the DevOps world! Smile