TFS Release Manager–Website Application Pool Start & Stop

Requirement is to copy the updated files of the website to the target environment (Production, Staging etc.) automatically using copy task in release manager.

It can be easily implemented by using the copy task which is internally a Robocopy operation.

Issue is that the copy task will fail, if some user is already accessing the website and at the same time this task is trying to copy the files.

This problem can be handled by implementing following steps in the given order –

1. Stop the application pool
2. Copy the updated web files
3. Start the application pool

Step 2 above is the available copy task in TFS RM.

Step 1 and 3 can be implemented using a PowerShell script.

Here is the content of the script –

<#

.Synopsis
    Start / Stop Application Pool

.Discription
    It starts or stops the application pool of a website. 

.Example
 powershell.exe -file .\AppPoolStopStart.ps1 ApplicationPoolName Start/Stop

. Example
 powershell.exe -file .\AppPoolStopStart.ps1 DefaultAppPool Start

#>

param ([parameter(Mandatory=$True,Position=0)]
        [string][ValidateNotNullOrEmpty()]$AppPoolName,

        [Parameter(Mandatory=$true, Position=1)]
        [string][ValidateNotNullOrEmpty()]$Action)

        
if ($Action -eq "stop")
{
    Write-Output "Stoping the Application Pool - ($AppPoolName)......."
    import-module WebAdministration
    if((Get-WebAppPoolState $AppPoolName).Value -ne 'Stopped')
    {
        Stop-WebAppPool -Name $AppPoolName
        Write-Output "Application Pool - ($AppPoolName) stopped successfully!" 
    }
}

if ($Action -eq "start")
{
    Write-Output "Starting the Application Pool - ($AppPoolName)......."
    import-module WebAdministration
    if((Get-WebAppPoolState $AppPoolName).Value -ne 'Started')
    {
        Start-WebAppPool -Name $AppPoolName
        Write-Output "Application Pool - ($AppPoolName) started successfully!"
    }
}

Its can be executed as -  .\AppPoolStopStart.ps1 DefaultAppPool Start

Now add this to the source code in TFS and publish it in the build artifacts for the release definition.

In release definition, add the following tasks in the below order –

1. Task to copy this PowerShell from the published artifacts to the target machine.
2. Task to run PowerShell on Target Machines to execute the above PS script with an arguments as “Application Pool Name and the status as “Stop”.
3. Other required Release Manager tasks.
4. Task to run PowerShell on Target Machines to execute the above PS script with an arguments as “Application Pool Name and the status as “Start”. 

          

On successful execution of the above release definition, it will –

1. First stop the application pool.
2. After successful execution of other tasks, it will finally start the application pool.

             ——End of Article——

RM – Agent based or vNext (Agent less)

Microsoft Release Management is the DevOps solution for delivering the software easily and more frequently to any given environment and by controlling the process through approvals for each step.

It can be used in two ways.

1) Agent Based Release – For it, you need to install deployment agents to each of the machines in your environment that are required to deploy your applications.

2) vNext (Agentless) based Release – For it, you need to use Windows PowerShell, Windows PowerShell Desired State Configuration (DSC), or Chef to deploy your application to machines without installing a deployment agent.

I am assuming, you have selected on-premise based release. With this said, which above option to select? Should I select agent based release or vNext release?

I have tried summarizing it in the below table that will help you taking the right decision:

S.No.	Agent based Release	vNext (Agentless Release)
1	Agent needs to be installed on every target machines.	PowerShell Remoting needs to be enabled on all the target machines.
2	Pull based	Push Based
3	On every RM release/updates from Microsoft, Agents may needs to be re-installed and re-configured. Microsoft says, Agents auto-upgrade upon upgrading RM server but there is no guarantee.	No need to change anything on new RM release/updates
4	It can use in-built deployment tools	Here everything needs to be written in PowerShell Scripts that is based on Windows Remote Management and PowerShell
5	No direct PowerShell DSC support. You can run a PowerShell DSC script from Agent based release template using command-line task.	PowerShell DSC fully supported

Let me explain each of the above point in the same order. Each point has its own advantages and disadvantages.

1) As said above, for agent based release, deployment agent needs to be installed on all the target machines so maintenance cost will be there. This negative point can be mitigated by using SCCM packaging to deploy agent automatically to all the servers.

In case of vNext, there is no agent involved, rather PowerShell remoting needs to be enabled which can be a security issue.

PS remoting can be enabled and WinRM port configured for HTTP communication using below PowerShell commands

a) Enable-PSRemoting –Force

b) winrm quickconfig –transport:http

It actually opens WinRM and can be used by hackers to run any script from remote machine. Extra security (like SSL) needs to be in place.

2) Pull Based vs Push based – In case of Agent Based, Agent will be pulling PowerShell script(created by RM as tools or created by users) and will use that script to perform the particular task.

In case of vNext, RM will push the PS script to the target machine using the PowerShell remoting.

Both approaches are ok to use.

3) With every Microsoft Release Management software release/update, we have to uninstall, reinstall and reconfigure the deployment agent on all the target machines. This will be big overhead as it needs to be done on all the target machines. It can be mitigated, by redeploying using SCCM.

Though, as per Microsoft, deployment Agents will be auto-upgraded upon upgrading the release management but there is no guarantee. Recently, with RM 2015 update 1, we had to do a manual upgrade of the agents.

This overhead will not be there at all for vNext based as it does not have any agent in place. This is big plus for vNext based.

4) In Release Management software, Microsoft have written many tools that can be used to achieve particular task like copying, MSI Deployer etc.  List is given below:

You can create your own tool and you can add in it as well. Internally, all these tools are created using PowerShell.

Now, in case of Agent based, you can use any of the above already available tools from Microsoft in your automated release to achieve the particular task.

Unlike it, in vNext, everything needs to be written in PowerShell scripts. This means that for any activity, you will need to write a PowerShell script from scratch. This could be hard in the beginning and can be treated as a negative point. But as you will start working on it, you can have your own PowerShell library that you can use with other releases as well.

5) PowerShell DSC – 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.

There is no direct support of PowerShell DSC in case of Agent based release. however, you can run a PowerShell DSC script from Agent based release template using command-line task and by enabling Remoting (WinRM).

vNext based release fully support PowerShell DSC as it runs with the same concept.

Conclusion –

Agent based, 

• Getting started is easier – rich set of tools/actions
• When you decide to move to web-based model, you need to translate the fine grained actions into equivalent PowerShell scripts.

vNext based

• Getting started is harder, need to be hands-on with PowerShell scripting

Note – If you need to get started quickly then Agent based. If you’re comfortable with PS scripting then vNext.

–End of Article–