The importance of continuous integration
I am not 100% sure of the exact order of things that should be done when starting a new development project. But I do know that before you select file>new>project for any development involving more than one person there are several things that need to be put in place. Source control is somewhat obvious (though I am surprised at how many professional developers do without this necessity). Continuous integration should also be pretty high on the list. And when using any form of remote workers, in the same time zone or not, when communication might be somewhat sketchy - CI is a must.
I am a fan of TeamCity. But let me be clear that I didn’t get there over night. I have tried all sorts of tools for continuous integration. Many of them requiring some eye straining through a large pile of xml to get them running. But TeamCity is my go to CI tool for a company that can afford it. It just works. And if you are in a Microsoft shop, TC is easier than TFS, but provides some MS niceties like a nuget server. Jenkins is a close second.
But why do I need continuous integration you might ask?
Its simple really. Before I check in, I generally run my local build scripts. This at the very least builds my code and runs my unit tests. And it might run various other code quality metrics. But when I actually commit code there isn’t anything that ensures that the code I just ran through a gauntlet of quality bars actually makes it to the source control system as I intended. And what if I am on one of those teams that doesn’t have a local build script?
For that reason I need an automated tool to perform a get, and re-run all those quality bars, and then inform the world of the status of the build. This ensures that the poor schmuck that gets my shoddy work at least gets something that builds.
Not being able to get a stable build when getting latest - especially when working remote - results in some frustrated developers!
Back to trying to un-fuss the code I just got from getting latest…