A large part of my job is doing two things:
- Install continuous integration
- Add coverage reporting
To this end, I have developed a strong toolset using:
- Continuous Integration
- NCover (version 3!)
- Test Coverage Reporting
- Source Control
- Agile Project Management
I’ve found these tools to offer the maximum amount of flexibility for any engagement. Together, they can handle just about any process workflow.
My workflow currently looks like this:
Coverage reporting from the CI server is probably the most important metric a development team can track. It’s the proof (or lack of!) that the code is working as expected. For new project I demand 90% “branch” coverage or greater. For legacy code, 70% is good. Branch coverage is conditional logic in your code. These are the business rules and where most defects are logged.
I find that a 90% covered project will have 4x more unit test code than production code. This is great! It’s nearly impossible to introduce regressions into systems that are so well tested. Finding these regressions early reduces the Dev->QA cycle time.
Jenkins is wonderful at allowing you to fail the build if a metric falls below a threshold. I fail builds for the following:
Code coverage drops (at all!)
- Compiler warnings are added
- Code duplication increases
- Unit tests fail (at all!)
Once a developer checks code in, Jenkins runs the build and publishes metrics. It’s also great for public shaming. Everyone is emailed if the build breaks.
Jenkins then logs the commit and build result into Rally. From there, I can see all the commits associated with a story. Once a developer marks a story complete, it’s easy to code review right into GitHub.
Building a good CI system isn’t trivial for the inexperienced. It now takes me about 2 days to build a system if I’m dealing with a decent codebase.
- A good CI system will discover bugs early
- High code coverage will discover regressions defects early
- A good process will allow you to perform code reviews easily