Tuesday, January 20, 2015

Using a on-premises / Azure VM server for Visual Studio Online builds

We're running low on CI build minutes, actually, I spent the 60 minutes in 1 day. So I'm setting up a build controller on an on-prem VM. Turns out it's a breeze to hook the build controller up to the Visual Studio Online account. Check out this post by Anthony Borton on how it's done.




HP DL380 G5 with ESXI 5.1 - processor options

So I took my 5th generation HP DL380 to my new job and because of the static IPs I had assigned to the ILO interface and ESXI, I couldn't get anything done anymore. So I removed the battery from the main board which did a nice reset of the ilo inerface but also reset the BIOS processor options. Thanks to the VMWare forum I found the options I had to configure to run ESXI on the box:

https://communities.vmware.com/message/2388160



If you forget the no-execute memory protection, you'll get purple error message. Below is how to solve these BIOS issues.

http://blog.vmpros.nl/2012/09/17/vmware-esxi-requires-the-execute-disableno-execute-cpu-feature-to-be-enabled/


Saturday, January 17, 2015

Console Application argument parsing: solved

I'm working on a codebase which has a lot of console applications and has several lines of code to deal with parsing the command line arguments. Well ... that can be removed since I found this little friend on NuGet: https://www.nuget.org/packages/CommandLineParser/


First of all - I can remove all the command line argument parsing code and just use the code demonstrated below.
Second of all - with 3 lines of code, a --help will be implemented showing you all the possible options for the command line tools.



Friday, January 16, 2015

Playing with JSON Schema

All the new ( 'vNext' ) stuff coming from Microsoft seems to be using JSON configuration files and less XML configuration. Today I was looking into my Azure Scheduled Job configuration and saw this:

{
  "$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
  "webJobName": "myjob-dev",
  "startTime": "2015-01-15T00:00:00+01:00",
  "endTime": "2015-01-16T00:00:00+01:00",
  "jobRecurrenceFrequency": "Day",
  "interval": 1,
  "runMode": "Scheduled"
}

Following the link to the JSON schema file shows you what it looks like:

{
 "title": "JSON schema for Azure Webjobs configuration files",
 "$schema": "http://json-schema.org/draft-04/schema#",

 "type": "object",
 "required": [ "runMode" ],

 "definitions": {
  "shared": {
   "properties": {
    "webJobName": {
     "type": "string",
     "description": "The name of the Azure Webjob."
    },
    "startTime": {
     "type": "string",
     "format": "date-time",
     "description": "The start time of a scheduled job. Example. 2014-06-11T00:00:00-08:00"
    },
    "endTime": {
     "type": "string",
     "format": "date-time",
     "description": "The end time of a scheduled job. Example. 2014-06-12T00:00:00-08:00"
    },
    "jobRecurrenceFrequency": {
     "type": "string",
     "enum": [ "Second", "Minute", "Hour", "Day", "Week", "Month" ],
     "description": "The frequency metric used with the 'interval' property."
    },
    "interval": {
     "type": "integer",
     "description": "The interval of how often the Azure Webjob should run. Use it with the 'intervalType' property."
    }
   }
  },
  "scheduled": {
   "required": [ "webJobName", "startTime", "endTime", "jobRecurrenceFrequency", "interval" ],
   "allOf": [ { "$ref": "#/definitions/shared" } ],
   "properties": {
    "runMode": {
     "type": "string",
     "enum": [ "Scheduled" ],
     "description": "Determines the run mode of the Azure Webjob. \n\n Triggered: manually triggered \n Scheduled: runs on a specific schedule \n Continuous: runs all the time"
    }
   }
  },
  "notScheduled": {
   "required": [ "runMode" ],
   "allOf": [ { "$ref": "#/definitions/shared" } ],
   "properties": {
    "runMode": {
     "type": "string",
     "enum": [ "Continuous", "OnDemand" ],
     "description": "Determines the run mode of the Azure Webjob. \n\n Triggered: manually triggered \n Scheduled: runs on a specific schedule \n Continuous: runs all the time"
    }
   }
  }
 },

 "oneOf": [
  { "$ref": "#/definitions/scheduled" },
  { "$ref": "#/definitions/notScheduled" }
 ]
}

So - JSON Schema for JSON is what XSD is for XML: you define a schema in which you define what information must or can be present inside an element.

I have to say I'm not sure what my position is on this. I'm a strong believer in 'the right tool for the job'. So if you want to write a textfile with information but want to enforce a schema - shouldn't you just use XML? XML with an XSD solved this problem.
You want to send data back and forth between a webserver and a client, without a lot of hassle and overhead and which works great with JavaScript ? Use JSON. JavaScript lets you get away with everything - so does JSON.

Don't get me wrong - I like all the developments in software and this surely adds to something. JSON configuration files wouldn't be possible in a product like Visual Studio if not for a schema. But one should not be affraid of it's dynamic nature and therefore make everything strongly typed. Embrace the dynamic nature of JavaScript and JSON or pick a different tool IMHO.

Anyway - I played around with it a bit and here are some interesting resources:

So here's my attempt at a schema:


{
   "definitions":{
      "car":{
         "title":"Car schema",
         "type":"object",
         "properties":{
            "make":{
               "description":"The manufacturer of the car",
               "type":"string"
            },
            "model":{
               "description":"The model of the car",
               "type":"string"
            }
         },
         "required":[ "make", "model" ]
      },
      "person":{
         "title":"Person schema",
         "type":"object",
         "properties":{
            "firstName":{
               "description":"The firstname of the person",
               "type":"string"
            },
            "lastName":{
               "description":"The family name of the person",
               "type":"string"
            },
            "cars":{
             "type" : "array",
             "items" : [ { "$ref":"#\/definitions\/car" } ]               
            }
         },
         "required":[
            "firstName",
            "lastName",
            "cars"
         ]
      }
   },
   "$ref":"#\/definitions\/person"
}

Which validates this JSON:


{
 "firstName" : "John",
 "lastName" : "Doe",
 "cars" : [
 { "make" : "Ford", "model" : "T" },
 { "make" : "Ford", "model" : "Galaxy" }
 ]
}


Note the $ref thing - makes everything nice and structured. Other than that it's all pretty straight forward.

We're going to see a whole lot more of JSON schema in the future I think - so you might as well read up on it!



Thursday, January 15, 2015

Visual Studio ALM Rangers: get your branching strategy right

We've moved source control over to TFS Online with GIT as the version control system. This is a good way to re-think our branching strategy. I was looking for some resources on the internet, because I think I want to move over to GitFlow but I need to read up on the pros and cons.

So if you don't know what GitFlow is - here's a great explanation: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow.

Then I found this CodePlex site that offers several guide for Application LifeCycle Management (ALM) on TFS. Check it out here: http://vsarbranchingguide.codeplex.com/ - go to the downloads page and find the PDF guide.





Saturday, December 6, 2014

Testing your application with Microsoft Test Manager: a quick howto

We're rushing a bit towards the end of the year at work and since we're a multi-disciplinary team ( very Agile ;) ), and so I'm contributing by testing some WCF service a colleague created. So I dusted off MS Test Manager again and found that I still like it very much. Three arguments:

  1. Since you plan out your test before, it forces you to think about the tests. I know there's exploratory testing too, but here I used planned testing.
  2. Tests can easily be reproduced to re-test the bugfix, by anyone
  3. Creating a bug report from test manager is SO powerful. It gives such detailed information about the steps that lead to the bug. The dev knows exactly what happened up until the point that the system failed.

So let me take you through a quick tour of MS Test Manager and how to get started with testing.

Assuming you have a project in TFS, open up Test Manager and select the project. If you don't have a project, create one in TFS. I'm using TFS online for this demo.


Create a testplan. I saw that the testers at work had plans like 'Regression tests system-a', 'Tests for sprint 32 system a', so that's the kind of scopes you need to think of.


After selecting the plan, the Test Manager screen opens and you see the test plans. There's nothing in my case, since I just created the test plan.


So since I'm going to be brief here, I just want to focus on these two main buttons at the top, the 'Plan'  and 'Test' buttons. Let's start by writing a testplan, by hitting the 'New' button:


So I noticed yesterday as well that the first steps were 'shared steps' often. Some of the tests start with these steps, so it makes sense to make them shared. They're like [TestInitialize] if you're used to writing unit tests.

So I created a shared step 'Open browser and navigate to google calculator'


Double click it and you get to define the sub-steps for this shared step:


Be sure to fill out the 'Expected result' column. Especially for proper testing steps of course. Save and close this screen and return to the original plan.

 
Here are the finished steps of my test. Now let's save an close this screen and return to the home screen.

As you can see, the test is now planned. So now we go over to the Test side of Testing Center:


OK - so we see that our test is present in the Test area, let's go ahead and run it:


What you should see is that the Test Runner window will go on the left of your screen and show you the steps to do for testing, which you can do in the rest of the screen:


Clicking the 'Create action recording' checkbox makes a video from you running the test. Let's just hit Start Test:


On the top left there's controls that allow you to pause / stop the tests you're running. In case something comes up during the testing. 

The triangle lets you expand the shared steps and shows the sub-steps of the 'Start browser and navigate to Google calculator' shared step.

At the right of each step you have the option to pass/fail a test.
Right-clicking on the test lets you add comments. Be sure to utilize taking screenshots, they are added to the test results quickly:



And now for the cool stuff: let's create a bug for the dev team. That's the button on the top right, left of the screenshot tool. It opens the new bug window:


It creates a bug with all the test steps, screenshots, expected results, comments etc. Coming from an organisation where bugs came in with information like 'login doesn't work', I'm very very happy with descriptions like this.


De developers that typically aren't in test manager, can see the reproduction steps and open the test case by clicking either 'Test case' on the left, or click 'Links' on the right and see both the testcase ( will show in TFS ) or the test result ( will open in Test Manager ).

Tip: If you want to add this bug to an existing backlog item, you want to add a link to a parent item, and select the backlog item there.


Going back to test manager, where I stopped, saved and closed the test, you can see that one testrun has failed. If the dev now fixes the issue, the tester just re-runs this test and if all is well, passes the test.