1

Our company is running an on-premise Azure Devops Server in our local intranet, it's only accessible from inside our company's network.

We already have several build and release pipelines that deploy to local servers using the deployment group agent that Azure Devops Server provides.

The project I am now working on has the goal to run on two public servers (test and live) and I can't set up the deployment group agent, because our Azure Devops Server is (obviously) not reachable from those servers in the current setup.

I was now thinking of two possible options:

  1. Deploy to a machine (server, VM, whatever) in our network using the Azure Devops pipeline and then proceed to deploy from there using msdeply in some kind of powershell script or similar.
  2. Expose our Azure Devops server in our DMZ to those specific servers. (my undesired solution)

My questions regarding this:

  • Do I have any other possible solutions for this?
  • Are there any best practices for what I'm trying to do here?
  • Is my option 1. possibly the solution and are there resources on how I could ideally achieve this?
E4est
  • 65
  • 1
  • 7
  • 1
    Why wouldn't you just msdeploy straight from your pipeline to the desired server? There's no need to deploy elsewhere and run a separate Powershell script, as pipelines are capable of running PowerShell or doing whatever other deployment task you need. – mason Jun 14 '22 at 12:39
  • 1
    An Azure DevOps agent doesn't have to run on the machine that you're deploying to. – mason Jun 14 '22 at 12:45
  • Because I was stubbornly trying to use the stage template for IIS deployment. Thank you for the heads up. When I was looking for a predefined task to deploy using msdeploy, I only found the deprecated one. The next thing I found was [this question about the deprecated task](https://stackoverflow.com/questions/49665437/tfs-2018-update-2-iis-website-deployment-deprecated-or-missing) and I'm going to try the solution there. If I won't be successful, I'll try to put a powershell script using msdeploy there instead. I'll get back and report how it went when I'm done. – E4est Jun 14 '22 at 13:42

1 Answers1

2

After mason pointed out I could msdeploy from my pipeline right away, I first found out about the WinRM templates in this question.

I have been trying around with that, but could not get it to run properly, so I ended up using a CMD script to do so.

The script uses the release artifacts from our drop directory and releases it to the according server. Here's the script I am using now.

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" ^
   -source:package='$(System.DefaultWorkingDirectory)/_$(RepositoryName)/drop/$(ProjectName).zip' ^
   -dest:auto,computerName="https://$(TargetServerIP):8172/msdeploy.axd",userName="$(AdminUser)",password="$(AdminPassword)",authtype="Basic",includeAcls="False" ^
   -setParam:name='IIS Web Application Name',value='$(ApplicationName)/$(ServiceName)' ^
   -verb:sync ^
   -disableLink:AppPoolExtension ^
   -disableLink:ContentExtension ^
   -disableLink:CertificateExtension ^
   -allowUntrusted

Some variables need to be configured, to make it run.

  • RepositoryName (e.g., my-repository)
  • ProjectName (e.g., NameSpace.Project - basically the name of the .csproj of the executable project without the extension)
  • TargetServerIP (e.g., 123.234.213.132)
  • AdminUser (e.g., UserName (save as secret) - The user with sufficient rights to deploy on the server.)
  • AdminPassword (e.g., the password of the user above (save as secret))
  • ApplicationName (e.g., app.name.com - The name of the main application in IIS)
  • ServiceName (e.g., users - The name of the sub application in IIS)

If you don't use sub applications in your infrastructure, you can leave out ServiceName, but you must change $(ApplicationName)/$(ServiceName) to $(ApplicationName) in the script then.

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
E4est
  • 65
  • 1
  • 7