| Integration |
[02 Apr 2009|12:43pm] |
|
One of the things that can help with integration are "continuous integration" tools; by using CCNet we ensure that when a developer checks in some code it gets checked out, built, the unit tests run and then deployment packages run (which create the database tables and stored procs). This makes sure your changes are tested against everyone else changes and encourages developers to "Get Latest Version"* before checking in lest your check in clash with something and "break the build"
The big question is what to do next. The obvious thing is to automatically build the next project in the chain; the argument being if you changed the model and rebuilt, then you need to rebuild the business and UI layers to pick up any issues that the model change might have cause. A downside is that you probably know that the business layer is going to break and are about to fix it so why bother with a build you know is going to fail. You could wait until you've updated all layers before checking in** but on the other hand you may want your model changes in there so than others can start using them now.
More importantly, in a large team, you could also find yourself checking in code into the UI project just as it's building following a business layer build so then they end up waiting twice as long to see if their build goes green. That's an argument of streamlining the builds to as quick as possible, of course, but if you're running lots of unit tests and test deployments you might need to juggle. There is always the idea and there is always pragmatic.
Ultimately the answer is communication, a colleague will come round and warn us when he's "getting the planets aligned", by which he means he's about to turn off the automatic builds so he can build each bit in turn manually and make sure we've got a last known good deployment.
* Actually with Team Foundation Server, we so regularly found that this didn't get us all the latest changes that we gave the menu item the moniker "Get Late-ish Version".
** If you do that make sure you shelve your code overnight so it is in the code repository and backed up rather than having lots of changes on your local machine only.
|
|