On-premise VM’s and Azure Pipelines: Set up with multiple stages in Azure Pipelines (part 4)

Joost Luijben

In the previous article we discussed how we can build a pipeline and at some tests to it. In this article we’re going to discuss how we can set up the on-premise VM’s so that we can deploy the artifacts to them. You can also deploy the artifacts to an Azure Webapp. I recommend doing this if you’re starting from scratch, but if you can’t and would like to run them on on-premise VM’s, this is the right article.

Environment setup

On my setup I have three VM’s:

  • Acceptance – automatic deployment allowed (to see if it just works)
  • Test – only manual deployment (finals checks before deploying for production)
  • Production – only manual deployment

This means that I want to deploy my backend and frontend artifact to different VM’s. Luckily, azure has a solution for this! Azure enviroments.
Azure calls a set of VM’s that deploy the same code, an environment.
In combination with the deployment jobs you can specify to which VM you want to deploy. You can add checks to those environments so you can only allow manual deployments!

To use those environments we have to register one of the on-premise VM’S to an environment. You can do this by first creating an environment:

Select virtual machines
Select the copy function that shows up

Set up script

In the following code snippet I used most of the code from the copy function, but removed some commands (I don’t recommend running it interactively). Make sure you add your own token and url, you can copy this from the generated function (the copy icon):


mkdir azagent;
cd azagent;

curl -fkSL -o vstsagent.tar.gz https://vstsagentpackage.azureedge.net/agent/2.166.3/vsts-agent-linux-x64-2.166.3.tar.gz;
tar -zxvf vstsagent.tar.gz;
./config.sh --deploymentgroup --deploymentgroupname "Service Portal Acceptance" --acceptteeeula --agent $HOSTNAME --url $ORGANISATIONURL --work _work --projectname $YOURPROJECTNAME--runasservice; 

sudo ./svc.sh install; 
sudo ./svc.sh start; 

Execute those functions. You might make an new user so you don’t run the new user from root. I run the service under the user pm2.

When the service is running, it should show up under your environments in the environments panel in Azure DevOps

This shows that the on-premise VM is available

Do this for all three environments. You change the hostname for every time you run the script. The final result will look like this:

This shows an overview of all the environments with all the on-premise VM's

Adding only manual deployment

Now for every environment you can enable checks. For production, we want only a manual deployment.
Click on the production environment -> Click on the three dots -> Click approvals and checks -> Plus button -> Approvals.

In the next menu you can configure who is allowed to deploy to production

This shows the screen where you can configure the approvers for a manual deployment for an on-premise VM

Do this for every environment you want it to (I applied it to production and test). In the next article I will explain how you can deploy the build artifacts to those environments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Next Post

Deploy Angular and Node.js webapp in Azure Pipelines (part 5)

In the previous article I explained how to set up multiple environments for Azure Pipelines. In this article I will explain how you can deploy the artifacts to the on-premise VM’s. This are the artifacts you build in the pipeline. I am using an template for this, because we are […]
Azure Pipelines: How to build and test an Angular and Node.js webapp
%d bloggers like this: