Continuous Integration is an interesting concept no doubt. It is what PM's want. Build and Integration time is seldom assumed on the critical path of any project. What is assumed is integration will be smooth and seamless. Both of which depend on the maturity of the team and the product.
More than just seamless integration, projects need to be "controllable" towards the end. And this control should be configurable to enough to ensure no loss to productivity. The other side of the same coin is too much process can over burden the project. But, process is meant to be customized to ensure that the burden : benefits ration are as less as possible. Now, coming to my point. A integration infrastructure needs to have a controlled checkin process. A control checkin process should be linked tightly with the build start time. It should be possible to specify a date from when the controlled checkin will start. From this day onwards, every checkin, should be approved by a user/group (commonly known as a change review board). The review will be based on defect, reproduction steps, code changes, fix changes (code and ANY change), unit test review comments, people involved (lines of code changed, should not be a metric here, makes no sense anyway, since we have the actual code that we need to review before the checkin). A end time should be defined for this approval/review process, beyond which the auto build process will be delayed. OR we should be able to configure approval/review process to be desirable (or mandatory). If a approval / review process is active the communication on the dashboard should reflect the results. Approval/Review process summary should be displayed along with the build results. Build conducted with (in green) / without (in red) the approval/review process. Summary of Approval / Review by change control board - total_checkins - reviewed_checkins - approved_checkins - disapproved_checkins - risks mitigated (by the change review board) - textual communication to the team - risks taken - textual communication to the team - assumptions made - textual communication to the team - Final Decision (Build Safe / Build At Risk / .... some more.. ) If this is a interesting idea, I am willing to work closely with the implementation team. Please comment.
