[Please note: Just a couple of weeks after publishing this post Microsoft changed the name of Visual Studio Online (VSO) to Visual Studio Team Services (VSTS). I’ve updated the title and URL of this post for consistency with future posts but the text below remains unchanged.]
I first started investigating how to implement continuous delivery with TFS – working almost exclusively in Microsoft Azure – nearly two years ago. Out of these investigations (and backed-up by practical experience where I work) came my original 24-post series on implementing continuous delivery with TFS and a shorter series covering continuous delivery with VSO.
Although the concepts that I covered in my original series haven’t really changed the tooling certainly has – only what you would expect in this fast-moving industry of ours of course. In particular there have been fundamental changes to the way Microsoft Azure works and we also have a brand new web-based implementation of Release Management coming our way. Additionally, there are aspects of continuous delivery that my original series didn’t cover because the tooling I wanted to use simply wasn’t in place or mature enough. Consequently it feels like the right time to start a brand new blog post series, and it is my intention in this post to set the scene for what’s in store.
Aims of the new Series
- Hopefully by now most people realise that despite its name VSO (Visual Studio Online) is Microsoft’s cloud version of TFS. My original continuous delivery series focussed on TFS since the Release Management tooling didn’t originally work with VSO. Although that eventually changed the story is now completely different and the original WPF-based Release Management has a brand new web-based successor. As with most new ALM features coming out of Microsoft this will initially be available in VSO. TFS 2015 will get the new release management tooling sometime later – see here to keep track of when this might be. Despite the possible complications of different release timeframes I’m planning to make this new series of posts applicable to both TFS and VSO. This will hopefully avoid unnecessary repetition and allow anyone working through the series to pick either VSO or TFS and be confident that they can follow along without finding I have been focussing on one of the implementations to the detriment of the other.
- Of all the things that can cause software to fail other than actual defects, application configuration is probably the one that is most troublesome. That’s my experience anyway. However there is another factor that can cause problems which is the actual configuration of the server(s) the application is installed on. The big question here is how can we be sure that the configuration of the servers we tested on is the same in production, because if there are differences it could spell disaster? Commonly known as configuration as code I’m planning to address this issue in this new series of posts using Microsoft’s PowerShell DSC technology.
- So we’ve got a process for managing the configuration of our server internals, but what about for actually creating the servers I hear you ask? It’s an important point, since who doesn’t want to be able to create infrastructure in an automated and repeatable way? I’ll be addressing this requirement using the technologies provided by Azure Resource Manager, namely what I think are going to turn out to be idempotent PowerShell cmdlets and (as a different approach) JSON templates. For sure, you are unlikely to be using these technologies in an on premises situation however for me the important thing is to get hands-on experience of an infrastructure as code technology that helps me think strategically about this problem space.
- I’m a huge advocate for IT people using cloud technologies to help them with their continuous learning activities and if you have an MSDN subscription you could have up to £95 worth of Microsoft Azure credits to use each month. Being able to create servers in Azure and take advantage of the many other services it offers opens up a whole world of possibilities that just a few years ago were out of reach for most of us. However, as well as being a useful learning tool I also feel strongly that most IT people should be learning cloud technologies as they will surely have an effect on most of our jobs at some point. Maybe not today, maybe not tomorrow but soon etc. Consequently, I use Azure both because it is a great place to build sandbox environments but also because I’m confident that learning Azure will help my future career. I hope you will feel the same way about cloud technologies, whether it’s Azure or another offering.
- Lastly, I’m planning to make each blog post shorter and to have a more specific theme. Something like the single responsibility principle for blogging. My hope is that shorter posts will make it easier for those ‘trying this at home’ to follow along and will also make it easier to find where I’ve written about a specific piece of technology. Shorter posts will also help me as it will hopefully be an end to the nightmare blog post that takes several weeks to research, debug and explain in a coherent way.
Who is the new Series Aimed at?
Clearly I hope my blog posts will help as many people as possible. However I have purposefully chosen to work with a specific set of technologies and if this happens to be your chosen set then you are likely to get more direct mileage out of my posts than someone who uses different tools. If you do use different tools though I hope that you will still gain some benefit because many concepts are very similar. Using Chef or Puppet rather than PowerShell DSC? No problem – go ahead and use those great tools. Your organisation has chosen Octopus Deploy as your release management tooling? My hope is that you should have little problem following along, using Octopus as a direct replacement for Microsoft’s offering. As with my previous series I do assume a reasonable level of experience with the underlying technologies and for those for whom this is lacking I’ll continue to publish Getting Started posts with link collections to help get up to speed with a topic.
I carry out my research activities with the benefit of an MSDN Enterprise subscription as this gives me access to all of Microsoft’s tooling and also monthly Azure credits. If you don’t have an MSDN subscription there are still ways you can follow along though. Anyone can sign up for a free VSO account and there is also a free Express version of TFS. Similarly there is a free Community version of Visual Studio and a free Express version of SQL Server. All this, combined with a 180-day evaluation of Windows Server which you could run using Hyper-V on a workstation with sufficient memory should allow you to get very close to the sort of setup that’s possible with an MSDN account.
Looking to the Future
It might seem odd to be looking at the future at the beginning of a new blog post series however I can already see a time when this series is out of date and needs updating with a series that includes container technologies. However I’m purposefully resisting blogging about containers for the time being – it feels just a bit too new and shiny for me at the moment and in any case there is no shortage of other people blogging in this space.
Happy learning!
Cheers – Graham
The post Continuous Delivery with TFS / VSTS – Start of a New Journey appeared first on Please Release Me.
