Adding Some Flexibility to Build and Release with JSON to Variables

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:

Gives me output like this, and I get four new Variables in the process for other tasks to consume

This just gives me one more tool to help make my build and release pipeline a bit more flexible.  The source code is in GitHub, and is written with Typescript to run as a node task in TFS and VSTS.   It handles JSON objects, and Arrays. Really, the goal of this is not to generate some super complex process, and a simple JSON should suffice for where I envision this working.  

For now, this will get me through some of the deploy and build versioning things that I'm working with the development teams on, and I think I will be able to use this in the future.  If you can use it, please pull it down out of the marketplace and give it a spin!

Sanity check your Web Application Release with a Smoke Test

Automated build and deployments are great right!? Write some code, commit your changes, a CI Build can fire, and a CD Release goes off and deploys that shiny new code out to your web server! Magic! 
BUT, often I find myself working on a release pipeline that could benefit from a quick sanity check that the Web site that we deployed, is ACTUALLY available and running after the Deploy steps say they succeeded.  I mean what good is a Release that shows up nice and Green in your release

Only to then go to your application to find that it is not running, or is unavailable

Yuck! I want to see if the Website I say "Deployed" is actually a "good" deploy!  Enter the Release Web Smoke Test release task for tfs and vsts.  This task will run against a specified set of URLs, and test to validate that the response that is received is the expected result.. you can set the expected return value in the advanced settings, along with setting a retry count. So if you're deploying to a web farm, you can specify the individual server urls and test each server is running well. If you have a site that has a healthcheck api already on it that returns a different code than 200, you can specify something different than 200.. 

This can be used in a stand-alone manner to allow you to see if the release is functional, or even better you could use this failure to trigger a roll-back in your release, creating a more robust release pipeline than just firing away and forgetting about it.

I tried to make it somewhat flexible, but not overly so... If there is a case that you need that isn't covered here, let me know!  The code is up on GitHub so you can see what's going on and extend the task as needed, or even better, share your updates with me and I can publish things up to the Marketplace for everybody to enjoy.


<<  December 2018  >>

View posts in large calendar

Category list

Page List

Month List