Continuous integration versus delayed integration
A vigorous area of debate in the development and architecture community exists around the value of Continuous Integration . To give context, when a software development team gets to a certain amount of concurrent work that involves multiple teams making changes in the same codebase, there are two main ways to handle this: Each individual stream of work take a copy of the code and start working on their own Each team coordinate all work streams within the same codebase In my experience, the former method seems like a great idea, especially when folks start worrying about "what happens when project A impacts project B's timeline?". Everybody just works on your own feature and at the end of each team's work stream, just merge all the individual team's efforts back together in a shared location. The great advantage here is that if Feature A is pulled from the delivery, Feature B can be deployed independently. What is frequently overlooked is the fact that ...