home • products • solutions • support • resources • company • blog

home > resources > build-pain-relief > Best Practices: Team-based Streams

Team-based Streams

For large development organizations working on a single product, having smaller teams working only on their own code lines (ideally streams) can be an effective strategy of achieving small teams. To maintain the benefits of Continuous Integration, changes are regularly merged up to integration streams shared between several teams, and finally up to a common integration stream shared by the entire product team. AccuRev refers to this practice as Multi-stage Continuous Integration.

The odds of classic slow integration problems are higher in this case, particularly if daily integrations do not occur. That said, even if a few hours each week are devoted to resolving integration errors, teams using a stream approach will suffer far less from a simple bad commit than large teams not using streams.

Team-based Development Streams have a similar benefit profile to component-based development from the perspective of isolation (the third pillar of pain free building). Benefits to build speed (the second pillar) are only seen in the case of incremental builds, however. While components often trickle up the hierarchy automatically, once the team has a successful build, promotions between development streams usually involves human intervention.

This code-based promotion has its advantages. Individual change orders can be inspected, approved, and promoted to integration streams without bringing along incomplete features. But delaying integration of those other features, however, brings with it the standard penalties seen in slow integration models. Component-based development may be preferred to Team-based Development Streams, but often switching to a component-based system requires serious reworking of the applications under development, while Team-based Development only requires changes to process, and perhaps a source control system.