If I understand this correctly, here we have a system where the build is done first and then the real build goes thru a set of rules for a checkin approval process.
To me (as a PM) these are 2 different things. The first is part of unit testing, quality. Where every dev has teh resposibility to ensure that his code builds. I think we call this the "buddy build". This is part of the process.This is a what we do regardless of the phase of the project. The checkin approval is very different than the above, here we call for a lot of control and communication. One slip here and the project is delayed for build (something that PM's JUST DONT ACCOUNT FOR hahaha). This "REAL BUILD" is what (as a PM) I care for. As a PM, I want my team to be able to review (in a automated way, no manual steps so error's are lesser) checkins getting into the build. I want the build system to in a automated way show me the list of checkin's and the code associated with it. Normally in these review meetings we also review the defect description, reproduction steps, environment, workaround, priority....It is possible for PM's to instruct dev's to associate the checkin with a defect number. It is also possible for PM's to instcut dev's to fix only one defect per checkin (not to club multiple defects in one checkin). The build system should send out a "cutoff" time for the approvals to the PM team, and the link to the approval details. Any delay in approval, the build would be halted (and sometimes build managers just say if you dont give me the approval until 2am, I will leave for home :)). Now the above is for waterfall projects (more than 90% market, not that im happy about it). My thoughts are more "starting with the end in mind". Siddharth (Ruben, I have still not read CinnamonDonkey, I will today and share my thoughts). On Tue, Mar 3, 2009 at 1:22 AM, Darren McDaniel <[email protected]> wrote: > thats what we're looking for... Much like a "Code Move Approval Process" > Our thoughts were to have two ccnet boxes.. one that always built on changes > and fired an email off to the user when the build was done > (successful/failure/etc) and a second that the build team could set a flag > that does the 'Real Build' So what you are suggesting would be pretty near > what we would require and could easily integrate something (via API??) into > our system > > > On Mon, Mar 2, 2009 at 12:15 PM, jonty s <[email protected]> wrote: > >> 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. >>>>> >>>> >>>> >>> >> >
