I started this experiment for several reasons.

One is that I had been thinking about books for quite some time. During my time as evangelist a publisher asked me to write a book on Windows Store App development. While I always wanted to write a book just because it would be awesome to call myself an author at this time the APIs of the Windows RT platform changed rapidly. The publisher told me that it typically is a project of several month or even more than a year to write a book. (We’re talking about a physical book here, made of paper.) Basically my book would be outdated when it was printed. So I declined and started thinking about what authoring a book should look like today.

[ Years later my first ebook was published. It was only a collection of blogposts wrapped into an PDF, MOBI and EPUB format. (My colleagues at Microsoft helped me with all of this a lot.) The posts contained information on Visual Studio tips in German language. So it was a rather quick & dirty approach but it fulfilled it’s goal: Sharing knowledge with the world. ]

It it pretty obvious to me today that documentation on something that fast moving and volatile as e.g. a cloud computing platform or a very frequently updated piece of software is outdated very soon if you print it on paper. So going forward I wanted to focus on digital books.

But even a digital version doesn’t keep itself updated. We have to make sure we can rework and update the content over and over again, fix bugs and include changes rapidly keeping the cycle times low. Wait a second — doesn’t this sound familiar if you’re coming from a software engineering background? Sounds like the need for CI/CD for me! Take a look at http://docs.microsoft.com The new documentation is located on GitHub and everybody can work on it or send Pull Requests. The docs improved a lot over the last month and I think the reason for this is the switch to the new platform. Couldn’t this concept also be used to write a book? And: Where’s the difference between writing a book on a technical topic and writing brilliant technical documentation?

The ultimate driver for me to start working on this was that I own an ebook reader (Tolino) which I take almost wherever I go. And I found that it is pain to read documentation which comes in PDF, because it’s just not made for ebook readers. I realized that when I tried to download the PDF version of some docs.microsoft.com chapters. I thought it would be awesome to be able to take that info with me and whenever I sit in a plane or train or anywhere else without connectivity and I feel like learning new stuff I start reading the docs. However this doesn’t look too good on my Tolino, because scrolling, zooming, panning PDFS is just pain.

So here’s the very obvious idea: Write a book based on a bunch of markdown files located in GitHub. And then create a build and deployment process to publish a new version every time a PR has been accepted. Pretty straight forward. To make things more attractive I added a function who lists every Contributor on GitHub as an author.

Now the last thing is which topic I would choose so that the concept of the book will work. I’m a strong believer in the developer community because I learned over years that developers are very willing to share their knowledge. And I really profited from that quite often. So, my choice is obvious: Let’s write a new version of that Visual Studio Tips & Tricks book as a starter. If the tech proofs to be working, we can pick greater challenges later on.

Do you want to participate? All you have to do is share your one favorite tip to become a book author. The latest version of the book can be found here. The guidance how to participate can be found here.

Thanks for your contributions.

Let’s write a book together — CI/CD for ebooks was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was expecting some challenges but I got up to speed very fast — actually way faster then expected. Here’s what I wanted to do and what I’m asking you to do as well:

1. Specifiy a hashtag to identify tweets related to my service
2. Create an Azure Logic App to check Twitter periodically.
3. Call the sentiment analysis service provided by Bing.
4. Write the results of the analysis into this Azure SQL Database.
5. Create a PowerBI Dashboard to display the results in a chart.
6. Publish this chart and show it on my Team Services Dashboard.

This sounds like a lot of work. In fact: It’s not. Before we dive into the details, here’s what I got:

This diagram shows the average sentiment for all tweets related to my specified hashtag on a per hour basis. The closer the value to 1 (the higher the bar) the better is the mood. The black line gives an indication about how many messages have been tweeted — so you have an indication whether an increase or decline is backed by many voices or just a single tweet. I’m pretty sure you could beautify the chart a lot and integrate all kinds of colors but that’s not the focus.

As always here’s a warning: This post shows the technical aspects — I’m totally aware that an interpretation of the sentiment analysis is a totally different story. Be aware that this analysis only displays the sentiment of people who spoke up on Twitter — there might be plenty of unheard voices, though, so this should be considered as just another feedback channel. Anyway it’s an interesting metric to look at.

Here’s what I did to get there. You can follow the steps to build it yourself. Another warning: I’m working mostly with free plans here. This will limit your experience as the database size is limited and the number of free service calls is limited as well. If you’re not working on a free plan, cost might occur!

Create an Azure SQL Database

I didn’t create a new one, I just used one I had for demos anyway. You can use the free version. Here’s how you do this. Then add a new table to the database to store the Tweet Data. I ran this SQL statement to do so:

CREATE TABLE MoreTweets (

id int PRIMARY KEY IDENTITY,

createdDate datetime DEFAULT(getdate()),

tweettext varchar(512) SPARSE NULL,

sentiment Float NULL,

author VARCHAR (512) ,

);

Create a Twitter account

Surprise, surprise, you need a twitter account. Go, get it here: http://www.twitter.com You need it to be able to query Tweets from the logic app.

Get a Cognitive Services key

Microsoft provides a bunch of cognitive services to analyze images, speech and text and so on. We’ll be using this service, but you have to sign up for it. You can do a limited amount of analysis per month for free, that’s what we’ll be doing.

Get the key for the Text Analysis API here: https://azure.microsoft.com/en-us/try/cognitive-services/?api=text-analytics

See the screenshot below.

Create a Azure Logic App

We need an Azure Logic app. If you’re working on the free Azure contingent of an VS MSDN Subscription or on a free trial things are free for you as long as you did not delete the cost limit explicitly. If not and you just want to try out things make sure to disable the logic app after some experimentation as cost will occur!

Edit the workflow of the logic app in the logic app designer after the logic app has been created.

Click the “new step” button and add three actions. I was impressed when I figured out, that for everything I wanted to do there’s already a step available which means I won’t have to write a single line of code. Just search for the connectors for Twitter, Text Analytics and SQL Server. Those connectors will provide specific events and actions. Just add them as shown below.

This is what the workflow should look like.

If you click the Twitter step, it will ask you to configure a connection to Twitter. Specify your credentials. Then enter the appropriate values regarding keywords and interval. I set the interval to 3 Minutes. Choose the keyword as you prefer. If you don’t have a good keyword and still want to do the sample, just search for any product name you’re interested in or check the trending hashtags on Twitter. Be warned: This might bring plenty of traffic to your workflow!

The sentiment analysis task is pretty straight forward. First you have to specify the keys you created earlier and give the new connection a name. Then you want to pass in the text of the tweet found. Just click into the text box. This will open up a menu showing “dynamic content”, which is provided based on previous tasks. In our case, of course we know all content related to a tweet containing our keyword by now. So we can just add the tweet text by clicking the Icon “Tweet text”.

This is what it should look like:

As a result of this step we will get the sentiment of this tweet. So in our last step will will write all of that into our database. Again in the SQL Server “Insert Row” step, we have to establish a connection to a specific database first. This will be very easy if you’re using an Azure SQL Database — the connections will be available already, you just have to pick the database. Then specify the table (Tweets, in my case) and pass the values — again taken from the dynamic content.

We don’t have to specify the “createdDate” — it will be filled when the value is entered to the database automatically. I also store the author. This would allow me to figure out if there might be a single person who’s affecting the metric (I didn’t implement this filter yet, however).

We’re done. Let’s run the logic app now. Just click run in the editor. Over time, this will fill your Tweets table in your database.

Create a report in Power BI

Now create a new report in Power BI. You could do the same thing in Excel, but Power BI is pretty handy when it comes to publishing stuff afterwards.

In Power BI click “Get Data” and pick “Azure SQL Database”.

Specify servername and database name and choose “Direct Query”. This way the data shown by the report is taken directly from the database (with a cache which can be updated). Now it depends on what you’re going to display. I used the “advanced options” to be able to run a T-SQL query on the data to adjust it before I’ll be using it in my report.

Here’s the query I’m using:

SELECT

Convert ([datetime],

(Convert(Varchar,DatePart(year, createdDate ))) + ‘-’

+ (Convert(Varchar,DatePart(month, createdDate ))) + ‘-’

+ (Convert(Varchar,DatePart(day, createdDate ))) +’ ‘

+ (Convert(Varchar,DatePart(hour, createdDate )))+’:00 ‘

) as dateBasedByHour

,

createdDate,

id, sentiment FROM tweets

The reason I’m doing this is because I want to have the tweets clustered by hour and not listed separately one by one. This seemed to be a simple way to get there — I basically just skip the minutes and set them to 00. Maybe Power BI can do this in another way as well, but that’s the path I took.

In Power BI now create a “Line and clustered column chart” as seen below. Activate the values “datebasedbyhour” and “id” and “sentiment” as shown below. Make sure you’re using “Average of sentiment” (not sum) as column value and Count of id (not sum) as a line value. I also added a relative date filter showing values from the last 7 days.

Now let’s publish this on Power BI. You can do this via the File menu.

Create a public link

After publishing you’ll get a direct link into Power BI Web. Create an “Embed code” there by choosing “publish to web” in the file menu of Power BI Web. You’ll be presented a link to your chart. Be aware that every person with this link will be able to see the chart. In our case it doesn’t matter I guess. The information is public on Twitter anyway.

Add the chart on your Team Services dashboard

Now go to your Team Services account and add an “Embedded Webpage” Widget on your dashboard. I chose the 3x2 size. Specify the embed link you got. Place the Chart on your dashboard. You’re done.

I think this is a very easy way to always keep an eye on what’s going on in public about your product. If sentiments are declining badly it might be an indicator that something is going wrong. If its increasing or if there’s just more chat about your stuff going on — you might be on the right track.

Go ahead and give it a try and let me know what you think about it.

How to create a Twitter sentiment analysis for your service was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Es gibt mehrere Wege einen Test zu erstellen — am, einfachsten ist sicher das Erstellen in Visual Studio. Zur Ausführung in der Cloud benötigt man eine Azure Subscription und und einen Visual Studio Team Services Account.

Erstellung und Ausführung eines Lasttests mit Visual Studio

Einen Lasttest kann man am einfachsten mit Visual Studio erstellen. Dazu legt man ein Web Performance and Load Test Projekt an, Wie der Name schon sagt, gibt es hier zwei Komponenten: Webtests und Lasttests. Ein Lasttest führt einen oder mehrere Webtests in einer vorgegebenen Häufigkeit aus, um eine gewisse Last auf dem zu testenden System zu erzeugen.

Zunächst braucht man aber den Webtest. Eine *.webtest Datei exisitiert schon im Projekt, man kann beliebige weitere hinzufügen. Nach dem Öffnen des Webtests zeigt sich ein kleiner roter “Record” Knopf. Damit kann man das Mitschneiden des Netzwerkverkehrs auf dem eigenen System starten. Anschließend würde man im Internet Explorer die zu testende Website besuchen und hier beispielsweise einen bestimmten Ablauf auf dem Zielsystem ausführen (bsp. User Login, Produktsuche, Ware in Einkaufskorb legen, Ware aus Einkaufskorb entfernen, ausloggen). Den aufgezeichneten Verkehr kann man anschließend einsehen, editieren und parametrisieren. Auf diese Art wird man unnötige Requests los (bspw. Requests auf Advertising-Anbieter) und kann den Webtest flexibler machen, was die Zielsysteme angeht (indem man zum Beispiel die Zielurl als Parameter anlegt.) Die notwendigen Buttons finden sich im Menü zum Webtest.

Als zweiten Schritt würde man jetzt einen Lasttest zum gleichen Projekt hinzufügen. Das Öffnen des *.loadtest startet einen kleinen Wizard, der durch unterschiedliche Einstellungen führt — hier kann man unter anderem auswählen, welche Webtests im Rahmen des Lasttests gestartet werden sollen. Ein Lasttest ist also eigentlich nichts anderes als eine Ausführungsanweisung für andere Tests — in unserem Fall Webtests.

Eigentlich ist man jetzt schon fast am Ziel. Früher — und damit meine ich die Zeit bevor man die grandiose und komfortable Möglichkeit hatte auf Cloud-Resourcen zuzugreifen — hätte man jetzt den Lasttests direkt aus Visual Studio gestartet und auf einem lokal verfügbaren Agent, vielleicht sogar auf der eigenen Maschine gestartet.

Die Cloud bietet uns hier aber den Komfort einfach auf Agents zuzugreifen, die immer, wenn wir sie brauchen zu Verfügung gestellt werden — ohne, dass Last auf eigenen Rechnern entseht. Und für diese Agents gibt es auch das erwähnte Freikontingent.

In diesem Fall würde ich im Load Test Wizard einfach meinen Team Services Account anwählen und kann dann im zweiten Schritt das Datacenter wählen in dem mein Loadtest ausgeführt wird. An sich ist das Datacenter egal — ich kann rund um den Planeten auswählen. Standardmäßig ist das Datacenter die erste Wahl, das zum Visual Studio Team Services Account am nächsten liegt. Unter gewissen Umständen kann es aber sinnvoll sein hier explizit ein anderes auszuwählen, zum Beispiel, wenn man eine möglichst kleine oder große Distanz von Agent zur Zielapplikation haben möchte.

Zum Ausführen drückt man einfach auf “Run Load Test”. Abhängig von den gewählten Einstellungen läuft dann der Test eben lokal oder in der Cloud. Die Ergebnisse werden in beiden Fällen im Visual Studio angezeigt.

Lasttests im Azure Portal anlegen und starten

Zugegebenermaßen ist das zwar ganz nett, aber es haut einen vielleicht noch nicht um — dazu ist es zu naheliegend. Wäre es nicht schön, wenn wir derartige Loadtests auch direkt aus dem Azure Portal ausführen könnten? Von Cloud zu Cloud?

Auch diese Möglichkeit besteht. Im Azure Portal kann man für Web Apps einen Performance Test anlegen. Hier besteht die Möglichkeit entweder einzelne URLs abzufragen oder auch hier einen Webtest aus Visual Studio zu verwenden. Kleiner Hinweis: Tatsächlich wählen wir hier ein *.webstest File — nicht, wie man vielleicht meint, ein *.loadtest. Die Konfiguration der gewünschten Last erfolgt dann im Azure Portal — daduch wird dann aus dem Webtest unterm Strich ein Lasttest. Über den Menüeintrag “Set Account” legt man den VSTS Account fest, in dem die Lasttestergebnisse später sichtbar werden — so sehen alle Beteiligten, ob das System ein Problem bekommt.

Kleiner Hinweis: In diesem Fall kann als Input für die Generierung des Lasttests übrigens auch ein HTTP-Mitschnitt von Fiddler dienen — die Beschreibung dazu findet sich hier.

Die Ausführung der Tests über das Azure Portal ermöglicht es mir also völlig unabhängig von einer Entwicklungumgebung eine Aussage über das Verhalten der Anwendung unter Last zu bekommen. Spätestens jetzt sollte klar sein, dass es sich in jedem Fall lohnt das freie Lastkontingent einfach mal zu verbraten — man bekommt auf jeden Fall ein besseres Gefühl, wie sich die eigene Anwendung unter bestimmter Last verhält und man braucht noch nicht mal eigene Hardware dafür zur Verfügung zu stellen.

Lasttests und Visual Studio Team Services

In Visual Studio Team Services gibt es mehrere Möglichkeiten Lasttests anzulegen. Die offensichtliche ist es ebenso wie im Azure Portal einfach manuell einen Lasttest anzulegen. Die Benutzerführung ist hier ähnlich gehalten wie im Azure Portal. Hier finde ich auch unter “Settings” die Möglichkeit die Last des Lasttests zu konfigurieren.

Regelmäßige Lasttests nach einem Deployment

Soweit so gut — aber noch nicht gut genug. Wäre es nicht super, wenn wir derartige Lasttests regelmäßig ausführen? Zum Beispiel nach jedem erfolgten Deployment unserer Anwendung in ein bestimmtes Deployment Environment — beispielsweise das Staging System? Auf diese Weise kann man verhindern, dass man ein System öffentlich macht, das zwar “ganz gut” aussieht, aber der zu erwartenden Last nicht gewachsen wäre.

Hierzu kann ich einen Task im Release Management einbinden, der einen Lasttest ausführt. Konfiguriert wird er nach dem gleichen Schema — einfach ein *.loadtest file im Release Management und den Pfad zum Ordner mit den Testbinaries angeben. Alle Ergebnisse der Testausführung finde ich dann — wie zu erwarten — unter dem Menüpunkt Loadtest in Visual Studio Team Services.

Wieviel Kontingent habe ich noch?

Wer wissen möchte, wieviel Freikontingent noch verfügbar ist, der findet diese Info auch im Azure Portal:

Hier noch ein paar Links, die den Einstieg erleichtern:

• Q&A zu Lasttests
• Genereller Übersicht in Last Tests und Visual Studio Team Servcies
• Lasttests mit VSTS
• VSTS Lasttests Tutorial
• Web App Performance Tests im Azure Portal

Frohes Lasttesten!

Lasttests in der Cloud mit Visual Studio Team Services was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

First, you might expect a more detailed display name which also names the edition (like Professional or Enterprise). Next, if you know the version numbers from the past you might expect to see a number starting like “15.x.y.z” instead of “1.x.y.z” — after all Visual Studio 2015 had version numbers starting with “14.x.y.z” so a simple increment seems obvious. Instead you see something like “1.x.y.z”.

It’s important to understand that the entry shown in the screenshot above relates to the installer of Visual Studio 2017 and not to Visual Studio 2017 itself. The installer of Visual Studio 2017 can typically be found in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer .

Why is that? You might have noticed already that the overall installation experience of Visual Studio has changed dramatically with Visual Studio 2017 allowing not only very slick and quick installations but also side-by-side instances of Visual Studio 2017 . (See also this post.) These new capabilities lead to described behavior.

In case you need to find out the version number of Visual Studio on a PC programmatically there are two ways recommended.

If you prefer to work with Powershell you can use the vssetup module found here (https://github.com/Microsoft/vssetup.powershell) which will return all the details of your current Visual Studio 2017 installation. The result will look like shown in the screenshot below.

As an alternative you can run vswhere.exe which can be found in the installation folder of Visual Studio Installer per default. If you can’t find it there, it can also installed manually, e.g. via chocolatey. More details can be found here. The result of vswhere.exe looks like shown below.

How to get Visual Studio 2017 version number and edition was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hint:

In case you don’t want to run step 1–4 and have Docker installed on your machine you can also just pull danielmeixner/yo-team-bash from https://hub.docker.com/r/danielmeixner/yo-team-bash/
However things might behave differently than described here — this is because in docker you’re command line only and you should set up your git credentials first. I’ll describe some of those specifics in another post.

• docker pull danielmeixner/yo-team-bash
• docker run -it danielmeixner/yo-team-bash

Step by step:

1. Install NodeJs.
   NodeJs provides the runtime required for Yeoman which is the basis for everything else.
2. I found the my old 6.x version didn’t work so I recommend using the latest version. On my machine v7.7.3 works like a charm.
3. You can download a NodeJs installer here.
4. Install Yeoman.
   Yeoman is a based on node so you install it using npm. If you want to know more about Yeoman check out the Yeoman website. It’s a fantastic tool so it’s worth a look. And by the way it’s open source.
   Open a commandline and run
5. npm install -g yo
6. Install the team generator.
7. Yeoman needs additional code generators to be able to generate stuff. In this step you install the required generator to be able to automate setup of CI/CD in VSTS. It’s called generator-team and it’s open source.
   Open a commandline and run
8. npm install -g generator-team
9. Install Git. [Optional|recommended]
   You might have Git already installed anyway. You don’t really need git for the setup, but it’s good to have it to do the first push into your repo. Also the automation tries to fire some Git commands. If you don’t have Git installed you might run into errors, however these are typically not completely stopping the show. I still recommend having Git installed. For this tutorial I supposed Git is installed.
   You can download Git here.
10. Install Visual Studio Code. [Optional]
11. You don’t really need Visual Studio Code, but I will use it in this tutorial. It’s works cross platform and is open source.
12. You can download the installer here.
13. Set up a free Team Services account
    here. If you already have an account, just use that one.
14. Set up an Azure trial subscription
    here. We’ll deploy to Azure so we don’t have to set up our own hosting in this tutorial. However you could also deploy to a Docker host, if you want. If you already have a subscription that’s fine as well.
15. Start Yo Team
    Trigger the yo team generator. Open a command line and type
16. yo team
17. Follow the wizard.
    Yo asks you for several inputs. I will explain what those inputs are based on a Java application running on Azure. The first thing you might see (only the first time) is this.

1. This only appears if you’re running yo for the first time. For our purposes it’s not relevant if you answer with Y or n.
2. Specify Account Name.
   Yo will ask you for an account name.

1. You can use the generator for work with Team Foundation Server. Specify the full URL then as shown. However in our case I consider you have a Visual Studio Team Services account. Then just specify the account name. You can find it in your URL. It’s basically the subdomain. In my case it’s “dmx”. So I respond with dmx.

1. Now I’m asked for my Personal Access Token.

1. A personal access token (PAT) is required for giving access to my Team Services account for the Yo tool. I have to create a PAT first. So I navigate to my Team Services account (in my case https://dmx.visualstudio.com) and mouse over my icon in the upper right corner and chose “Security”. A page opens where I can create a new PAT. Simply click “Add”, give the PAT a description and create a token. I choose “All scopes” to make sure Yo can do whatever it takes. You can invalidate our key right after we are finished. But first create it with “Create Token”.

1. You have to copy the token in the next dialog. There won’t be another chance so better copy it right now! It’s pretty long. Don’t show it to anybody and keep it safe like a password!

1. Provide this PAT as answer.
2. Configure Build Queue.
   Yo Team will use your PAT to figure out which agent queues are available to build your source code. I prefer to pick “Hosted” here. It certainly depends on what you already have set up, however Hosted should work under all circumstances. You can select using the arrow keys up and down and then just click return.

1. Appliation type
2. Yo Team will ask you what kind of application you want to set up. I’ll pick a Java app for this demo. Again, chose with the arrow keys.
3. Name of application
4. Next specify the name of the app. This will be used as Application name and also as name for the team project you’ll be creating in VSTS. You can use whatever you want. I recommend avoiding special characters.
5. I chose tmpMyYoJavaDemo03
6. Deployment Target
7. Yo Team will ask you where you want to deploy — to a Docker host or to Azure App Service? For this demo I don’t want to set up a Docker host but just be able to deploy. So I pick Azure.
8. Azure Subscription
   Yo Team asks me which subscription I want to use. Maybe you don’t have a choice here, maybe you’ll see several subscriptions. Just pick the one where you want to deploy to. I’ll go with my MSDN subscription here. If I would have chosen Docker I’d had different questions regarding my Docker host here.
9. Group ID
   Because we chose a JAVA app we also have to specify our GroupId. I just pick MyYoJavaDemoGroup here.
10. Install Dependencies?
    Next you’re being asked if you want to install dependencies. I prefer No here otherwise some dependencies will be downloaded on my machine. But I don’t need this, I just want to push the code later.
11. Magic starts now. All in all it looks like this and now the magic starts…

1. Credentials again?
2. You might be asked for credentials again and this might be confusing to you. This depends on how you’ve been working with Git already and how it’s been set up locally for you. It’s important to note that these credentials are credentials to access your Git repo on VSTS. So your default VSTS credentials might not work. If in doubt go to your VSTS account, open the security page again (as before) and set alternate authentication credentials for your account. Use these to login.

1. When asked for your username use the user name as specified (including @something.com) so e.g. your.name@live.com. You’ll be prompted for the password as well.
2. When everything worked as expected if you get a “Now all you have to do is push when ready” message.
3. If you’re used to Git, you can do the push by using the command line git commands. Or you open Visual Studio Code. First navigate to the brand-new directory containing code. In my case I do so by running
4. cd tmpMyYoJavaDemo03
5. Open Visual Studio Code in this folder by typing
6. code .
   Don’t forget the “.”, otherwise you can navigate to the folder manually in Visual Studio Code.

1. Now navigate to the Git panel in Visual Studio Code and select “Push to …” in the menu.

1. In the subsequent dialog choose “origin” as your target.

1. This will push the code to your VSTS account. You will find it in the “Code” tab of your account. It will also trigger a build and after the build it will deploy to your Azure subscription into a newly created Azure App Service.

A speedway to Continuous Integration and Continuous Deployment for Java, Node or .NET — Yo Team step by step was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why?

As developers we always need more performance. A faster CPU or more RAM or more space. Sometimes our physical machines just aren’t powerful enough. On the other hand I often hear from developers who are owning an MSDN license already that they don’t know what to do with the monthly Azure credits which come with MSDN.

Here’s my proposal: Even if your company doesn’t build a cloud service yet and even if you are not very experienced with cloud computing at all — why not set up a powerful developer Workstation in the cloud — it will cost you nothing! 56GB of RAM. 8 Cores. Or more? Sounds good?

If you are licensed with MSDN you get a certain amount of monthly credit you can spend on Azure workloads. If you don’t spend it, it’s gone. If you do spend it, you can use Azure until your credits are gone and then your Azure service just stops working. Per default there’s a spending limit of 0 which makes sure you don’t have to pay and stay within the free credits. So as long as you don’t explicitly delete this limit, you’re save.
You haven’t activated your Azure credit yet? Here’s a tutorial I wrote how to do this.

In case you don’t have an MSDN license — go ahead and start an Azure trial. You can then follow the same process as described below and can set up a powerful developer VM (However your budget is different and your trial will expire at some point in time). You can activate your Azure trial here.

This is an awesome opportunity to get your hands on new software like Visual Studio 2017 which is provided within a VM template already for you. If you like it you might consider trying out the software with your current project and code files. And if you really fancy the experience, this might become your number one developer workstation you connect to every day. In case this is something you’re looking into you should definitely check out our Azure Dev/Test labs as well which is our service offering for exactly this scenario with some additional features. But I think I will cover this in another post.

So here’s my step by step tutorial. If you already know how to set up a VM — go ahead, do it, this is the procedure described here. But make sure you switch on Auto-shutdown to save your credits during the times where you’re not using your machine (see steps below). This is important!

Control cost by shutting down

You might wonder if this makes any sense — a powerful VM on Azure doesn’t come for free and if you take a look at the cost of a really powerful VM it might be a multiple of your free Azure credits. The thing is that the estimated cost per VM which you see in the Azure portal is estimated on a 24/7 basis. This means the estimated cost you see here is a good indication — but based on your usage you can control cost. This makes perfect sense and for our scenario it means if you run the VM just for a few hours every workday you can reduce the cost to a level where you stay within the free Azure contingent. Of course — if you find you like what you see you always have the chance to exceed the limit after you disabled it or you also can scale up or down the machine you are using after creation.

If you want to save credits, don’t just shutdown the machine from within the machine but make sure you stop the machine from the Azure portal. (see below)

Step by step — set up a powerful Azure VM running Visual Studio 2017

1. Visit the Azure portal (http://portal.azure.com) and create a new VM. To do so, click the + on the left, then select “compute” and “see all”.

2. Search for Visual Studio, pick the template you want to use.

3. Click Create. A configuration blade will open. Provide the basic information like machine name, user, password, your Azure subscription and a resource group. A resource group is logical construct which holds some Azure resources (like the VM we are creating). You can pick any name to create a new one or use an existing.

When it comes to Location pick one which is close to you to avoid unnecessary latency.

4. Confirm this dialog at the bottom of the blade. No the fun starts. We can pick a size of the VM. This means we can configure stuff like RAM and cores. Pick “View all” to see more available configurations.

5. Go and find a configuration that should work for you. As said before — you can control actual cost of the VM by reducing unnecessary uptimes. A DS3 machine will offer you 8 cores and 56GB RAM. This is somewhat faster than my laptop. As said before — you can’t exceed the zero spending limit if you’re licensed via MSDN as long as you didn’t remove the limit manually.

6. Confirm your configuration and provide the necessary setting in the next blade. See a sample configuration below. The only thing where you really have to provide some values is the networking part. For all others you can keep the defaults. Provide an adresss space (e.g. 12.0.0.0/24) and a subnet address range (e.g. 12.0.0.0/24) and pick a name for your subnet.

7. Confirm you configuration. You will get a summary and your configuration will be validated. Click OK to start the deployment. In the portal a notification will show up.

8. In the notification era you will find information on how much credit is left as well. Here’s a sample screenshot from my credits. Thank got the month is almost over and I will get a new credit in a few days.

9. After a few minutes you’ll see the message that the deployment was successful. This means your machine is running.

10. Click the “Connect“ button to download an *.rdp file. Click the downloaded file to start an RDP session with your brand new machine.

11. Enter your credentials. Make sure you provide your name as machinename\username! In case your machine can’t be found it might still be booting. So give it another try in a few seconds.

12. As soon as you are connected you’re done. You have set up a virtual machine running Visual Studio 2017 — go ahead and start it, connect it with your account and your source code repositories in VSTS or on Github.

13. This last step is important: I recommend you configure auto-shutdown. Your VM will always be shut down automatically at a point in time you choose. Every day. This will save you some credits when you don’t need the machine.

15. If you want to start or stop the machine manually, do it from the Azure portal using this menu bar:

Check your spending limit

1. You may want to check if your spending limit is still active. You can do this by navigating to “Billing” in the portal. Then click “manage” in the upper menu.

2. This will forward you to the “old” Azure portal. You will see that whether you still have set the limit and you can deactivate the limit here.

Create an insane developer workstation in the cloud was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Warum das Ganze?

Der Grund ist recht einfach: Als Entwickler geht es nie schnell genug, wir könnten immer mehr RAM oder mehr CPU-Leistung vertragen. Auf der anderen Seite hat man als MSDN-lizensierter Entwickler ein monatliches kostenloses Azurekoningent — oftmals wissen wir nichts damit anzufangen.

Mein Vorschlag ist: Selbst wenn aktuell Cloudcomputing vielleicht für den ein oder anderen im Entwickleralltag noch kein Thema ist, kann ich als Entwickler von der Cloud profitieren. Ich setze mir also einfach eine High-End Entwicklerworkstation gehostet auf Azure auf. Und im Rahmen der MSDN Lizenz wird es mich absolut nichts kosten. 56GB RAM? 8 Kerne? Klingt gut, oder?

Mit einer MSDN Lizenz bekommt man monatlich ein bestimmtes Kontingent an Azure Guthaben, dass man für nahezu beliebige Workloads auf Azure ausgeben kann. Unter anderem kann ich damit virtuelle Maschinen erstellen. Standardmäßig ist es so eingestellt, dass — sollte ich das Kontingent ausgenutzt haben — mein Workload einfach nicht mehr funktioniert. Meine VM würde einfach abschalten oder mein Service nicht mehr funktionieren. Ich bin also auf der sicheren Seite. Falls Du Dein Azure Kontingent noch nicht aktiviert hast — hier steht wie das geht. Es ist ganz einfach.

Falls Du nicht im Besitz einer MSDN Lizenz bist, kannst Du Dir einen kostenlosen Testzugang zu Azure holen. Das kannst Du hier tun. Danach gilt dieses Tutorial auch für Dich.

Die Möglichkeit eine vorkonfigurierte Maschine auf Azure zu betreiben ist eine super Möglichkeit die neue Version auszuprobieren, damit zu spielen, den eigenen Code damit zu testen, Kompatibiliäten zu überprüfen — oder um damit richtig zu arbeiten. Wer Gefallen an der Vorstellung findet Entwicklermaschine auf Azure für sich oder sein Team zu hosten, der sollte sich die Azure Dev/Test Labs auch einmal näher ansehen. Darauf gehe ich jetzt nicht weiter ein, aber letztlich ist das unser Service, der genau dieses Szenario noch komfortabler macht.

Hier ist also meine Schritt-für-Schritt Anleitung. Wenn Du schon weißt, wie man eine Azure VM aufsetzt, dann kannst Du einfach loslegen — hier beschreibe ich nichts anderes. Stelle aber auf jeden Fall sicher, dass Du Auto-Shutdown aktivierst, um Dein Kontingent nicht unnötig zu belasten! (siehe unten)

Kosten sparen durch Shut Down

Vielleicht fragt man sich, was das soll — letztlich kostet eine VM auf Azure ja Geld und je stärker die Maschine, umso höher die Kosten. Die geschätzen Preise im Azure Portal pro Maschine übersteigen das Freikontingent im Rahmen der MSDN in der Regel. Allerdings beziehen diese sich auf einen Betrieb rund um die Uhr. Wenn wir also dafür sorgen, dass die VM nur läuft, wenn wir sie benötigen — z.B. ein paar Stunden jeden Werktag — , dann kommen wir mit dem Freikontingent doch schon recht weit. Man hat auch jederzeit die Möglichkeit nach der Erstellung noch die Maschinenleistung zu verändern — eindeutig ein Vorteil einer virtuellen Maschine gegenüber der Abhängigkeit von Hardware.

Kleiner Hinweis: Es ist nicht ausreichend, die Maschine einfach herunterzufahren, wie man seinen PC halt so herunterfährt. Um Kosten zu sparen muss man die Maschine entweder über den automatischen Azure Auto-Shutdown Mechanismus stoppen oder im Azure Portal stoppen. Weiter unten steht wie das geht.

Schritt für Schritt Anleitung: So erstellt man eine VM auf Azure mit Visual Studio 2017

1. Gehe auf das Azure Portal (http://portal.azure.com) und klicke + auf der linken Seite, dann “compute” und “see all”.

2. Suche nach Visual Studio, und wähle die Vorlage, die Du nutzen willst.

3. Klicke Create. Das öffnet eine weitere Ansicht zur Konfiguration. Hier gibst Du Username und Passwort an. Interessant ist die Resourcegroup. Das bezeichnet eine Art logischer Klammer um einzelne Azure Resourcen. Du kannst sie nennen wie Du willst. Beim Ort bietet es sich an, einen möglichst nahen Standort zu wählen, um Latenzen zu vermeiden.

4. Bestätige und wähle im nächsten Schritt die Größe der VM. Über “View All” siehst Du mehr Konfigurationen.

5. Du kannst hier wählen was Du willst — lass Dich nicht von den Preisen erschrecken. Da die Maschine nicht rund um die Uhr laufen soll, wird nicht der volle Betrag fällig — und die Kosten sind ja standartmäßig bei 0 Euro gedeckelt, so dass keine Kosten entstehen, nachdem Du Dein Freikontingent aufgebraucht hast. Im schlimmsten Fall ist Deine Maschine schneller abgeschaltet als Du möchtest.

6. Bestätige die Konfiguration. Im nächsten Schritt werden noch ein paar Einstellungen gemacht. Spannend ist nur die Netzwerkeinstellung, hier gibst Du Adressraum (z.B.. 12.0.0.0/24) und Subnetzkonfiguration und Namen an (e.g. 12.0.0.0/24).

7. Klicke OK. Auf der Zusammenfassung siehst Du nochmal Deine Konfiguration und kannst die Erstellung anstoßen. Das dauert ein paar Minuten. Folgende Meldung wird angezeigt:

8. Im Bereich der Benachrichtigungen findest du auch Info zu Deinem verbleibenden Azure Guthaben. Bei mir sind es noch gut 4€. Aber der Monat ist ja nicht mehr lang.

9. Nach ein paar Minuten bekommst du den Hinweis, dass die Maschine erstellt ist.

10. Über den “Connect” Knopf laden wir ein *.rdp File und verbinden uns per Remote Desktop zur VM.

11. Wir geben Username & Passwort an. Wichtig — der Username benötigt auch den Maschinennamen, z.B.: machinename\username Falls die Verbindung nicht zustande kommt, dann bootet die Maschine vielleicht gerade noch. Probier’s in ein paar Sekunden nochmal.

12. Sobald Du verbunden bist kannst Du loslegen. Verbinde VS2017 mit Deinem Account, lade Deine Projekte… Viel Vergnügen!

13. Diesen letzten Schritt darfst Du nicht vergessen! Konfiguriere auf jeden Fall Auto-Shutdown. Du kannst eine Zeit angeben, wann Deine VM automatisch heruntergefahren wird. Das spart einen Teil Deines monatlichen Freikontingents und Du kannst die VM länger nutzen.

15. Manuelles Stoppen geht über den “Stop” Knopf im Azure Portal.

Überprüfe Dein Ausgabenlimit

1. Wenn Du nicht sicher bist, ob Dein Ausgabenlimit auf 0€ noch existiert, dann kannst Du das überprüfen. Geh im Azure Portal auf “Billing” und wähle Deine Subscription. Klicke dann auf “Manage”. Die Ersteinstellung für MSDN lizensierte Nutzer ist mit Ausgabenlimit.

2. Das bringt Dich zur Übersicht auf der Du siehst, ob Dein Limit noch besteht.

(deutsch) Schritt für Schritt zum Entwicklerarbeitsplatz in der Cloud was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Visit http://my.visualstudio.com/benefits and log in.

2. Click “Activate” in the Azure tile to start the activation process to get your monthly credit.

3. The activation page will open. You have to accept the terms and then click to sign up.

4. The activation is running. Check your inbox for a mail which looks like this.

5. Click the link in the mail to navigate to your portal. Sign up if required. Click “Portal” in the upper right to get started.

6. You’ll get a notification on the credits you get monthly. The amount of credits depends on your license.

7. You’re done! Go and try out some of our services.

(english) Step by step — activate your free Azure monthly credit for your MSDN license was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Öffne http://my.visualstudio.com/benefits im Browser und logge Dich ein.

2. Auf der “Azure”-Fläche auf “aktivieren” klicken, um den Prozess zu starten.

3. Eine neue Seite öffnet sich. Hier die Vereinbarungen aktzeptieren und “Anmelden” klicken.

4. Die Aktivierung läuft. Nach ein paar Minuten sollte eine neue Email in Deinem Postfach sein, die ungefähr so aussieht.

5. Über den Link in der Mail kommt man auf eine Website — hier führt der blaue Button “Portal” oben links zum Azure Portal. Bei Bedarf einloggen.

6. Man erhält sofort eine Benachrichtigung, wie hoch das monatliche Guthaben ist. Der genaue Betrag hängt dabei von der jeweiligen MSDN-Lizenz ab.

(deutsch) Schritt für Schritt–so aktiviert man sein Azure Guthaben als MSDN-Abonnent was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s important to point out that the scenario described is technology-agnostic for the most part. It really doesn’t matter if your device is running Windows IoT Core (as chosen in my implementation) or any kind or Linux system or something totally different. The only part where this is important is the automated UI tests which clearly demonstrate the power of the Universal Windows Platform.

For this blogpost, I’ll concentrate on how our devices are being notified.

The challenges

In contrast to standard DevOps scenarios (something like a CI/CD chain for Web Development) — there are several challenges. Let’s stick with the “refrigerator control” scenario. If I want to program a software for a refrigerator and want to be able to update it after the refrigerator has been shipped, here’s a number of things I have to deal with:

• Access to Devices
• I won’t have physical access to the devices. So, I can’t plug in a USB stick and install new software. I also won’t be able to RDP into the devices.
• Connectivity
• I can’t even tell if the devices are online all the time. So, when I want to send a message, I have to make sure the message really arrives, even if the device is currently unplugged. For an IoT device of course I expect it to be online again at some point.
• Device Management
• I don’t have “System Center” or something similar to manage my device. My device might be pretty low powered and might not be supported by classic device management solutions at all.
• Scale
• I have to expect to have not only ten or 100 devices. If this was the case, you might think it is okay to do something manually. But in my refrigerator scenario I want to be able to ship millions of refrigerators. So, I have to deal with millions of devices. I need to be able to communicate and orchestrate this massive number of “things”.

Azure IoT Hub

The good news is, that for all of those topics there’s a solution out there which has been built to exactly address these. It’s called Azure IoT Hub. It’s here to allow devices to register, to report their state and to communicate bidirectionally between the hub and the device.

So the implemented flow is:

Whenever a device starts an app deployed on the device contacts IoT Hub and registers itself with a unique identifier. In my implementation, this is done by a custom app which could be delivered with the device initially (e.g. it might be burned into the OS image). If the device is already registered, that’s fine as well, the device will then just keep a connection open to IoT Hub. This guarantees that IoT Hub is able to talk to the device and vice versa. The protocols supported here are HTTP, AMQP and MQTP — and IoT Hub really doesn’t care what the device looks like as long as it is capable to “speak” those protocols.

It’s possible to report its state using Device Twins. This could be used to identify certain devices based on properties they are reporting. I didn’t do this in my scenario, it’s just something I want to point out because you probably would be using this to be able to cluster your devices later.

Whenever you want to send an information to the devices, you would use Azure IoT Hub as your communicator — basically this means we are telling Azure IoT Hub what message we want to transfer to the devices. We can decide what this message should look like content wise. All we need on the device is an app which is able to interpret this message. In my implementation, I already have an app on the device which was responsible for registering the device at IoT Hub. So, I just leverage this application to listen for incoming messages from IoT Hub as well. In my implementation, this is a background application which automatically starts on boot and always restarts itself in case it crashes. (See background applications for Windows 10 IoT Core) If you’re working with another operation system you’d just pick something similar for your OS.

In my case the message sent triggers a download of the new application from a FTP server and triggers the installation after the download. I picked this solution because a) it was easy to implement and b) is kind of general purpose. You could of course change the action depending on your specific scenario.

What is worth pointing out is, that Azure IoT Hub really takes all the pain from me, when it comes to the challenges addressed earlier.

• I don’t have to have physical access — my device registers itself with IoT Hub and I’m able to talk to it afterwards.
• I don’t have to care about connectivity of my device — Azure IoT Hub makes sure messages arrive even if the device is offline while the message is being triggered (similar to sending an SMS via mobile phone).
• I don’t have to set up any kind of homegrown device management — because this is exactly what Azure IoT Hub does for me.
• I really don’t have to worry about scale, because Azure IoT Hub is built for scale — it supports up to 10.000.000 devices per Azure IoT Hub instance. This is amazing — imagine all of those devices are sending messages in short intervals — Azure IoT Hub is capable of receiving them because this is what it’s been created for.
• The best thing is that you can get started with Azure IoT Hub in literally 5 minutes — you just spin up an instance in your Azure portal.

Talking to Azure IoT Hub from VSTS

Now that we know how to communicate with our devices it’s really just a question of how to trigger the communication during our End-To-End CI/CD chain based on Visual Studio Team Services (VSTS). In this case I created a release definition which just triggers a node.js script which again is responsible to send a message to all devices.

The script is based on the sample script for cloud to device messaging and can be found here. (I’ll go into details on how to setup everything in a future post where I will also point out all downloads again.)

What the script basically does is it queries all devices registered at my IoT Hub instance and then ask IoT Hub to send a message to all of these sequentially. (In my case the message just says “Cloud to device message from VSO” to keep things simple. Of course, I could add Ids, version numbers etc. and based on the information I could react differently on the device after receiving. For my end-to-end show case, I’m just triggering an installation, no matter what message is coming in.

Working with IoT Hub really took the pain from communicating to a wide range of devices. It’s easy to get started with and scales for extensive use in the future. So, it’s a very crucial component when automating communication to IoT devices. I don’t even want to think about building something similar myself because I’d have to bring tons of budget and time to realize this. Azure IoT Hub also works when connecting devices behind firewalls because the connection is always established outgoing — from device to IoT Hub. It should be easily possible to set up the communication whatever the network infrastructure looks like.

Besides this I think it’s pretty amazing that I’m able to run npm and node during deployments on a hosted (!) VSTS release agent. This makes leveraging existing scripts really easy and in my case saved a lot of work.

Let me know in the comments section if you have feedback for this scenario.

DevOps for IoT (Part 3 — Talking to Azure IoT Hub from VSTS) was originally published in DevelopersDevelopersDevelopersDevelopers on Medium, where people are continuing the conversation by highlighting and responding to this story.