Desired State Configuration (DSC) is a new management platform in Windows PowerShell that enables deploying and managing configuration data for software services and managing the environment in which these services run. During this video, we’ll see why Powershell DSC is a great feature that helps us a lot Dev/Testing with Microsoft Azure.

When trying to setup an environment, things like:

• a local account
• a special service
• a process
• a configuration in IIS
• etc.

take time and may be the source of many mistakes.

With PowerShell Desired State Configuration (DSC), creating dev / test / staging environments has never been easier. You can now specify how the VMs should “look like”, and establish their desired state (state that the VMs will be able to reach automatically).

“PowerShell DSC is a great mechanism to specify prerequisites on VMs, and also to make sure VMs are created in an identical manner, every time we need to deploy into the same type of environment.”

This is the forth video in the Dev/Test series. We recommend you also watch the previous videos:

• Part I: Discover the core benefits of Dev and Test with Azure
• Part II: How VSTS Integrates with Microsoft Azure in Dev/Test Scenarios
• Part III: Dev/Test with Azure Resource Manager

In the previous videos we’ve seen how we can create environments for Dev, QA or Staging purposes in Azure. Most of the time, in order to deploy a solution in such environments, we need specific prerequisites to be installed on the Virtual Machines.

A continuous integration process may look like this —

You have your source code (say in Visual Studio), source code that is maybe checked into TFS or VSO. And you want to deploy a new version into a specific environment (dev/test/staging etc.). The steps you need to follow are the classical continuous integration steps from VSTS: build, release and so on.

After the environment has been created in Azure, which is actually an Azure resource group, you have to deploy your solution on that environment.

Let’s zoom in a bit to see how Powershell DSC can help us a lot in these scenarios.

When you deploy your solution, you already have created and configured the Virtual Machines, load balancers, storage accounts – whatever the solution needs. All these should already be created as components in Microsoft Azure. The actual solution deployment (before you actually deploy the bits and the resources that compose your solution), you need to install and configure some pre-requisites on the VMs which are running the solutions. Such as a Web server, a local account, a Windows service, load other components and other required configurations.

Those prerequisites can become a challenge sometimes. Because you have to make sure that those prerequisites must be installed every time identically you make a new deployment in test / staging / production environments. This is the challenge: how do you make sure all those prerequisites are reused every time, in between environments or in between versions of the solution into the same environment.

I would say, a particular case, would be to make sure when you move from staging to production, when you have concluded that – Yes, this version has been tested and can be moved to Production – why not here be able to reuse the same pre-requisites.

Powershell DSC is a set of technologies which have been designed exactly for that. You are able to specify how the VM should look like, the desired state of those VMs. There are 2 mechanisms to make sure the VMs have the desired state:
VM PUSH – you simply push the specification (the DSC) on to the VM and all the differences will be applied;
VM PULL – the VM will check its’ state against a desired state specified somewhere from time to time and will be able to refresh its state.

The most important thing here is that using Powershell DSC you’re able to specify how it should look like. It’s not a procedural language where you say – install this, configure that and so on and so forth – it’s a state that you define which makes us be certain of the fact that this state will be exactly how it’s described (we’re not going to miss anything, we’re not going to install something by mistake etc). Having the DSC we will be able to use the DSC configuration throughout deployments or different mediums.

If you want the dev environment to be identical with the test environment, you simply reuse the same DSC. If you want the staging environment to be identical with the production environment, again, you reuse that specific DSC. By the way, this is a big challenge – whenever you want to promote your solution to production, which let’s say, it’s on a client’s environment, it’s always a very hard thing to do. Because you don’t have access to your customer’s infrastructure all the time, probably you’re not allowed to play with it, and what we end up doing as software developers or software companies before actually launching into production a new version of the solution, we try to replicate the production environment into a staging environment in our own infrastructure / own Azure account for example. And trying to replicate an existing production environment is not always the best case, because you might miss something. There are a lot of configurations. So testing in a replicated environment will not be perfect, because of the differences of the two environments.

With the help of Powershell DSC you’re able to easily switch tables: you’re able to actually say this is how the environment should look like, this is my staging environment where we tested the solution and, dear customer, together with the solution that we’re providing you here is a set of DSC files which will bring your environment into the desired state. Thus allowing the customer to be able to create a production environment which is supported, which has been tested on and so on.

This is how it looks like. This is part of a DSC file, specifying things like I want this Windows feature to be installed. Once you compile this file will be able to further used (with an existing or a when you create a new VM).

View the entire Dev/Test in Microsoft Azure series

• Part I: Discover the core benefits of Dev and Test with Azure
• Part II: How VSTS Integrates with Microsoft Azure in Dev/Test Scenarios
• Part III: Dev/Test with Azure Resource Manager
• Part IV: Why Use PowerShell DSC in Dev/Test Scenarios with Azure