Nerd stuff..

I did a presentation/rundown of how I implemented Cruise Control for the rest of my team. I think it went well, but I wonder whether a lot of the information really gets through - I suspect a lot of people just vague out when the projector comes on. Again, the usual suspect decided to be negative about it - and not suprisingly, this person has worked at the bank for about 12 years.

Anyway, I will put the text of the presentation here.

Continuous Integration

What is it?
- A methodology for helping developers - Standard caveats apply.
- A way to keep the source as clean as possible
- Gives developers constant feedback

It is not:
- A blame-o-meter.
- A methodology for not documenting requirements thoroughly
- The be all and end all - Refer to point above about being a tool.

Why do it?
- Benefits
- Teaches developers to use Source Control properly
- Adds discipline to development teams
- Increases communication between team members
- Improves visibility of progress for TL/PM
- Improves source quality
- Reduced risk
- Quicker to produce something the client can see
- Removes hack-y work around for build and deployments (SoX!)
- Identification/fixing of bugs is quicker (small changes!)
- Drawbacks
- None! (Kidding)
- Some maintenance overhead, although once done, self maintaining
- False sense of security (no emails sent due to other problems, not broken build)
- Changes to existing working practices

How?
Build Cycle
- Build Server which is production-like
- Automated/Manual Build
- Short/Long builds
- Automated Deployment

Cruise Control
- Download
- Build CC
- Configure (simple XML)
- Multiple Projects
- Can use existing ANT scripts
- Notification emails
- Build CC Web App
- Deploy on any Servlet Container (Tomcat, WAS, etc)
- View in a dashboard like structure

Further Information:
http://www.martinfowler.com/articles/continuousIntegration.html
http://en.wikipedia.org/wiki/Continuous_Integration