|
Creating build definitions and release definitions in TFS and VSTS can become a real chore. Have you ever wanted to give a build or a release a little bit more flexibility, so you can handle some situations based on a condition, but didn't have a great way to give the developers control of that without having to meddle with manually setting variables all the time? Maybe you wanted to handle creating an "alpha" or "beta" version build of a nuget package? or perhaps you wanted a insert some control of how things deployed? Having variables to control these things is great, and can rescue you from having to clone your build and release to handle the various situations that you find yourself in. BUT now you've just given yourself more variables to maintain, and more things to remember to set at build or release time. I've run into a few situations in some recent work where it just makes the most sense to give control of what happens when code is committed to the developers that own the code. One of the most direct ways to handle some of those things can be accomplished by placing some of that variable information in the developers hands to begin with, and one of the easiest ways to do that is to give them some JSON to hold it. Some of my current work is involving creating a deploy pipeline and workflow to help the various development teams to most easily deploy their code to the various "dev" environments that many of the teams use. The development teams had set up a series of Web Application paths on the dev server to hold various instances of their applications, so that one team can deploy, without stepping on another team's workflow. Now team A, can deploy to Dev server app space "F3" while team B can deploy to app space "F5" and they won't interfere with each other, and then later they can deploy to app space "Integration" and all play nicely together. This is all great, except how can we easily get a team B to deploy over to Team A's app space without making sure they update all the right spots in the right release definitions? Well, I suggested we find a way to standardize a "deploy" json file that could be used to control some of those things ... this isn't the first time I've had to utilize a json file in the source code to help customize the process flow of a build or release, so instead of trying to craft yet another one-off custom task, I decided to create a more flexible task that will read a JSON file and simply create Variables in the build and release for subsequent tasks to utilize. This way, I can feed other tasks the information they need, and I never (hopefully) will have to write something to pull the data out of a JSON file for my build and release processes again. Here's what I've got. It's in the Marketplace as "Json to Variable" and it will parse through a JSON file and generate variables with the data it finds. So some JSON like this:
|