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 )

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:

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.

Then add the JavaScript SDK as per the documentation:

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:

Then I am going to add this series of scripts:

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 ), 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

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

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

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:

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!

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.

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.

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 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:

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:

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:

The zip files the build uploads contains these files:

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.

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.

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

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:

…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.

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.