We Agilists talk a lot about the importance of Continuous Integration (CI) as a practice and we talk about it like it assumed; however, when adopting CI in what was a waterfall, iterative or undisciplined environment there will be a lot of hurdles to adoption that have to be planned as part of the CI roll-out. Here are just a few to consider:
- Is your code structured in such a way so that different sub-systems can be compiled and tested without the need to compile and test other sub-systems. If is isn’t you will need to refactor your code to remove the dependencies, create proxy classes, interfaces, and interface simulators for the dependent sub-systems.
- Is your code organized in the source code repository in such a way that you can check-out entire trees/directories and compile test? If not, you will need to spend time (task stories) to reorganize your code. Be sure to look for opportunities to separate business classes from helper, utility, and other common code.
- Are you using a source code repository that will even support the role of a Committer? If not, you will have to spend time migrating to such a source code control (SCC) tool. Why a Committer instead of everyone being able to commit code to the baseline? Simple, Code Committers are responsible for what actually is committed to the baseline. They perform such tasks as code-reviews, architectural compliance, and making sure the code conforms to style and quality standards. Think of it as a nice CMMI kind of practice that improves your product’s quality. You are performing peer reviews, right? What about overall code reviews?
Powered by Qumana
- SmartBear Software, Peer Code Review Pioneers, Expand Agility with CodeCollaborator 6.0 (eon.businesswire.com)
- Validating Code Rules in Visual Studio (codebetter.com)
- Agile Techniques: Continuous Integration Matters (devx.com)
- Martin Fowler on Continuous Integration (martinfowler.com)
- imabonehead: Hudson CI (slideshare.net)