I attended the CITCON (Continuous Integration and Testing Conference) in Brisbane last weekend and had an awesome time discussing a range of topics with the most passionate in this field.

I have added my notes to the conference wiki,but my takeaways from the sessions I attended are:

Elements of Enterprise Continuous Integration

Jeff Frederick led a discussion based around the Elements of Continuous Integration maturity model:

• for teams that are already doing continuous intgration, it gives you a target to obtain
• is obnoxious after insane (where to for teams that are already at the top level)?
• tooling makes continuous integration trivial now (when Cruise Control was released many people thought it crazy that you might build on every release, not its a given)
• the model was developed because people assume what is possible is based around their personal experiences
• the model shows the industry norms and targets, and if your team is not at these levels you are behind the curve

The discussion branched out around the following ideas:

• scrum does not prescribe continuous integration, but continuous integration is a good development technique
• that it should be acknowledged that there is a difference between project builds and full product builds (which can take days)
• I raised the idea that perhaps there should be an element around team principles, and that things like performance (and more importantly, the team realisation that performance should be monitored and improved) should be an indicator to maturity (there was much debate about this!)
• a number of industries potentially have their continuous integration processes audited, such as defence, gaming  and financial organisations that have Sarbanes-Oxley requirements
• it was acknowledged that most large organisations have teams at different levels on the maturity scale (this is certainly my experience)
• dynamic languages and don’t really build or deploy. This then raised discussion that dynamic languages are not compiling as opposed to not building, and that in many cases one man consultants can manage their deployment process in a much more lightweight manner
• parallel to CMMI, is there a payoff to getting to insane?
• maturity is often determined when we move from dropping code to testers versus testing the development build (where testers are writing the code while the code is being developed)
• where is the line that determines that the build is complete? It should be the entire team, not just the developers or the QA team
• the QA team is traditionally where much of the auditing happens, therefore many testers are reluctant to change as they have built up processes to deal with audits over a number of years

For the record, the cutting-edge agile teams I have worked with over the last few years were at the following levels:

• Building (Intermediate)
• Deploying (Intermediate)
• Testing (Insane)
• Reporting (Intermediate)

We still have work to do!

Virtualisation & CI

I used the “law of two feet” during this session, but was interested to hear that many people are using virtualisation very effectively in their test labs, and that it makes getting environments and data ready for testing much easier.

Long Build Times

The discussion was well-established by the time I got to this session, but some of the key points for me from the discussion were:

• question as to when static analysis checks should be run in the build – the consensus that running them first means you get the quickest feedback
• longer builds should be run nightly so as not to hold up developers
• prioritising build queues or using different machines sounds like a good idea, but nobody is doing it
• you can reuse functional tests for performance tests, but targeting specific tests seems to work better
• Atlassian use JMeter for performance tests and have a variety of Maven and Ant builds, but use Maven for managing repositories
• Ant is still well regarded, Idea support is awesome, many people do not understand the power of custom ant tasks or the ant idoms
• the build should be regarded as part of your code
• discussion about using a Java build tool, such as Hammer and why we can’t articulate why it seems wrong
• not enough people understand Maven, usually there is “one guy” on the team
• Vizant is a good tool to graph the build
• EasyAnt combines all of the Ant idioms plus Ivy

Is Scrum Evil?

Jeff Frederick led a discussion that he is led at previous CITCON’s around the world

The team first debated why Scrum is Evil. During this discussion I really thought the whole agile movement was done for. Jeff asked the group to finish the sentence Scrum Is Evil because…:

• it becomes an excuse
• that’s not Scrum
• tested as a silver bullet
• hides poor personal estimation
• master as dictator, project manager
• two days to agile master certification
• daily standup equals agile
• agile by the numbers
• is dessert first
• you lose the baby with the bathwater
• Scrum teams don’y play well with others including customers
• it has certification
• is the new RUP

Jeff then proposed a way to think about Scrum adoption as outlined in Geoffrey Moore’s “Crossing The Chasm”. The early adopters had success while the early majority are putting their faith in training everybody as Certified Scrum Masters (a problem that appears to be a far greater issue in Europe than Australia).

Then, just as though all hope had gone, Jeff asked the group to finish the sentence Scrum is Good beacuse…:

• people can get it
• an easy introduction
• a good starting point
• it is better than a cowboy shop
• people can actually follow it
• improves visibility
• blockers are highlighted
• testers can start work early
• provides a forum for communication
• can engage customers in a much richer way
• states there should be a facilitator
• results focussed
• makes everybody responsible for end result
• better communication from end result

The key outcome by the group was “Scrum is not evil… people are evil”

This was a great way of trying to tease out the issues and advantages to using an agile process and one that we may be able to use in the enterprise with teams who have been on training but appear to be resistant to change.

Seeding Test Data

A good discussion about ways to seed test data

• Erik Petersen introduced the group to GenerateData.com, a free site that generates real adddresses and data based on factors a random amount of times that you can then inject into SQL – the site looks awesome!
• others in the group mentioned LiquiBase that can be used to version the database, is designed for database management but can be used to seed data
• Unitils is used to setup data scripts
• one suggestion was to build a reset database function into the system
• HSQL (Hypersonic) is a good way to create databases from Hibernate, in memory

The discussion got a little more generic and talked about:

• Roo, a java Grails-like platform
• WebObjects by Apple is a lot better than it used to be

Extending CI Past Traditional Dev & Release Process

I led this discussion, and whilst it focussed mainly on different usages that I have been involved with (with assistance from Paul O’Keeffe and Paul King), we also had a good discussion about Tableaux and the build process at Atlassian.

Conclusions

A great open conference attended by people passionate enough to give up their Saturday to talk about continuous integration and testing.