OpenHacking away

Last week I coached a team during a 3-day OpenHack. The team members were new to DevOps but they had incredible energy and we all learned quite a bit. 

We used GitHub and Azure DevOps to create a blue/green deployment pipeline for a few APIs. Put some branch protection on Trunk including a pull request build / tests pipeline. We also used Azure Boards and GitHub issues to track work and bugs.

Good times.  ūüôā

Azure App Configuration service

The other day I was asked if it’s possible to put objects, arrays, etc as the value for a configuration variable. Hm… Good question.

Figured, how about JSON to the rescue? And it worked.

I created a simple .NET Core console app that reads a JSON string from Azure App Configuration service and parses the JSON into an int array.

In App Configuration service…

  • The Key name is: foo

  • The json string looks like this: {“value” : [0,1,2,3,4]}

  • I set the Content type to JSON, but that isn’t required.

The output from the program is:
this is a test: {"value" : [0,1,2,3,4]}
element is: 0
element is: 1
element is: 2
element is: 3
element is: 4

The sample program is located in my GitHub repo here.

Here are a couple of handy references:

Enjoy!

New domain name servers

I just now created a DNS Zone in the Azure portal to take care of Snowstormlife.com. Then I copied the name servers from Azure and updated the ones in GoDaddy. Didn’t take long at all.

Grabbed the name servers in the Azure Portal
image

And updated the ones on GoDaddy…
SNAGHTML1f5371b8

A new domain. . .

I mapped my old domain name snowstormlife.com to the app service plan. So there’s another item for the TODO list once I get external storage set up:

– [] Copy all the blog posts from jimblizzard.wordpress.com over to snowstormlife.com.

Baby steps on the journey . . .

The site in it’s brand-new-baby form is alive and running in a Linux container-backed Azure website here. Again, just getting started with it, so nothing fancy at this point. I’ve learned a ton of stuff just getting this far — not just following some hands-on lab or quickstart tutorial, but having to look things up and try things out. Lots to blog about. I’ve been keeping a blog for forever on WordPress, but I’m going to use the new site to blog about this process.

Also, I used the Azure Portal’s DevOps Project feature to create the site with a docker container backing it, Azure Container Registry, an Azure DevOps CI/CD pipeline linked to this GitHub repo, etc. It took only 5 minutes to stand it up by answering 5 simple questions. (I’ll eventually put the blog in a Azure Kubernetes Service cluster, but I have a bit more learning / work to do so I don’t leave it hackable. ūüôā

Update 2020.05.11 – I’m not going to keep snowstormlife.cloud. I’m too cheap to pay that much every year. ūüôā I’ve decided to revive my old domain name snowstormlife.com. I also bought a custom domain name, Snowstormlife.cloud, where it lives. Current next steps are to create external storage for the blog so it doesn’t get blown away with each new container deployment. It’s currently using storage within the container, which isn’t good. As in, when I commit this change to master and the CI/CD pipeline runs, it’s going to blow away the container and anything I’ve posted on the site. ūüôā And I need to add an SSL cert to the site so it can do https…..

The beginning of my journey to take a dotnet core app and stuff it into AKS. Properly.

The App is based on MiniBlog.Core by Mads Kristensen

The ultimate goal is to

  1. Run Miniblog.Core safely and securely in AKS. (All proper network / security / healt checks / secrets management / yada yada yada) in place.
  2. Deploy updates to the engine in AKS through GitHub CI/CD pipelines, which will include container scans, etc., using blue/green pattern.
  3. The Docker image will be stored in the Azure Container Registry.
  4. And other things. . .

For now I’ll document my efforts along the way here in the MD file. Once I get the engine up & running in AKS I’ll start documenting things there.

prerequisites

I’m running Ubuntu in WSL (Windows Subsystem for Linux) on Windows 10. https://docs.microsoft.com/en-us/windows/wsl/install-win10

I also have Docker Desktop. It includes the Docker Engine, CLI client, Kubernetes, etc.

And I’m using Linux containers, not Windows Containers.

the app

I cloned the Miniblog.Core repo from https://github.com/madskristensen/Miniblog.Core.git

Snippets in VS Code

I just discovered how to create snippets for VS Code. All this time I’ve been living without them. Why didn’t I look into this before? I don’t know.

To create / edit snippets, in VS Code, press Ctrl+Shift+p then type “snip”

To edit your snippets, select Preferences: Configure User Snippets, then select the snippets file or create snippets

In WSL Ubuntu, my c# snippet config file is located here: /home/jim/csharp.json

Here’s an example of a couple that I created:

{

    // Place your snippets for csharp here. Each snippet is defined under a snippet name and has a prefix, body and 

    // description. The prefix is what is used to trigger the snippet and the body will be expanded and inserted. Possible variables are:

    // $1, $2 for tab stops, $0 for the final cursor position, and ${1:label}, ${2:another} for placeholders. Placeholders with the 

    // same ids are connected.

    // Example:

¬†¬†¬†¬†//¬†“Print¬†to¬†console”:¬†{

¬†¬†¬†¬†//¬†¬†“prefix”:¬†“log”,

¬†¬†¬†¬†//¬†¬†“body”:¬†[

¬†¬†¬†¬†//¬†¬†¬†¬†¬†¬†“console.log(‘$1’);”,

¬†¬†¬†¬†//¬†¬†¬†¬†¬†¬†“$2”

    //  ],

¬†¬†¬†¬†//¬†¬†“description”:¬†“Log¬†output¬†to¬†console”

    // }

¬†¬†¬†¬†“Property”:¬†{

¬†¬†¬†¬†¬†¬†¬†¬†“prefix”:¬†“prop”,

¬†¬†¬†¬†¬†¬†¬†¬†“body”:¬†[

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“public¬†${1:type}¬†${2:MyProperty}¬†{get;¬†set;}”

        ],

¬†¬†¬†¬†¬†¬†¬†¬†“description”:¬†“Create¬†a¬†property¬†with¬†‘private¬†type¬†varName¬†{get;set;}'”

    }

¬†¬†¬†¬†“PropertyFull”:¬†{

¬†¬†¬†¬†¬†¬†¬†¬†“prefix”:¬†“propfull”,

¬†¬†¬†¬†¬†¬†¬†¬†“body”:¬†[

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“private¬†${1:type}¬†${2:myVar};”,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“”,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“public¬†$1¬†${3:MyProperty}”,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“{“,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†”¬†¬†¬†get¬†{¬†return¬†$2;¬†}”,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†”¬†¬†¬†set¬†{¬†$2¬†=¬†value;¬†}”,

¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†¬†“}”

        ],

¬†¬†¬†¬†¬†¬†¬†¬†“description”:¬†“Full¬†property¬†with¬†private¬†backing”

    }

}

After you save the file, in the VS Code editor for your C# project, simply type the snippet prefix, such as “prop” or “propfull” then press tab and fill in the values

 

Snippets are such handy things…..

 

There are a bunch of topic-specific config files available for use, too. For more info, see: https://code.visualstudio.com/docs/editor/userdefinedsnippets

 

Enjoy!

 

And don’t forget to wash your hands.

 

.

 

Unit testing your JavaScript code

I delivered a Test Driven Development workshop for a client last week in Ohio. It was a fun workshop, but man, the weather was brutal. The low the other night was below zero. The highs never made it above freezing while I was there. Brrrr.

Anyway, during the workshop we worked through TDD examples in C#, for the most part using MSTest, and leveraging the Microsoft Fakes framework in Visual Studio 2017. (See https://msdn.microsoft.com/en-us/library/hh549175.aspx.)

In addition to C# they also have a lot of JavaScript code, so I demonstrated how they could write unit tests in JavaScript to test their JavaScript code, leveraging Karma, Jasmine, and Chutzpah. The unit tests show up in Test Explorer, just like unit tests written in C# do. And setting things up isn’t very difficult and can be completed in just a few minutes.

So let’s take a look at how you can do it in your environment while we start to create a JavaScript library that calculates the score of a bowling game.

First some prerequisites

If you’re using Visual Studio 2017, node.js is probably already installed. If not, you can download it from here: https://nodejs.org/en.

Download and install the Chutzpah .vsix packages. Use the Visual Studio¬†Tools menu > Extensions and updates… then search for chutzpah as shown below. (More info about Chutzpah here:¬†https://marketplace.visualstudio.com/items?itemName=vs-publisher-2795.ChutzpahTestAdapterfortheTestExplorer.)

Chutzpah

Also download and install the Jasmine Snippet Pack from the Extensions and updates… menu option. ¬†(More info about Jasmine Snippets ¬†here:¬†https://msdn.microsoft.com/en-us/library/hh549175.aspx.)

jasmine

Now let’s create a place to hold our ¬†JavaScript library (the starting point of the system under test)

To give us a place for our JavaScript library, create a new empty MVC project / solution. (File > New > Project… then choose ¬†Web > ASP.NET Web Application (.NET Framework) template, and name it BowlingGameJS. Here are a couple of screenshots . . .

BGJS1.png

After you click OK, in the next dialog box, choose the Empty project template, then click OK.

BGJS2.png

Now open a command prompt to your BowlingGameJS project’s folder and run the npm init command. Take all the defaults by pressing enter for each question. This will create a package.json file in your project folder. (Notice that you need to use lower case for the name: option.)

bgjs3.png

Switch back to Visual Studio and add package.json to your project. Right click on the project name > Add > Existing Item… > package.json, then click the Add button.

bgjs4

You should now see package.json in Solution Explorer.

bgjs5

Now that package.json is in your project, let’s open and configure it a bit more. We’ll update it to add package depenencies for karma, jasmine, and other necessary packages. We need to put these changes in the devDependencies section. As you’re typing, IntelliSense should pop up the latest version of each of the packages. The image shows the versions available as of this writing.

bgjs7

Also in package.json, change the “scripts” element to point to karma. It should look like this when you’re done. . .

bgjs8

Save package.json, then right click on it and choose Restore Packages. This should pull down the additional packages you added in package.json, but when I’ve tried this recently it hasn’t done anything.

To see if it did download the packages, open Windows Explorer to your solution’s project directory and see if the .\node_modeules directory has anything in it. If it does, cool. If it doesn’t, open a command prompt to your solution’s project directory and run npm install to install the node packages manually. It will take a couple of minutes for this to finish. (For more info, see:¬†https://www.digitalocean.com/community/questions/after-running-npm-install-installs-with-no-errors-node_modules-is-empty).

Now with your command prompt open to your project’s directory run this command:

.\node_modules\.bin\karma init karma.conf.js

Answer the promps as follows. (Press enter to take the default, or tab to a new value as needed.

  • Which testing framework? jasmine
  • Do you want to use Require.js? no
  • DO you want to capture any browsers automatically? [press tab until you see PhantomJS]
  • What is the location of your source and test files? [leave empty for now. We’ll update it in a bit]
  • Should any of the files included by the previous patterns be excluded? [leave blank]
  • Do you want karma to watch all the files and run the tests on change? yes

Now add the karma.conf.js file to your project. (In Visual Studio, right click on the project name, and choose Add > Existing Item… and select karma.conf.js

Time to write some code?

Well, almost. Before we do, we still need to tell the tools where to find the class library and the tests you’re creating.

In Visual Studio, right click on the project name and choose Add > New Folder and name the folder Scripts. We’re going to put our library code here.

Do the same for our tests: Add > New Folder and name the folder Specs.

Now we need to update the karma configuration file to point to the Scripts and Specs folders. So in karma.conf.js, add the following

// list of files / patterns to load in the browser
files: [
¬† ¬† ‘Specs/*.js’
¬† ¬† ‘Scripts/*.js’
],

We also need to add a couple more reporters

// available reports: https://npmjs.org/browse/keyword/karma-reporter
reporters: [‘progress’, ‘dots’, ‘htmlDetailed’, ‘mocha’],

Tell karma about the available plugins

// notify karma of the available plugins
plugins: [
¬† ¬†‘karma-jasmine’,
¬† ¬†‘karma-ktml-detailed-reporter’,
¬† ¬†‘karma-mocha-reporter’,
¬† ¬†‘karma-chrome-launcher’,
¬† ¬†‘karma-phantomjs-launcher’,
¬† ¬†‘karma-coverage’
],

Tell karma to put all the results into one file

// configure the HTML-detailed-reporter to put all results in one file
htmlDetailed: {
   splitResults: false
},

Time for some jasmine

Now let’s add the jasmine NuGet package to our project. In VS, right click on your project name and select Manage NuGet packages…

Under the Browse tab, search for jasmine, then tell the package manager to install jasmine. NuGet will add a jasmine folder in your Scripts folder.

bgjs9

Now it’s time to write some code!

Let’s create the jasmine test spec file for our bowling game calculator and the file for the bowling score calculator itself. First the test spec since we’re doing test driven development.

In Visual Studio, right click on the Specs folder > Add > JavaScript File and name it BowlingGameTests. (Visual Studio will add the .js extension for you.)

Testing 1, 2, 3. . .

Our first test is going to be a simple one. Let’s test to see if it can correctly calculate the score if someone rolls all zeros. Open BowlingGameTests.js and write the test spec as follows:

/// <reference path=”..\Scripts/jasmine/jasmine.js” />
/// <reference path=”..\Scripts/BowlingGame.js” />
describe(‘the bowling game’, function() {
¬† ¬†it(‘correctly calculates gutter game’, function () {
       // roll 20 zeros
       for (i = 0; i < 20; i++) {
           roll(0);
       }
   var result = score();
   expect(result).toBe(0);
});

When you save the file you should see the test appear in the Test Explorer window.

bgjs10

If you don’t see the Test Explorer window, the easiest way to open it is to type test explorer in the Quick Launch box near the upper right of the Visual Studio UI. Then click on the Test > Windows > Test Explorer (Ctrl+E, T) item in the dropdown list.

bgjs11

Run the test by clicking on the Run All command in Test Explorer.

bgjs12

Since we haven’t started writing our system under test yet, the test is going to fail.

bgjs13.png

Developing 1, 2, 3. . .

So let’s fix that. Let’s write enough code in our system under test to satisfy the test.

Right click on the Scripts folder > Add > JavaScript File. Name the file BowlingGame (VS will add the .js extension for you). Open the BowlingGame.js file and type the following code. (Don’t laugh at the code. Remember, we’re taking this a step at a time when we do TDD.)

// BowlingGame.js
(function (window) {
    function roll(pins) {
        return;
    };

    function score() {
        return 0;
    };

    window.roll = roll;
    window.score = score;
})(window);

Save BowlingGame.js, then click Run All in Test Explorer. The test should run and complete successfully. Yay!

bgjs14

Your JavaScript test environment should be working now. Congratulations!

So let’s add another test, this time to calculate the score of a game that has one pin knocked down on every roll. It’s the same drill as before: we first write a new test spec, run the test, then write the code to satisfy the test.

In the test spec file (BowlingGameTests.js), add this code after the closing }); for the existing it method.  After you save your changes you should see the new test appear in Test Explorer. Run the test by clicking Run All.

it(‘correctly calculates all ones game’, function () {
      // roll 20 ones
      for (i = 0; i < 20; i++) {
           roll(1);
      }
      var result = score();
      expect(result).toBe(20);
});

The test will fail because we still return a hard-coded value for the score() function.

Let’s update the system under test then run the test again. Here’s a simple change that will satisfy both tests:

bgjs16

Here’s the current state of our BowlingGameTests.js file:

bgjs17

This is just the beginning

At this point you would continue writing tests with different criteria, such as a simple one that starts out with a spare then a one then the remainder all zeros; and then a test that starts with a strike then two ones then the remainder all zeros. With each new test you’ll write just enough library code to satisfy the test, making sure you don’t break any existing tests as you work. At some point you’ll also want to refactor your code (both the test specs and the system under test) to keep it maintainable.

Remember the TDD manrtra: Red, Green, Refactor.

There are other ways to write your JavaScript code, engines you could use to run tests against your code. But however you go about it, the bottom line is: unit test your code. Try edge cases. Write tests to make sure you’re satisfying the business requirements.

And have fun.

 

 

 

 

 

Android Keystore file and password in VSTS builds

I was on site with a client last week working with them on DevOps for Xamarin.Forms builds using VSTS. The question came up of what to do about the Android Keystore file and its password ‚Äď where to put them, keep them safe, etc.

Keystore file
If you’re running the build agent on a local build server (or Azure VM), the keystore file can be placed in a secure location on the build server. If you’re using the hosted build controller the Keystore file could be put into source control with limited access given to that file.

Keystore file password
For the Keystore file password, create a private variable in the Android build definition . Once the variable is set it cannot be displayed again. Then set the permissions in VSTS so only those who have Build Edit permissions can change this variable, and restrict who you give those permissions to accordingly.

clip_image001
The build step with a reference to the Keystore file in VSTS source control and a variable for the password.

image
The Keystore password saved as a Variable in the build definition.

Then you’ll need to set the security on the Build itself to limit who is allowed to edit the build definition.

image

image

And that’s it. Setting up the VSTS build in this way will keep the Keystore file and password safe in your Xamarin Android build definitions.

Enjoy!
–bliz