Tuesday, July 12, 2005

Development Model

Bit of a nerd rant here. In most development houses, things work like this. You have a TRUNK in your cvs tree. Main development goes here. As you develop, you tag so that you can go back to specific points in time. When you're ready to release, you branch from the TRUNK. If bugfixes are needed in production, you apply them to the branch, tag, and re-release. Later on you can merge the branch fixes back into TRUNK, which is where main development happens. Pretty simple, right?

Here where I work, we do things differently. Main development happens in branches that are merged into TRUNK at release time. Take a minute and think about this. Every time a merge happens, conflicts arise and things need to be re-tested. You're merging large changes on top of bug fixes rather than bug fixes on top of small changes. The tree becomes a stick, and when someone fucks up in TRUNK, development has to switch over to the correct model, which confuses everyone. To further this problem, everyone works on everything, so if someone had to make a branch for something and the development lead forgets about it, the person that comes in to add their new stuff may not add it to the correct line of development (with the correct model, it would clearly either go in the branch if it's a bug fix, or the TRUNK if it's a feature).

Honestly, I don't know why we do things this way. Our development lead is stuck in his ways and I wholy believe that half of the problems we have are a result of it. He's a really smart fellow, but sometimes it really sucks to be stuck doing things in a way that makes absolutely no sense.

No comments: