Boy Meets World

Mike is currently…

trying to be Canadian

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages

Fri, 20 Aug 2004

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Effective Source Control

Most developers these days understand that a source control system is necessary, at least so they can collaborate with other developers on their team. A lot of folks seem to think of source control as a big communal bucket, or some kind of shared backup system. It’s much more than this, and you can get a lot more from your source control system by following a few simple practices.

Use a decent source control system

This might sound funny, after all source control has been around for ages, but your choice of source control software can really impact the benefits you see from it. CVS is the de-facto standard for developers collaborating on the internet, so if your source control system isn’t at least as good as CVS, you should really go look at why you’re using what you’re using. Paying big bucks doesn’t guarantee you’ll get a decent system — I’ve had bad experiences with StarTeam and PVCS, yet they both cost thousands of dollars. Subversion, the new open source replacement for CVS, costs nothing and works great.

Review your changes before checking in

I’m forever seeing developers check in changes without even eyeballing them for correctness. This is bad because you tend to check in extra stuff that you’d forgotten about, or even code that shouldn’t get into source control (System.out.println anyone?). A decent source control system should give you an easy way to review changes, postpone some changes for a later commit, roll back changes, etc. Reviewing your change also helps with the next part.

Commit logical changes with a decent log message

Often during a development session, you’ll change something fairly unrelated to the main task you’re working on. This is normal, and to be encouraged — if you see something that’s broken and needs fixing go fix it. New feature needed to help you implement your story? Go write it. But when checking in, don’t confuse the two. If your change includes a smaller, standalone change, check that in first, with a precise log message. Then check in your new feature.

Only change what you mean to change

As part of reviewing your changes, you might notice things you didn’t actually mean to change. Make sure you revert these changes, and don’t forget to re-run your test suite before checking in. It helps to have a fast build here, or to review your changes before running a big build.

Prefer smaller, frequent commits over big “end of week” code bombs

If your’re not checked in, it means you’re not sharing your changes with others. It’s important to frequently commit — if your changes conflict with someone else, you find out faster. If your changes include enhancements then another teammate might want to take advantage of them, and if you’re off work for some reason (or, yikes, your laptop gets stolen), your changes are right there in source control so others can use them.

Taking an extra little bit of care when using source control can really pay off. Weeks or even months after implementing new features or fixing bugs, your source control system can precisely tell you what was changed, by who, and (hopefully) why. Decent log messages, in particular, can save you hours of digging around in code trying to find something, and really help you communicate with other developers.

Posted 21:11, 20 Aug 2004.

[ permalink ]

Wed, 18 Aug 2004

Cruise and Anthill, part 2

My post last week on CruiseControl vs. Anthill Pro resulted in several emails, including a very well thought out response from Maciej Zawadzki, President of Urbancode (the company that develops Anthill). Maciej made several good points and I feel a clarifying post is in order.

Anthill and CruiseControl differ in their original design goals. Cruise is a Continuous Integration (CI) framework, whilst Anthill is a build server. This leads to the difference in approaches – scheduling builds verses monitoring source control for changes. Whilst Cruise can also function as a build server, for example scheduling a nightly build, its main purpose is CI. Similarly, whilst Anthill can be used to achieve CI, its main purpose is that of a build server.

Maciej noted that several of the problems with Anthill’s scheduling have been addressed in recent releases of Anthill. I’ll certainly make sure we check those out!

Finally there’s plenty of room in the market for both products. Realising that you need something to run builds and tell you when the build is broken is a quantum leap forward from “bad old days” checkin anarchy. If Anthill’s ease of installation helps get more people running an automated build, that’s great for our industry and should be applauded.

Posted 06:30, 18 Aug 2004.

[ permalink ]

Thu, 12 Aug 2004

CruiseControl vs. Anthill Pro

Continuous Integration is the practice of building your software many times a day, usually whenever a change is checked into source control, so the development team can find out quickly if they’ve broken something. A build will usually include unit tests, so we can catch broken logic as well as code that plain won’t compile. In the Java world, there are a couple of contenders for CI frameworks, CruiseControl and Anthill. I reckon CruiseControl is a far superior product, and here I want to outline why.

CruiseControl is probably the oldest framework for CI in Java, having been around for a few years now. It’s Open Source, hosted on SourceForge, and developed and supported by people including a bunch of ThoughtWorkers. I work for ThoughtWorks – it’s probably worth stating that clearly here. Anthill is a newer product, and comes in an Open Source GPL version and a “pro” for-money version. Here I’ll be discussing Anthill Pro, which we’re using on my current project.

The argument I hear most often for using Anthill instead of Cruise is because it’s easier to set up. Simply drop a War into a web container and configure using fancy GUI screens. Cruise requires that you build it from source, and configure it using an XML file, but it’s a well documented process and really gives you lots of power to control how Cruise runs. With Anthill, you’re stuck with a (buggy) GUI.

A CI framework runs builds for you, whenever the code in source control changes. CruiseControl includes a “build loop” that continually polls source control for changes, and launches a build when it detects a developer has checked something in. If changes occur during a build, Cruise will realise as soon as the current build is finished, and launch another build straight away. By contrast, Anthill includes a “build scheduler”, in which you can run your build, say, every 15 minutes. The immediate drawback is that it might be several minutes from a change going into source control until Anthill runs the build – in Agile software development faster feedback is better so the Cruise model wins. You might think scheduling a build more often will help, but Anthill tends to get its knickers in a twist when it has lots of stuff in the queue. Schedule a build once a minute and you’ll quickly end up with a long queue, since Anthill isn’t smart enough to realise a build is already scheduled. The trick is to schedule builds at about the same frequency as your build time, so a build will be scheduled soon after each build completes. Unfortunately, Anthill will only let you choose certain scheduling intervals, so if your build takes 20 minutes you’re forced to use a half-hour schedule.

Multiple project support is included in both Cruise and Anthill. In Cruise, each project runs in its own thread, detecting changes and running builds in parallel when projects change. This works great, as long as you don’t try to run too many projects on the same machine (or you’re willing to live with the occasional long build). With Anthill, scheduling multiple projects means they end up in the build queue together, with build threads taking items off the queue and running builds. Unfortunately, there isn’t any way to prevent the same project from being run twice at the same time. If a project is built by two threads, it’s almost certain that the two builds will interfere with each other and fail.

Constant feedback from your build box is required if developers are to act quickly and fix broken builds. Cruise includes various publishers to send email and create a simple, single page website including build status, what changes have been made since the last build, and what tests (if any) are failing. You can also get a system tray application that shows a little green light when the build is good, and goes red and plays a Homer “Doh!” if the build is broken. By contrast, the Anthill emailer doesn’t even reliably send “success” messages when a broken build gets fixed. The web site it generates shows only basic build status – to find out what’s broken we have to produce our own JUnit report page, which is several clicks away from the main page. Similarly the “what’s changed” information is in Anthill’s revisions log, buried 3 clicks deep.

Overall I’ve been disappointed by my experience with Anthill Pro. It looks good at first sight, but for use on anything other than a toy project it just doesn’t cut it. Our current installation has a memory leak, and requires regular restarts so it’ll continue to send status emails. The Anthill Pro developers are apparently “working on it”. I really think the effort spent trying to get Anthill to work would have been better spent building and configuring CruiseControl. The time invested is well worth it, and you get all the benefits of a proper Open Source product.

Posted 00:44, 12 Aug 2004.

[ permalink ]

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]

skizz-biz

[ joe walnes ]

joe's new jelly

[ rob baillie ]

oracle

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.