At my workplace we have a build server and I'm more or less responsible for it. It happens to be CruiseControl.Net but other build servers are available ;-)
Some of our more junior devs don't seem to understand why - to them it's just a spambot sending annoying emails whenever they commit code. Our testing team actually have Outlook rules set to delete these without reading them. So what purpose does it serve?
I thought I'd list some reasons:
1) First and foremost, you need a Source Witness. With today's source control systems(a)(b) you can't be sure that you've got the latest code on your machine. We use TortoiseSVN which pulls down source locally and then uses a merge model when committing. There's nothing to stop me pulling down code - leaving it for a year then editing it and compiling it locally. I can then attempt to commit it. If the code that I've edited doesn't conflict with what's on the server then the chances are it will commit successfully. So apparently everything's OK right? Well, no - not at all! What about all the other edits made in the year since I last pulled down the source. What about the entire WCF subsystem that Steve added last month? Just because I can compile MY version of the source locally it doesn't mean that the source held on the server compiles.
2) It provides a Heartbeat for the Project. OK so it's only one way of measuring progress, and it's fairly crude - I could just be moving whitespace about. But generally speaking, the more successful builds there are the healthier the state of the project. You might be working away for days making gigantic leaps forward - but if I can't see your builds how do I know that? Some guys construe this as snooping - I guess it's your point of view. But if I see no commits for a while it's an early warning - a chance to investigate potential problems. Better to know that someone's spinning their wheels (or "thrashing") on Monday rather than waiting to tell you on Friday...
3) As a Means of Deployment. We compile on the build server in Release mode rather than Debug - be honest how often do you try that locally? We also manipulate our AssemblyInfo files to contain a build label so that we can audit versions. We also use the server to create WIX installer packages and to run WSPBuilder for SharePoint packages - this means that Testers and Release Managers can grab the latest bits directly from the server.
4) You can hook up Other Gizmos. On our server we run NAnt, NUnit, NCover, FXCop, and Sandcastle. They give us some great extras - and who's got time to run them locally?
So there we are - my top 4 reasons for having a build server. There's a great article, on similar lines, here:
http://zutubi.com/products/pulse/articles/buildenlightenment/
And I hope you don't think it's so that I can nag people - I don't need a build server for that...
(a) Please don't say you're not using Source Control... don't make me come round there!
(b) And I don't mean SourceSafe, I mean something that supports collaborative working, such as SVN or TFS...
Some of our more junior devs don't seem to understand why - to them it's just a spambot sending annoying emails whenever they commit code. Our testing team actually have Outlook rules set to delete these without reading them. So what purpose does it serve?
I thought I'd list some reasons:
1) First and foremost, you need a Source Witness. With today's source control systems(a)(b) you can't be sure that you've got the latest code on your machine. We use TortoiseSVN which pulls down source locally and then uses a merge model when committing. There's nothing to stop me pulling down code - leaving it for a year then editing it and compiling it locally. I can then attempt to commit it. If the code that I've edited doesn't conflict with what's on the server then the chances are it will commit successfully. So apparently everything's OK right? Well, no - not at all! What about all the other edits made in the year since I last pulled down the source. What about the entire WCF subsystem that Steve added last month? Just because I can compile MY version of the source locally it doesn't mean that the source held on the server compiles.
2) It provides a Heartbeat for the Project. OK so it's only one way of measuring progress, and it's fairly crude - I could just be moving whitespace about. But generally speaking, the more successful builds there are the healthier the state of the project. You might be working away for days making gigantic leaps forward - but if I can't see your builds how do I know that? Some guys construe this as snooping - I guess it's your point of view. But if I see no commits for a while it's an early warning - a chance to investigate potential problems. Better to know that someone's spinning their wheels (or "thrashing") on Monday rather than waiting to tell you on Friday...
3) As a Means of Deployment. We compile on the build server in Release mode rather than Debug - be honest how often do you try that locally? We also manipulate our AssemblyInfo files to contain a build label so that we can audit versions. We also use the server to create WIX installer packages and to run WSPBuilder for SharePoint packages - this means that Testers and Release Managers can grab the latest bits directly from the server.
4) You can hook up Other Gizmos. On our server we run NAnt, NUnit, NCover, FXCop, and Sandcastle. They give us some great extras - and who's got time to run them locally?
So there we are - my top 4 reasons for having a build server. There's a great article, on similar lines, here:
http://zutubi.com/products/pulse/articles/buildenlightenment/
And I hope you don't think it's so that I can nag people - I don't need a build server for that...
(a) Please don't say you're not using Source Control... don't make me come round there!
(b) And I don't mean SourceSafe, I mean something that supports collaborative working, such as SVN or TFS...
Comments
Post a Comment