CITCON Australia/New Zealand 2010 – Day 2 (Part 2)

30 Jun 2010 CITCON Australia/New Zealand 2010 – Day 2 (Part 2)

Session 3: Build In Enterprise, Ant, Maven, Dependency Management

• Better builds with Maven has misled a lot of developers, it encouraged bad practice of using child modules. It was suggested that the book should be renamed to ‘Broken builds with Maven.’ There’s a new Maven book being written about using Maven the right way.
• Good thing about Maven is that it encapsulates procedural steps in a declarative manner.
• Teams that use Ant successfully tend to employ a certain level of standard and convention.
• Easy Ant – Ant with standards.
• If Ant works for you, there is no reason for adopting Maven.
• It’s always easier to figure out a Maven POM rather than trying to understand an Ant build script.
• Build is never easy, it looks easy, but it’s not.
• You want everyone in your team to be able to modify code, but you don’t want everyone to modify build.
• You shouldn’t avoid maintaining build script, the technical debt will be too much at the end.
• The quality of artifacts available from Maven central repository can be improved by enforcing tests to be part of the development culture, a la Perl testing and CPAN.
• Maven central repository needs to improve metadata quality, lots of broken POM.
• There’s an opportunity for an open quality dashboard system in continuous integration marketplace.
• How you build your product is often part of the audit process, specially when another company wants to acquire your product.
• Sonar is handy to calculate your technical debt.
• Crap4j measures code quality using an algorithm.
• Avoid setting latest/SNAPSHOT as a dependency to avoid crap release creeping in to your build, use version or version range.

Session 4: Continuous Integration Tools

• The pricing of CI tools can be roughly grouped into developer budget (i.e. free ones like Hudson, CruiseControl, Luntbuild, Buildbot), manager budget (i.e. not free but not expensive like Atlassian Bamboo), and director++ budget (e.g. Anthill Pro, IBM Rational BuildForge).
• The price gap between manager budget and director budget is pretty wide, this is because you can’t sell moderately expensive software.
• Interestingly, AnthillPro finds projects which already use Hudson to be a good starting point to migrate from.
• Deployment should be scripted, use the same script for all environments, use the script as early as possible (in dev environment).
• When you have any doubt about Hudson scalability, add more slaves.
• You’ll be surprised at how there are still projects out there without any proper build script.
• Git bisection is handy to identify point of failure and rollback.

Session 5: Continuous Deployment

• IMVU deploys to production fifty times a day.
• Flickr deploys 10+ times per day.
• When you deploy to production on each commit, you care less about zero defect, but you care more about having really good tests. And if there’s a defect, you handle each defect exactly once by adding more tests around the defect.
• Deploy on commit allows developer to concentrate on changes in small, more manageable, chunks.
• Feature flags give you the opportunity to push bug fixes to production with half-baked new features disabled. You can then enable those features in the future when they’re ready.
• Feature flag is also handy for doing A/B testing
• Deploy straight to production requires more care when there are database changes involved, specially on backward patch.
• Continuous deployment is not to be confused with cowboy development. Cowboy development is not about the frequency, but more on the lack of quality. Continuous deployment care about having good tests.
• Large corporate culture of having management signing off every little change can be a blocker to employing continuous deployment. One solution to this is to have the management sign off the process, instead of the change itself.
• Continuous deployment is not for all projects. It won’t work for legacy system lacking good tests. It won’t work for projects with large data that requires time-consuming post-deployment processing.
• It’s questionable how well the concept of continuous deployment is going to work in finance industry where a single error can have a legal implication.

Day 2 ended with a retrospective session where many of us highlighted how well the open space format worked, and how good the quality of the discussions is. My favourite sessions were the ‘Evolution of Agile and Continuous Integration’ talk facilitated by Jeff, and ‘Continuous Deployment’ talk facilitated by Nigel McNie. I learned a great deal from those discussions, I had my a-ha moments, and there were a number of ideas I could pass on to others in my organisation/team.

I believe that the main reason why open space worked really well was the participants, everyone who was there, they were there because they cared, and somehow the level of passion was higher compared to other events I attended in the past. CITCON rocked!