It's interesting, because I've been wondering much of the same thing. This could/would be a very useful feature to much of us out there I bleieve.
On Mon, Mar 2, 2009 at 3:22 AM, Ruben Willems <[email protected]>wrote: > Hi > > > You should better forward this to the devel group, not all devels check the > user list as often( lack of time) > > but coming to your question : > This sounds indeed intresting, but it will requrie a few of changes I > think. > > Although some could be done with the current code of CCNet : > Your setup seems a lot like the one of CinnamonDonkey : look in the user > list for a topic of > Creating a build farm, Feb 25 > > he set's using CCNet to check a 'Master' > al developers code in their own branch, when they think it is ok, > they may merge it with the trunk, and battery of tests is released on that > patch > > So this sounds a bit like the thing you want, check out the thread ;-) > > with kind regards > Ruben Willems > > > On Sat, Feb 28, 2009 at 6:39 AM, Siddharth <[email protected]> wrote: > >> >> 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. >> > >
