This is part 5 of 5 of my How to Blog with VSTS series.
I’ve been tinkering with Visual Studio Team Services off and on since its public release, but never did anything really productive with it. Over the past couple of weeks, I finally bit the bullet and decided to move my most prevelant personal project into VSTS: this blog.
In this post, we’re going to schedule our deployments using the Release tools provided by VSTS.
Builds VS Releases
The first thing I want to point out is that releases feel like an extension on the builds of VSTS. We pointed out last time, that if you wanted to just continually deploy after you were done a build you could add a step to your build script to do so.
With releases, this is further extending that deployment step to add release logic, workflow, and handle multiple environments.
Before we get into releases, I want to point out that there is a lot more functionality here that I’m not exploring because I didn’t need it for my blog, nor for my build/release pipeline. I would recommend taking your time and exploring the options available in each of the screens, and take a look at the official VSTS Release Management documentation to see everything it has to offer.
The Release Plan
Being a simple project, I generally stick with a simple release plan:
- Take the latest
masterbuild and deploy to the test environment
- Get a post-deployment approval of the test site
- If approved, deploy to production on Monday morning
As you can see, I have two environments: test and production. The second part of this is the approval component. Even though my planning and code reviews work well, I want to do a final once over before it goes live.
The scheduled releases give me a regular release window to target. That way, it keeps me driven to keep to a schedule for my content, and for pushing out fixes to bugs or other issues.
With our plan in place, we’re ready to make it.
Creating our Release
Creating a release is very similar to creating a build. Click on Releases from the top nav menu and you’re presented with the Releases screen. Click the “+” button on left side of the screen, and start creating our release.
Adding our Environments
First thing we do with a release definition is define the environments that will be deployment targets. In my case, I have a test environment that will get deployed to first, and a production environment that we’ll deploy to if everything looks good on test.
Select the Add Environment and create a new environment.
At this point, we define the tasks needed to deploy to this environment. This works exactly like builds, so if you skipped that post I would suggest going back to review it as it’ll give you everything you need.
For my test environment, I only have one task: to deploy the build assets we saved from our build to our environment.
Because I’m using Windows Azure, this is pretty easy as you can see above. If you’re deploying elsewhere, like GitHub pages, you might have a few more steps or need to write a Powershell script and execute it like we did in our build script earlier.
Once we’re done defining this environment, we need to create our production environment. We can add another and do it from scratch, or we can just select the Clone Selected Enviroment option from the … drop down menu and make a few tweaks.
With our environments defined, we need to setup our approval step.
We want to add a post-deployment approval step for our test enviornment, so that we can confirm that everything looks good before we give the the go-ahead to unleash our blog onto the world.
This is pretty easy. If you click the … on menu, you may have noticed the Assign Approvers menu item. Select that and you’re on your way to assigning approvers.
The window that appears is pretty self-explanitory. If you select “Automatic” you’re saying that the approval automatically happens. If you select specific users, you can select people on your team who will be able to approve the test environment. Since I’m a solo blogger, it’s just me, but if you more that yourself working on a project, you can select more people. Make sure you click on the More Options link to see some of the extra logic you can apply with approvers.
Setting Deployment Conditions
With production, we want to define a few conditions before it deploys. More specficially, that the test approval is complete and approved. To do that, we click the … for the production environment and select select Deployment Conditions.
Configure the deployment conditions as you see fit, and with that your release definition is officially defined!
…Now we just need to trigger it.
Triggering the Release
Back on a main releases screen, there is a triggers tab that allows us to define what triggers the release. Select it, and you’ll be able to kick off a release based on whatever trigger you’d like.
Because I’ve setup a scheduled build to happen every Saturday night, I tied my release to kick off after a that build script completes successfully.
NOTE: Environment Triggers
This screen also lets you define what triggers the deployment to each of your environments. If you filled out the Deployment Conditions section earlier, this will already be filled out. If you click the pencil icon, it will bring up the same Deployment Conditions window that we filled our previously.
And That is That!
You now have your first project in VSTS using all the bells and whistles.
As I hope you’ve realized throughout this series, VSTS is exceptionally powerful and flexible. It works for something as simple as a static blog like mine, but it provides enough power for any project you’re looking to manage.