New vNext Config Variable Options in RM Update 4 RC
Update 4 RC for Release Management was released a few days ago. There are some good improvements – some are minor, like the introduction of “Agent-based” labels improves readability for viewing agent-based vs non-agent based templates and components. Others are quite significant – like being able to use the Manual Intervention activity and tags in vNext templates, being able to use server-drops as release source and others. By far my favorite new feature of the update is the new variable capabilities.
Variables: System, Global, Server, Component and Action
Be aware that, unfortunately, these capabilities are only for vNext components (so they won’t work with regular agent-based components or workflows). It’s also unlikely that agent-based components will ever get these capabilities. I’ve mentioned before that I think PowerShell DSC is the deployment mechanism of the future, so you should be investing in it now already. If you’re currently using agent-based components, they do have variables that can be specified at design-time (in the deployment workflow surface) – just as they’ve always had.
The new vNext variable capabilities allow you to use variables inside your PowerShell scripts without having to pass them or hard-code them. For example, if you define a global variable called “MyGlobalVar” you can just use it by accessing $MyGlobalVar in your PowerShell script.
Global Variables
Global variables are defined under “Administration->Settings->Configuration Variables”. Here you can defined variables, giving them a name, type, default value and description.
Server Variables
Server variables can be defined on vNext servers under “Configure Paths->Servers”. Same format as System variables.
Component Variables
vNext components can now have configuration variables defined on them “at design time”.
You can also override values and event specify additional configuration variables when you add the “DSC” component onto the design surface:
Another cool new feature is the fact that ComponentName and ServerName are now dropdown lists on the “Deploy using DSC/PS” and “Deploy using Chef” activities, so you don’t have to type them manually:
All these variables are available inside the script by simple using $variableName. You may event get to the point where you no longer need a PSConfiguration file at all!
You can also see all your variables by opening the “Resource Variables” tab:
System Variables
RM now exposes a number of system variables for your scripts. These are as follows:
- Build directory
- Build number (for component in the release)
- Build definition (for component)
- TFS URL (for component)
- Team project (for component)
- Tag (for server which is running the action)
- Application path (destination path where component is copied)
- Environment (for stage)
- Stage
You can access these variable easily by simply using $name (for example: $BuildDirectory or $Stage). If you mouse over the “?” icon on right of the Component or Server screens, the tooltip will tell you what variables you have access to.
Release Candidate
Finally, remember that this Release Candidate (as opposed to CTPs) is “go-live” so you can install it on your production TFS servers and updating to the RTM is supported. There may be minor glitches with the RC, but you’ll get full support from MS if you encounter any.
Happy releasing!
