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:
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):
export HOSTNAME=YOURHOSTNAME
export PROJECTNAME=YOURPROJECTNAME
export ORGANISATIONURL=https://dev.azure.com/YOURORGANISATIONNAMEGOESHERE
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
Do this for all three environments. You change the hostname for every time you run the script. The final result will look like this:
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
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.
