A Continuous Integration system is often considered one of the key elements involved in supporting an agile software development and testing environment. As a traditional software tester transitioning to agile environment, it became clear that we would needed several changes to make the transition to agile testing possible. This experience report discusses a continuous integration implementation I led last year. The initial motivations, technical specifics of the implementation, perceived benefits to the team, and retrospective results are all discussed.

Automating your build process with Continuous Integration is certainly a great idea, but why stop there? Why not go the whole nine yards and automate the deployment process as well? Staging and production deployments are typically more complicated and more involved than a simple development deployment, but doing them by hand can be time-consuming, tricky and error-prone. Indeed, turning your staging and production deployments into a one-click affair has a lot going for it.

Continuous Integration is a key practice in the agile toolkit. The practice is pretty simple - when checkins occur, some process is run against the codebase. This usually includes compilation and unit tests, but could include all sorts of things.

The panel of CI experts host discussion of the audience’s problems, questions, concerns and ideas about how to make best use of CI.

We aim to draw together the experience of the panel with the enthusiasm and fresh eyes of the participants to share our collective CI knowledge with those having issues with their CI implementations.

All projects benefit from high quality code but achieving the full benefits of agile approaches demands higher-than-usual software quality. A Continuous Integration build provides an ideal platform for applying automated tools to issues of code quality.

This tutorial looks at automated code quality tools that can be used to enforce or monitor code quality in Java and Ruby, and how they can be used to check quality manifested by:

• style enforcement
• lines per method
• methods per class
• code duplication
• npath and cyclomatic complexity
• test coverage