Shashi Velur’s blog

All the individual products in our organization use continuous integration development practice. However, all the products are built by different teams (with different skill-sets) under Sprints that do not share the same boundaries.

Some of these are complete products by themselves. They also are bundled together in a suite and so require integration testing. How do we apply continuous integration practice on a grand scale to this problem?

We ended up making these decisions:

1. The individual product team (with “inward” dependency) shall take the responsibilities of writing/maintaining the integration test cases.
2. We decided to push the individual product builds into this environment every week, mostly and also have the flexibility of being able to push the builds on demand, if necessary.
3. Start with a basic set of integration test cases and build upon them to keep it simple/Agile.
4. Start with manual steps to deploy these individual product builds into the integration environment and then slowly build a set of scripts to automate this.
5. Eventually, we should have a “push-button” integration environment where individual teams can push a button or set up rules to promote their builds in to this integration environment.
6. Decide that all teams should eventually move to a single source repository.
7. Initially, to keep it simple, all of the individual product teams will push only binaries into this environment.
8. We agreed upon a simple defect tracking process for reporting/escalating integration testing bugs.

Technorati Tags: Continuous Integration, Product Development