I’ve been doing a whole lot of work with Visual Studio Team Services, formerly Visual Studio Online, and making heavy us of the Release Management feature as I discussed recently on the Microsoft Cloud Show Episode 146.
As this can be a wee bit daunting I’m going to do a few blog posts to help you get started with this tool. So this doesn’t blow out to an epic boil the ocean post I’m going to assume you have a few things:
- A VSTS subscription. These are free for small teams, up to 5 people I think, so you can try this at home
- A Team Project set up using git as the source control system of choice, because friends don’t let friends use TFS
- git installed on your local machine
- An Azure Subscription that you are an Administrator of. It’s pretty easy to get a trial subscription with $200 credit if you’re wanting to try this at home or without incurring costs for evaluation purposes
- An Azure Web App with at least a Standard license and a second deployment slot configured in your subscription.
So, you might need to get a few of those sorted out, don’t worry you can pick back up here once you have those 5 things.
There are a few tasks that we need to do
- Get the code into a VSTS Team Project backed by git. I suppose if your really wanted to use TFS the steps beyond this one would all be the same too…..
- Set up a simple build process
- Connect VSTS to Azure using classic mode
- Setup a simple release process
Get the code into your VSTS Team Project
You’ll note that I didn’t mention Visual Studio. So that’s not a blocker for you I’ve put that code together, if you want to use your own project, great, infact I’d prefer it but I need code to build this so I just went File > New > Project > ASP.NET 4.6.2 Web site > SPA and pushed all that to github.
Fire up your command prompt of choice. I personally use PowerShell with PoSHGit installed. Then clone the sample repo locally.
git clone https://github.com/gavinbarron/SPA-Template.git vsts-rm-mpta
This will pull down the repository into a new folder called vsts-rm-mpta
Change directory into the newly aquired repo
cd vsts-rm-mpta
Remove the link to the github repository that you acquired this code from
git remote remove origin
Now we need to get this code into your VSTS team project, If you click on the Code tab in the VSTS UI you’ll be presented with a page that helps here if there’s no code in there.
Image may be NSFW.
Clik here to view.
Towards the bottom of the page you’ll see the information you need:
Image may be NSFW.
Clik here to view.
So you can just copy and paste those from your VSTS instance.
git remote add origin <url-of-your-vsts-git-repo> git push –u origin –all
These commands establish the link between your local repository and the one that backs your VSTS Team Project and push the code from all branches in the local repo to the remote repository called origin. Note the name origin is a commonly used convention, if you really wanted to that remote could have the name Slartibartfast.
Image may be NSFW.
Clik here to view.
Now the code is being in your VSTS repo, let’s create a simple build process.
Set up a simple build process.
We’re going to configure the most minimal build process possible. This is not what you should be doing in the real world. For a real project I’d at the very least have task in our process to run unit tests. I’m deliberately omitting that step for the sale of brevity.
In VSTS click on Builds
Image may be NSFW.
Clik here to view.
Note that your VSTS instance may still have the older top navigation that has Build and Release as separate entries at the top level.
Click the big “New definition” button
Image may be NSFW.
Clik here to view.
Choose the Visual Studio base template as this give us most of what we want and click Next.
Image may be NSFW.
Clik here to view.
You can choose to make this build a CI build so that is kicks off every time your commit changes to your repository by checking the box as I have, this is optional though. Then click create.
Image may be NSFW.
Clik here to view.
Now that we have a base let’s set up our build.
First of all delete the Test Assemblies, Publish symbols path and Copy Files to tasks.
Image may be NSFW.
Clik here to view.
Next we’re going to re-configure the Build solution task so that it creates a Web Deploy package which we’ll use in the Release process. Click on the Build solution task
Use the … to the right of the solution text box and use the file explorer dialog to find the vsts-rm-mpta1.csproj
Set the MSBuild Arguments value to this
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=$(build.stagingDirectory)
This creates a web deploy package which we will use in the release process writing it directly into the folder which is used in the Publish Artifact task.
Click on the Variables item in the Build Definition navigation.
Image may be NSFW.
Clik here to view.
On the variables tab we need to edit the BuildConfiguration and BuildPlatform to use Release and AnyCPU as shown here. This is because we’re building from the project file rather than the solution file. With these edited click the save button
Image may be NSFW.
Clik here to view.
Give your new definition a name and click OK.
Image may be NSFW.
Clik here to view.
Click the Queue new build button to test out the build.
Image may be NSFW.
Clik here to view.
Accept the defaults and click OK
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Excellent, we have a web deploy package ready to push out to our website.
Connect VSTS to Azure in Classic Mode
In the top navigation click on the Services link in the hover menu under the cog. Note that if your tenant is using the old navigation then click on the cog and in the following page click the Services link in the top navigation.
Image may be NSFW.
Clik here to view.
Click on the New Service Endpoint dropdown and then Azure Classic
Image may be NSFW.
Clik here to view.
You could choose to use a Credentials based connection if you like, I prefer a certificate based connection as it’s not going to become invalid if the password of the user account used changes. Select the Certificate Based Radio button and click on the publish settings link.You may need to sign in to your Azure account.
Image may be NSFW.
Clik here to view.
Choose, the Azure Active Directory that is associated with the Azure subscription that you want to link in the drop down and click Submit
Image may be NSFW.
Clik here to view.
Open the .publishsettings file that downloads, copy over the corresponding values, click verify connection and once the connection is verified click OK.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Now with a connection established between Visual Studio Team Services and your Azure Subscription you’re ready to create a release process.
Create a Release Process
Click on Releases in the Build & Release hover menu, if your tenant is using the older menu this will be a separate entry in the top navigation.
Image may be NSFW.
Clik here to view.
Click on New definition
Image may be NSFW.
Clik here to view.
Select Azure Website Deployment and click Next
Image may be NSFW.
Clik here to view.
On the next pane of the dialog you can choose to turn on Continuous Deployment. This will result in each successful build of the linked build definition triggering an automated release. As you only have one build definition at this stage it’s automatically selected as the default, so just click on Create
Image may be NSFW.
Clik here to view.
Click on the Pencil icon and give your release definition a new name.
Image may be NSFW.
Clik here to view.
In the configuration pane for the Deploy Website to Azure task select your newly configured connection in the Azure Subscription (Classic) drop down. Choose the region that you deployed your target Azure Web App in. In the Web App Name type in the name of your Web App, the values that appear in the drop down are only the web site associated with the default service plan in the selected region so don’t be surprised if you don’t see the target website listed.
Enter the name of the slot that you created when your set up your Web App.
Use the file explorer to locate the vsts-rm-mpta1.zip file in the build output.
Image may be NSFW.
Clik here to view.
The additional arguments value can be cleared
Image may be NSFW.
Clik here to view.
Delete the Run Tests task
Image may be NSFW.
Clik here to view.
Click on Environment 1 and re-name it to Dev (or whatever you like)
Image may be NSFW.
Clik here to view.
Click on the ellipsis (…) in the environment card and choose Clone Environment
Image may be NSFW.
Clik here to view.
In the add new environment dialog let’s assign an approver so that we have a sign off process before deploying to production for our simple process and then click Create
Image may be NSFW.
Clik here to view.
Rename the environment to Production
Image may be NSFW.
Clik here to view.
Clear the value set in the Slot setting for the Deploy Website to Azure task
Image may be NSFW.
Clik here to view.
Click Save and click OK in the dialog.
Image may be NSFW.
Clik here to view.
Open the + Release drop down and click on Create Release
Image may be NSFW.
Clik here to view.
Select the version of your build that your want to deploy with this release. You can also see here that you can change the deployment triggers for each of the environments that you have configured, in this case we’ll leave the options as configured in the release process and click Create.
Image may be NSFW.
Clik here to view.
Click on Release 1 to see this release in action.
Image may be NSFW.
Clik here to view.
After the release into the Dev environment has succeeded you can see that there is an approval to deploy to production pending. The users listed as approvers will also receive an email notifying them that there is a deployment pending approval too.
Image may be NSFW.
Clik here to view.
At this point take a moment to verify that the slot you configured has had the code deployed successfully
Image may be NSFW.
Clik here to view.
Click on Approve or Deny and choose to approve the Production deployment. You’ll note here that you can differ the deployment to a later date, this can be extremely useful if your customer requires a 3am deployment (although you’ll probably want to wake up and verify that all is good after the deployment)
Image may be NSFW.
Clik here to view.
After a while the deployment will complete and you’ll see this reflected in the summary page
Image may be NSFW.
Clik here to view.
Congratulations, you’ve successfully configured a simple release process using VSTS Release Management.
Conclusion
As you can see although we covered a lot of configuration this basic process could easily be added to almost any existing Visual Studio Team Services based website build process. We’ve barely even scratched the surface of what is possible with this platform
There are plenty of other ways that this could be configured, for example we could have our Production environment not use a web deploy task but run a script to swap the dev and production slots. We could use Azure Resource Manager to provision or update our environments. We might want to set Application Configuration specific to the environment that is being deployed into. I’m planning on covering each of these three scenarios in future blog posts.
Please let me know if you found this useful, if there’s anything that you think needs clarification or improvement.
Filed under: Azure, Deployment, Development, DevOps Image may be NSFW.
Clik here to view.
