Rather than be a flash-in-the-pan methodology, CI has become the underlying platform - the bedrock - that all the trendy methodologies have been built on for the last 10 years including Extreme Programming (XP), Agile, RUP, Scrum, etc. If your methodology isn't Cowboy Coding - and I mean the classic definition of cowboy coding - a lone developer or a handful of developers acting alone practicing anarchy for argument's sake: "your rules stifle me!" - I bet your methodology has most or all of the continuous integration basics at the bottom of it.
The industry book definition of CI has it defined as a handful of best practices -
- Using a source code repository system
- Everyone gets latest (code) on a frequent basis
- Frequent commits
- Every source code commit generates a build*
- Build automation
- Build fast (and fail fast!)
- Build results should be public
- Automated unit tests in the build
- Test environment should mimic Production environment
All of these best practices can be compared to and validated against the boiled-down idea of "a small iteration - a small complete effort - increases the quality of a larger effort". If these pieces of effort don't pay huge dividends by the time your project is hitting its stride, let alone its delivery date, then simply remove that practice from your playbook. CI shouldn't be stifling or handcuffing the developer - everything about it is about improving the quality of the software being engineered, this is not about a Configuration Manager or System Administrator power tripping.
For the next few blog posts, I want to just write up some basic articles on constructing & running a CI environment for a work group or entire shop developing in .Net but isn't using TFS* (Team Foundations System), and I'll be mainly focusing on the art of the msbuild file and how your entire CI architecture can and should be seen in the way you craft your msbuild scripts.
* Maybe you don't use TFS because you're the lone group in your company doing .Net, and you can't get the budget for a TFS farm, or maybe you are required to use source control system XYZ for regulatory purposes and TFS isn't going to happen for purely technical reasons.
None of the other posts are going to be as wordy or philosophical as this one - I promise they will be short and straight to the point. They are also all works in progress - they are the best practices I have today - I not only can't guarantee they won't evolve in a year from now, I certainly hope they will.