Now that we covered the developer practice (at least to some extent) in the first part we can now take a look into the large-scale view of Continuous Integration. As a developer practice CI does have clear benefits but those benefits might be limited when development is done in large-scale with masses of developers are working on several new features at the same time. Development team’s capability to build and test the complete system with good enough coverage of all test areas with any reasonable effort can prove to be very challenging.
Large scale regulated industry, complex system, add embedded software to that mix, and you get a monster that requires some very expensive and long lead time testing. But you still want to get the advantages that CI offers? It can be done but not without some adjustments in organization. Most of the organizations want (need) to adapt CI as their development practice but there can be some blind spots that are not considered as the central ingredient in the change. The silos emerge.
BTDT? (been there done that) ?
Developers develop, integration integrates and testers test. Most preferably in a waterfall mode with manager to manager meetings deciding when to deliver, what to deliver and argue about delivery quality (quality doors etc). All the actions for development teams are mandated by different managers managing different silos. Long term isolated feature branches, integration issues are a norm, stabilization periods and bug tracking/mapping hell. Finally close to the project deadline I&V or whatever final test function there might be, makes development aware of some serious issues with the product quality and long lead time troubleshooting is expected.
Even though assumption is the mother of all f-ups, I still assume one thing. Since you are reading this blog post about Continuous Integration you are familiar with agile and lean.
When looking at the seven Lean Software development principles it can be noticed on how many levels they encourage the use of CI as a development practice:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- See and Optimize the Whole
Organizational setup needs to support this in a way that development teams have the possibility to integrate often and get feedback from complete system level tests rapidly and continuously during the development. There shouldn’t be some entity that the software is delivered to for testing neither there shouldn’t be any test areas that are executed only near the deadline of the project. Janne covers a lot of this team setup aspect in his recent post about agile test strategy and structure.
There is one more big bang that cannot avoided when going for agile / lean and implementing Continuous Integration in large-scale, the organizational one.