chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male

Tinkering About… (Continuous Integration On My Mind)


** Interested in Continuous Integration? Watch our webinar “Set Up Your CI Project with TFS 2012 in 45 Minutes or Less” **

In the last few days, I was playing with a new CI system, trying to do a POC of Isolator with it. Basically, I’m doing the basics stuff: cause a build, then run tests and publish test results.

Continuous integration has been for a while now a part of any self-respecting ALM tool. The problem is that anything out of the ordinary (or the supplied template), and you start tinkering with configuration, setting arguments, environment stuff. I don’t like tinkering.

Take Microsoft TFS for example. You get a build configuration, including tests and coverage out of the box. You then get a visual editor, XML you can edit (if you know the schema) and you can modify it to your heart’s content. For example, to add Isolator tests in, you need to either use the template that comes with Isolator, or modify your existing template to work with Isolator.

Now TFS comes the closest in terms of usability a functioning CI tool. If you work with older CIs, like CruiseControl (or its .net sibling), or the current Jenkins you’re back to editing text.

Now there’s an argument going on in my brain. The developer side says: You know you can’t make it easy for everyone all the time. There are different version control systems. Different build systems, and testing frameworks, and data collection tools. How is it possible to work with all of those? The only answer is to make a tool which is the most configurable, provide libraries, and rely on vendors or the community to supply the rest.

But my product side says: it’s 2013 dammit! Can’t it just work already? At least the out-of-the-box experience should be less, well, tinkery? Are we destined to play with configuration settings for the next decade just to run tests?

Anything that requires configuration, is riddled with errors, hard-to-debug processes, and basically a barrier for new entrants. Show me an XML configuration file, and I’ll show you the people who gave up on it.

You may say: Well, they are not “real programmers”. Real programmers code and configure files.

And I say: Real programmers produce working software quickly. Tinkering gets in the way.

Until there’s a better way, I’m doing a webinar on tinkering, I mean working, with TFS. The title is ambitious: “Set Up Your CI Project with TFS 2012 in 45 Minutes or Less!” and I’m going to go over the needed settings you need to get your project building and running. I’m also going to talk about CI in general, so even you’re not a, ahem, fan of TFS you can take home something with you.

Check out if I succeeded right here!