Categories
Development

Multiple teams and source

For quite a while now I have been spending way too much mind capacity on how to handle source when it comes to team-dependencies, library dependencies and database dependencies. There is certainly not a one size fits all solution out there, but Henrik Kniberg has a good introduction to the mailine model for handling source code.

I’m not convinced, but most of my scepticism could be written off to my mergophobia. It is mainly because I havn’t had the chance to practice it, and it is really something you need to have in your toolbox to be agile. I suspect many others share my phobia. On previous projects it has been sort of a pet peeve for me to point out that we should practice release-branches and fixes when we have the time. Not when everything else is burning like hell. Never really got there though.

We’ll scepticism aside. I guess my new years resolution (I just figured it out a month or two late) is to try more stuff without thinking it to pieces. I’ll probably get a lot more done that way. 🙂

BTW: QCon is on, and I’m not there. I had a blast there last year, so major envy to everyone that is.

Categories
Development

GUTs and BUTs

Alright, so it’s a cheap one, but I had to do it. 😉 Alistair Cockburn coined the term GUTs – Good Unit Tests in a blog entry. Having a term for it was a bit of an eye opener.

I do TDD, but it’s not always the way I do stuff so I’m not religious about it. But wether I write the tests first or after, what I really strive to achieve is Good Unit Tests. TDD is a technique to make it easier to achieve GUTs, but it is no guarantee. What other techniques is there?

GUTs isn’t easy to achieve wether you write them before or after (thus I really have too many BUTs too), but that is what my system needs to be agile and avoid resisting change.

Categories
Development

Database migrations

I was originally looking for a way to organize our db-scripts so we could do a full drop and recreate before running tests, or deploying a new version. One of the main disadvantages to this is that test data will get lost. By separating the scripts you can still maintain upgrade scripts for when you are going live with a new version.

But since we have many interested parties, asking them to drop all their carefully crafted test data is not an option. That’s when I stumbled across DBDeploy. It is beeing developed by a bunch of Thoughtworks guys, and it supports upgrade/downgrade in small increments. It seems alright, though it’s doesn’t seem to be under active development. Last svn activity was in october last year, but I guess some simple things actually get done. 😉 I’ll report back when we get some experience with it.