.NET Development by Eric

💡 This post is part of my TFS tips where I write about how we make the most of TFS (on premise)

During release in our CI/CD we want some codedUI tests to run. In TFS we have the “Visual Studio Test Agent Deployment” and “Run Functional Tests” steps but some extra work is needed to get the tests running every time.

Manual

Since we use the same dedicated machine for every codedUI test the setup is done manual. There are two things that need to be configured:

1. screensaver timeout, make sure it is long enough (10 min+) or disabled
2. autologon (sysinternals), provide the credentials and after every reboot this user is automatically logged in.

Release

The first step in the release definition will reboot the codedUI machine. Then the artifacts are deployed to the first environment (during which the codedUI machine is rebooting) When it is time to start testing the codedUI machine is done booting and the autologon makes sure it is able to interact.

💡 This post is part of my TFS tips where I write about how we make the most of TFS (on premise)

We are currently working on a project that needs the Java runtime to be installed on our local servers. As lazy developers we want to script this once and let TFS Release handle it from then. This way we can expand our OTAP or scale out in productie with ease.

Artifact

The default proces of Release is get agent from pool, collect artifacts, install artifacts on target. So the first thing we did was add the Java runtime installation to an artifact on the build.
The build makes one archive (zip) from the installation files and scripts. That zip file is published as an artifact on the server. This way everything is available to TFS, no hassle with access rights to fileshares.

DSC

Our standard for script installation (and checking) of software is Desired State Configuration.
The complexity with this DSC is the required reboot after the Java runtime installation. There is a way to do this with DSC by allowing the DscLocalConfigurationManager to reboot if needed and to signal that a reboot is needed.
For this we create one Dsc script and one powershell script that applies this Dsc. The important part of powershell script is below:

# create mof
DscJavaServer -ConfigurationData $ConfigData -Verbose
# allow the server to be rebooted
Set-DscLocalConfigurationManager .\DscJavaServer -Verbose -Force
# apply DSC (install java if needed)
Start-DscConfiguration DscJavaServer -Wait -Verbose -Force

The contents of the Dsc file:

configuration DscJavaServer
{       
  Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
      
  Node $AllNodes.NodeName
  {
    Write-Verbose "Configuration for $NodeName"
    Write-Verbose "Installation files should be in $DeployLocation"
 
    # This allows the reboot
    LocalConfigurationManager
    {
      RebootNodeIfNeeded = $true
    }
 
    Script Java
    {
      GetScript  = { return @{} }
      TestScript = { return Test-Path 'HKLM:\SOFTWARE\JavaSoft\Java Runtime Environment' }
      SetScript  = {   
        $installer = "$($using:Node.DeployLocation)\jre-8u144-windows-x64.exe"
        Start-Process $installer -ArgumentList '/s' -Wait
        # signal reboot
        $global:DSCMachineStatus = 1
      }
    }   
  }   
}

Release

The release definition will push the artifact to the target server, unpack the archive (zip) and execute the powershell script.
Now we have a release pipeline that can make sure the Java runtime is on a target machine. If it is not the installation will be done including the required reboot.