In this first post on my series on implementing continuous delivery with Visual Studio Online, we look at configuring the basics, including setting up an account and linking into Visual Studio. As usual, I assume a degree of familiarity with the tooling and if you need to get up to speed with VSO, I have a getting started post here. I also assume that you already have a Microsoft account and I’ll be writing the series from the perspective of someone with an MSDN subscription who has access to Microsoft software and Azure credits. If that’s not you, then all is not lost since much of the tooling is available for free or as trial versions.
Create a VSO Account and Configure a Project
Our journey begins by creating a new VSO account. Head over to this page and sign in with your Microsoft account. Under the Accounts list, there is a Create a free account now link which allows you to create a new account using a unique URL ending in visualstudio.com. A fairly recent addition is the ability to have the account hosted in West Europe by clicking Change options. Once created, you should see your account listed with any other accounts that you have created or have been invited to join.
The first time you visit your account (analogous to a Team Project Collection in on-premise TFS), you will need to Create your first project which is analogous to a Team Project. I created a project called ContosoUniversity based on the Microsoft Visual Studio Scrum 2013.4 process template and using Team Foundation Version Control.
Link the VSO Account to Visual Studio 2013
Once your new project is created, the next step is to hook it up to Visual Studio 2013. You can do this from the Overview page of your new project if you have the account open in a browser running on your development machine or you can do as I did and manually connect in Visual Studio via Team Explorer – Connect. I added a new server using https://pleasereleaseme.visualstudio.com and that was all that was required for Visual Studio to prompt me for credentials.
With the account added, the next step is to map a workspace. I’d previously mapped ContosoUniversity to the TFS version of the project and the filepath was already in use so I added a VSO folder before the project name to keep everything tidy and avoid a ContosoUniversity2 folder. Next up is to add the ContosoUniversity source code to version control under a Main folder that is configured as a branch – see this post for fuller details. If you have your own version of ContosoUniversity from my TFS blog post series that you want to use, then go ahead (see here for a utility to unbind the solution from version control prior to copying it over) or you can download a zip of the code from here. At this point, you should be able to publish the database to LocalDb and run the application.
Create and Run a Build
As a final step to getting the basics configured, we’ll create and run a build. Although there is a Build area within VSO you can’t actually create a build here, and you need to do that from within Visual Studio. From Team Explorer choose Builds and then New Build Definition. The process is very similar to the one for the full-blown TFS I describe here. The main differences are that in Build Defaults I left Staging Location set to Copy build output to server and in Process I chose the TfvcTemplate.12.xaml build process template and in Automated Tests I changed test to unittests to stop the automated web tests from running.
With the build running successfully, I did notice one immediate different compared with TFS: it can take substantially longer for the build to wait in the queue. I can’t find a reference but I’m pretty sure I’ve read or heard that a build from cold is going to be longer because VSO has to stand up the infrastructure for your build. I’ve also found that the first build from cold fails with missing assembly reference errors – presumably package download not working. Inexplicably subsequent builds work fine. I still need to verify this with more testing but if you’re finding this, do let me know via the comments. On the plus side, once your build is created, you can queue it from the build section of VSO:
To finish off, the initial impression of VSO is that it’s very slick and extremely well integrated with Visual Studio. It’s certainly orders of magnitude easier to set up than TFS. Does it have all the flexibility of TFS when it comes to continuous delivery? We’ll start to find out over the next few posts.
Cheers – Graham
The post Continuous Delivery with VSO: Configuring the Basics appeared first on Please Release Me.
