In my previous post I showed a very simple example using Visual Studio Team Services Release Management albeit to the default environment. In this post I’m going to dive deeper into the concept of Visual Studio Team Services environments and machines.
Environments
When you think of the term environment in the context of deploying software the first thought is usually one or more servers where you deploy your application to. But in VSTS environments are something different and this is bit confusing in the beginning. In VSTS environments are a logical container for a set of variables, approvers, tasks and agent queues etc. I think the most important point is your set of deployment tasks are defined per environment. You have to put some thought into the design of your deployment process to balance the trade off between the re-use of assets and the ease of making changes per environment.
If I contrast the VSTS approach with Octopus Deploy where you have one deployment process, you could craft some control logic using variables, environments and life cycles but it could become very messy and difficult to follow. Changes to your deployment process would impact all the environments using that project making it more cumbersome when you have changes for instance to your dev environment only. This is often the case since you would introduce functionality incrementally per environment from dev to production.
In VSTS you can change the deployment tasks for one environment without affecting other environments but if you have the same change in all environments at once you have to repeat the change for each environment. From experience this should not happen very often since you do it incrementally from dev to production. It will be interesting to see how this plays out in the long run
Also keep in mind how you structure your deployment scripts, ideally you want to have the same script for all your environments but with different parameters passed in for different environments. If you have different logic for each environment it will become a maintenance burden and also leave you open to human error since you will be crafting a script for production that was never tested in dev or qa, missing the whole point of continuous deployment. You can’t completely escape errors but making changes to production by adding new variables is less error prone than running a new script.
Where do I specify my servers
This leads to the obvious question, where do I specify which servers to deploy to if that is not in my environment. Some deployment tasks have a section for machines where you can provide a comma separated list of machine names or IP address, a variable that will contain the names or a machine group name.
A machine group is a collection of machines, you could make one called Dev for instance and add all you development machines to it. To create machine groups open the Test menu in VSTS and then the Machines sub menu. The machines must have WinRM configured and accessible.
You can also use output variables from steps that create new VMs like the Azure Resource Group Deployment Task and pass those to subsequent steps. Some tasks like Command Line or Batch Script doesn’t have the ability to specify a machine name and they will execute on the server where the agent is hosted. If you really have to use these steps instead of remote PowerShell you can control the agents that are selected using agent queues that are configured at the environment level and agent capabilities that are configured at the agent level.
Links:
VSTS Deployment Guide
