chris clarke

Using an SVN client with Team Foundation Server

Tim Goodwin blogs about SvnBridge. Its a tool for being able to use Subversion clients with Team Foundation Server. I quite like the idea of creating good interfaces to bad systems, however it would be much easier if people stopped making bad systems.

Continuous Deployment As A Practice

A lot of people do Continuous Integration these days (even if that just means source control and CruiseControl). But very few teams seem to do any form of Continuous Deployment. The point of Continuous Integration is to detect integration problems as quickly as possible and to reduce the risks involved in a deferred integration. A deferred integration is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems. As Martin Fowler says in his article:

“you are putting yourself into a complete blind spot right at one of tensest parts of a project”

So why is deployment any different? If your deployment process involves things that have not been done continuously every day, such as packaging files, copying them to servers, installing, configuring & starting processes, then you are doing deferred deployment. A deferred deployment is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems.

It may not be as easy to do Continuous Deployment - so keep it simple at first - grab your build artifacts from your Continuous Integration server, deploy them, automate the rest of your deployment process - then run some simple Deployment Tests:

• Is it up?
• Does it work?

Worry about adding more complicated things such as testing failover, load balancing etc. later. Just get some simple, automated deployment test coverage. I’ve seen & heard a lot of painful release processes, ones that take to 5 in the morning, ones that take 8 hours on the weekend, ones that involve a degree of ‘trial and error’ - don’t ignore your deployment problems - make them visible and try to fix them, just like you would with a slow build or a failing CruiseControl build.

Red, Green, Cup of Tea

I like the Red Green Refactor pattern - write a failing test, make the test go green and then refactor the code. However, I’ve found recently that refactor doesn’t necessarily mean make the code tidier or improve the design to some people. To some people it just means change some existing code.

So I invented (by accident) the Red Green Cup of Tea pattern - write a failing test, make the test go green, and go and make a cup of tea whilst the build runs. I’ve found that whilst making a cup of tea, my pair and I can reflect on what we’ve just done and often find we weren’t 100% happy with what we just did. We then set our cups of tea back down on the desk and Refactor the code.

Circles Of Life

Continuous Integration (The way I do it)

Feature Development

Build-o-matic plugin screens

Latest screens from build-o-matic plugin for intellij:

Logging in:

After logging in:

(The black box saying ‘quick-cruise’ is the build-o-matic build being monitored : it goes red for last build failed, green for success and black if it can’t find the build-o-matic server (this is because I didn’t have a build-o-matic running when i took these screenshots))

(The two tiny icons are the pictures of the people who are currently logged in (me and no-one))

After I break the build:

A picture of our builds (Uh-oh - looks like the e2e build has crashed and the branch build is broken!):

Where can I get this plugin?

Coming soon - currently integrating with main build-o-matic source.

Is there an eclipse version?

Yes - but it’s no where near as good - only has the status bars.

Comments and feature-suggestions welcome

Continuous Deployment

As a developer I want a continuous deployment server that grabs every successful build from my continuous integration server, deploys it and tests that its been deployed correctly. Then when it comes to the end of an iteration, I can use the last successful deployment and just switch it over to live.