You are currently browsing the monthly archive for November 2009.

One of the constraints that makes moving towards continuous deployment difficult for some teams is the downtime required with web app deployments.   Managed Chaos just posted an article on how to update web applications without destroying in-progress user sessions.   In this specific example he illustrates how to do this using a Tomcat cluster, but the fundamental principles apply to any tiered web application architecture.

Databases are, of course, a bit trickier since you’ve potentially got lots of dependency problems; luckily, the Exortech blog recently addressed this issue as well.

The more I’ve been thinking about continuous deployment the more I feel like it’s really going to be a game changer for companies that adopt it.  The barrier for entry is relatively low (and can be well understood before embarking on a project to adopt the process) and the reward of being able to reduce batch sizes on merges and (more importantly) give your product owners the ability to quickly get features in front of customers is key for any business.

I came across this flowchart that helps you determine the best chart to use based on the kind of data you are trying to get across.   I know that for me I have a tendency to rely on a few “go-to” charts that I’ve come to rely on when in fact there may be a better option out there that more elegantly expresses exactly what I’m trying to communicate.  This chart looks like a great resource to use to check your instinct against best practice.

Click on the image for a larger and easier to read version.


Jakob Ehn over at GeeksWithBlogs has written up a great list at   I’m particularly excited about the possibility of using templates for build definitions (I remember many an hour spent duplicating an existing build definition “the long way” with TFS 2008.)  It’s very cool that Microsoft decided to add gated check-ins as a core feature; we were able to get it working in the previous version, but it required a lot of creative engineering to get it working correctly.

I’ve just finished getting my local VM TFS sandbox up and running, and I have to say I’m very impressed with the new installation and configuration process.  There still seem to be the usual arcane permissions magic that needs to be done in order to get everything playing together nicely, but nothing that you can’t figure out with a bit of trial and error and/or making service accounts domain administrators. 🙂

Craig Tadlock (over at the Tadlock Enterprises Blog) made a couple good posts recently about Team Foundation Server and Team Build 2010:

Work Item Classifications
Work Item Relationships

He also came across this great blog that is focused on doing automated testing:

as well as this link discussing custom workflow items:

I’m setting up a local TFS test environment for myself now and hopefully soon should have some interesting information on setting up Lean build systems using this great platform.  I was lucky enough to work at a company that used the previous incarnation of Team Foundation Server and I have to admit I’m pretty excited to see what goodies Microsoft is giving us on this go-around.