I'll read up the earlier mails on this and write up some specifications. One more thought
So the story goes like this. The Build Manager sets up the build schedule with a rule "Approval Mandatory/Desirable". And on the build notifications a message goes out, "This project is under strict change control, all code changes will be reviewed before the checkin. List of Checkins with Defects/DefectSummary/DefectDescription/Links to the defect (all on one page). Build is expected to start on HH:MM:SS:DD:MMM:YYYY. Approval is mandatory before the build starts. OR Approval is desirable before the build starts. We start with integration with the simplest of defect tracking tools and then integrate more on the matrix. How do you like that ?? Siddharth On Mon, Mar 2, 2009 at 9:20 PM, Darren McDaniel <[email protected]> wrote: > 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. >>> >> >> >
