All categories

Posts in “Continuous Integration”

Scrum and Continuous Integration

Tue, Apr 15, 2008
I’ve been rambling about Continuous Integration a couple of times before and I just noticed that I have misspelled Continuous every time so I guess I’ll just have to go through all of my old posts and correct that. I have, on the other hand, gotten a lot of Google traffic from fellow misspellers around the world. Here’s a google search with misspelled articles, and here’s a search with the corrected ones.

Check your automatic builds frequently

Mon, Jun 18, 2007
Make sure your automatic, daily and continuous, build actually works. It is just like checking that your backup procedures actually works. You do not want to find out either one of those is not working when you really need them. This weekend our Team Foundation Server was moved and everything looked all right on Monday morning. There was no problem at all to connect to the new server and the Cruise Control Tray icon was a comforting green.

Continuous builds instead of meetings.

Wed, May 30, 2007
Lots of times I have been involved in lengthy discussions about how to solve a problem and trying to guess what the user really wanted based on his initial request. It is not uncommon that implementing all of the possible solutions and lettings the user choose the one that satisfies his needs would have been done in a shorter amount of time than discussing it. I’m probably rambling but if we have a continuous build, that is releasable, we could in many of these cases give the customer builds with all of the solutions and let the customer decide.

Installable daily builds and salesmen

Sun, May 27, 2007
I have quite often ended up in situations where the salesman has promised new or existing customer non-existing functions. Functions that took lots of overtime and ugly code to get done. When developers, more or less loudly, protests against this practice they are either laughed off or told they don’t understand the sales process. Quite often these forced solutions are not tested enough so the client isn’t satisfied anyway. Assuming you took my previous advice and created releasable daily builds, I suggest you deliver what you have at the moment and update with new functionality as it is done.

Releasable daily builds

Mon, May 14, 2007
Share and store documents… Free. When you do daily builds, a practice I think is essential for high quality software development, it is important to make sure the build is so complete and easy to find that the test team and sales force can choose what version, and when, to install by them selfs. It is an accepted truth that the longer you wait to fix an error the more expensive it gets.

Releasable daily builds

Mon, May 14, 2007
Share and store documents… Free. When you do daily builds, a practice I think is essential for high quality software development, it is important to make sure the build is so complete and easy to find that the test team and sales force can choose what version, and when, to install by them selfs. It is an accepted truth that the longer you wait to fix an error the more expensive it gets.

Broken builds

Fri, Feb 2, 2007
Nightly builds are almost useless if there is no collective responsibility to keep the code in a buildable state. Why should I even bother to make sure my code builds before checking in, when the build has been broken for a week and no one, who can/should do anything about it, cares? Is it the responsibility of the ones who do care to be a PITA, or should we take it upon our selfs to fix all error just because we care?