Multiple team, component, environment deployment via DSC (Part-1)

Introduction
Last week I attended the Continuous Delivery Conference in Bussum the Netherlands. One of the keynote speakers was Steve Smith on the branching techniques used by companies. The feature branching method is still widely used but they impose the Continuous Integration philosophy quite often because they tend to live to long (for the lifetime of a project). Feature branching is then used as separate trunks for different projects. Those branches are developed by different teams and want to work independent from the other teams. To facilitate that, project managers want to reduce the risk by claiming their own production like DTAP street and expect operations to keep them all in sync. Besides to just say that’s not the way to go and that shouldn’t be allowed (we should definitely do that), I feel there are companies who just can’t change right now and still want to enable an automated release strategy. This blog gives an idea how to facilitate that.

Scenario
Let’s say we work for a company where 3 teams work at different components. The teams are in control of their own development process following scrum and don’t want to have any dependencies with each other due to the risk of failing their sprint. Company policy is to use DTAP, each team has their own street but when any team releases to production all the other environments also have to be updated to a production like state.

Analyze
To start we need to analyze what we are going to do and what challenges we can expect so let’s start. We have 3 teams who don’t want to have any dependencies other than absolutely necessary with other teams. We can use MS Release Management to implement this but that also raises the next thing to think about. Because the MS Release Management only supports Desired State Configuration Push mode. Remember that by design only one configuration can be active on any environment at the same time. This is not a problem for the first phases like Development and Test but when u release to your production you don’t want to push out the carefully monitored configuration by your Operations Team.

Environment
Let’s begin. We are going to setup an environment where we use MS Release Management to PUSH components to a DSC Pull Server. The Pull Server will be used by the target server this will make the configuration when used in an network isolated environment less complex later on.

To pull this off we need a few machines. Set up in azure or any other environment the following:
• MS Release Management Server
• Target Server
• DSC pull Server

Make it easy on yourself and make sure they share the same domain, the Target Server can also be in another (untrusted) domain.

Release Management Server
Now on our RM server we are going to setup a simple 1 stage pipeline Production, I am not saying other stages aren’t necessary but we don’t need them for the purpose of this blog. Setup a development stage and environment by using your DSCPullServer as targeted server.

DSC Pull Server
When u never tried PowerShell 5 now is the time to try it out and save yourself a lot of pain installing DSC-Resources you can download it from here.
The setup of the pull server is really simple just follow the steps described below or read the entire blog here.

• run PS >Install-Module xPSDesiredStateConfiguration to install the needed DSC resources.
• Install windows feature “powershell desired stated configuration service”

• DSC pull server run CreatePullServer script. This script will generate 2 websites. 1 pull server en 1 compliance server

configuration CreatePullServer
{
  param
  (
    [string[]]$ComputerName = 'localhost'
  )

  Import-DSCResource -ModuleName xPSDesiredStateConfiguration

  Node $ComputerName
  {
    WindowsFeature DSCServiceFeature
    {
      Ensure = "Present"
      Name  = "DSC-Service"
    }
    WindowsFeature IIS
    {
      Ensure = "Present"
      Name  = "Web-server"
    }

    xDscWebService PSDSCPullServer
    {
      Ensure         = "Present"
      EndpointName      = "PSDSCPullServer"
      Port          = 8080
      PhysicalPath      = "$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer"
      CertificateThumbPrint  = "AllowUnencryptedTraffic"
      ModulePath       = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
      ConfigurationPath    = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
      State          = "Started"
      DependsOn        = "[WindowsFeature]DSCServiceFeature"
    }

    xDscWebService PSDSCComplianceServer
    {
      Ensure         = "Present"
      EndpointName      = "PSDSCComplianceServer"
      Port          = 9080
      PhysicalPath      = "$env:SystemDrive\inetpub\wwwroot\PSDSCComplianceServer"
      CertificateThumbPrint  = "AllowUnencryptedTraffic"
      State          = "Started"
      IsComplianceServer   = $true
      DependsOn        = ("[WindowsFeature]DSCServiceFeature","[xDSCWebService]PSDSCPullServer")
    }
}
}

CreatePullServer -ComputerName DscPullServer 

Start-DscConfiguration .\CreatePullServer -wait

That‘s it, you setup a basic Web based Desired Stated Pull Server.

Target Server
At the target server we need a few steps to enable DSC deployment by the pull server.
• Make sure u can access the pull service for example http://dscpullserver:8080/PSDSCPullServer.svc.
• Add the URL to your trusted sites

• Run PS >Winrm quickconfig
• When your target is in an untrusted domain you need to set up a trust by setting the winrm TrustedHosts. You can do this by:

winrm set winrm/config/client '@{TrustedHosts="machineA, machineB, 172.20.1.100"}'

Now we finished setting up the boundaries for our experiment. In the next part we start developing the composite resource and fire up the pipeline.