TFS Build + CI + OctopusDeploy + NuGet

Working in a development team no bigger than 10 people often puts a lot of pressure on us to do things (depending where you work) outside of our domain like setting up TFS servers, Build Definitions, Deploy to different environments etc etc… And it hasn’t been easy given I’ve had almost no training or experience with Team Build, MS Build or the new TFS workflow activities but I still wondered in to this world out of interest and taken upon myself to figure out an easier way to create a virtual our “release manager” role.

After doing much research, I will go through what I decided so far would be our solution in my first ever series of blog posts. To first come up with my prototype for delivery, I had come across many distracting solutions one of which was WebDeploy! Don’t get me wrong, because this is actually a neat solution for those that want to particularly work with websites only hence the name… But even so, by attempting to bundle a Build + Deploy using TFS MsBuild with each csproj file containing IIS settings for each configurations has a few drawbacks but I won’t go in to that today.

Here’s a few resources that can be very useful for web deployment in particular:

http://www.hanselman.com/blog/WebDeploymentMadeAwesomeIfYoureUsingXCopyYoureDoingItWrong.aspx
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
http://vishaljoshi.blogspot.com.au/2009/09/overview-post-for-web-deployment-in-vs.html

The Situation

6 environments + 15 applications (including websites, task schedules, windows services)  = Not so easy with TFS and .Net

The QA environment may have to deal with multiple development streams. And this is one of the key reasons I was motivated to look in to improving our release strategy.

The New Strategy

After having an interesting conversation with a dude called Brett Maytom from http://readify.net/ who came in to help us with a few TFS issues, he had changed my way of thinking when it came to described situation above.

The outcome was that, building packages and deployment should be considered as two separate processes. TFS Build should be enough to get packages built but getting it to actually deploy to physical servers should be handled by an additional process. He then pointed me in the direction of a deployment tool called Octopus that was developed by a colleague. At that point we also had a new developer on board that was also suggesting a similar approach with another tool called Jenkins.

Before I went on to research other tools I decided to invest a bit of time learning more about the ones I came across so far and they seemed promising enough so I jumped straight into to it.

Possible Solutions

  1. Octopus Deploy
  2. Jenkins

As per blog post title, I decided to research Octopus for a few reasons and it has been a great experience thus far.

  • Auto config transformation support during deployment
  • Powershell scripts easily runnable pre, post, during and on failed deployments
  • Geared towards .Net development tools like NuGet packaging and allowing for MsBuild arguments
  • Easy to install and uses RavenDb.
  • Developed by an Aussie Paul Stovell. A local dude should be better at providing support and he has proved reliable.

Each of the following blog post links will be available once I have covered them.

  1. Website deployment and Package Versioning
  2. Windows services and Consoles with Windows Task Scheduler
  3. SQL Source Control and Deployment
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s