"O'brien, Mark" <marko@UU.NET> wrote:
>
> Maybe you can run the script yourself to get the new file versions to use in
> the build. Then development only has to give you the SCR numbers when they
> are ready for a build
A successful method that I used in the past, we didn't accept SCR numbers outside of the
process. The developers were required to given them upon checkin, and we gave them a
list to choose from so they didn't have to look them up. It became easier to select
from the list than to send separate email.
>
> - As for files not being checked in -- there can be a "build" state
> development can move SCRs to when they are ready. So person moving a SCR to
> this state is responsible for ensuring all files are checked in. (Also, If
> you can eventually get them enter SCRs on checkin, you should look into
> having only one state, a dvlp state as example, for SCR to allow
> checkin/checkout)
Our solution was to prompt the user for the SCR numbers upon checkin. The defect
database was queried for open bugs assigned to the user that applied to the project(s)
affected by the checkin. Their edit session contained a list of bugs they were expected
to correct. (The number of bugs listed was usually small, so it was no big deal.)
After the checkin completed, the source files and version numbers were recorded in a
queryable table in the defect database, along with the SCR number to which the checkins
applied.
The handoff process inventoried the user's sandbox and queried the defect database for
all open bugs whose applicable file list was fully contained in the union of the handoff
set and those file previously handed off. If every source file required by a defect is
(or has been) handed off at a revision level at least as high as that recorded in the
defect database, then the defect's state is updated to reflect that it's awaiting a
build by the integration team. This new state is distinguishable from the "open" state
used by the above queries. The handoff also carried additional commentary, which could
detail how to use a new feature if there's no associated SCR.
>
> -- As far as the developers not wanting to type in a number or use the
> tracking (SCR) system. I would set up the pre-checkin trig to ask for it
> anyhow, but don't make it mandatory. Continue to make builds on LATEST, but
> add build audits/reports when builds are made ready for testing.
>
> In this build audit/report include such things these to highlight
> decrepancies:
> - list each SPR that has code checked in against it since the last
> build. Say something like the following SCRs have been addressed in this
> build and identify the new file versions checked in against each of these
> SCRs
> - list all other new file versions included. Say something like that the
> following file versions where changed for unknown reasons (Not associated
> with a known SCR) but have been included in the build.
We listed all files changed, along with the checkin commentary, plus handoff commentary,
plus defects that were handed off. Handoffs were done in such a way that each one could
be included or removed under control of the integrators, and the report was generated
based on which handoffs were included. There was also a breakdown by directory of where
failures occured. (Failures were dealt with in a civilized manner.)
After a succesful build, the associated defects were updated again to indicate that they
were ready for testing by Q/A, along with the build number.
> - list all other SCRs (that are not tied to file versions) claimed to be
> addressed in the build. Say something like that the following SCR are stated
> to be addressed in the build, but are not associated with any new file
> versions
Our process didn't allow this explicitly; but it was possible to update the file path
and version table by hand, and change the defect state to inject it into later phases of
the process.
> - Also in the build report, list reason for build. Say something like
> this is a normal build to include new SCRs, or a new build due to files not
> being checked in, or new build due to the last one not compiling, etc...
In our process, there was no distinction between builds. They were done nightly, and
the good ones underwent a promotion chain. They went from "nightly" to "stable" to
"production" to indicate various quality milestones.
> - Send the build report/audit to team leads, managers and testing/qa
> when the build is done (add this or incoporated it into what you currently
> do for notification of build completion)
Our build reports went to all members of the development teams for each project. In
addition, there was a complete summary (build success/fail, test pass/fail) was sent to
everyone.
This process was based on CVS as the version control system and Quintus WorkPro as the
defect tracking system. But it could apply just as well to ClearCase and other defect
tracking tools as well. (It's important to note, however, that the extra table to
associate files with defects is somewhat unusual and may take some work to implement
using most commercial defect tracking systems today.)
-- The CEO of my employer requires me to include the following notice in my signature:* This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. --- Paul M. Sander +1 650 261 5174 | To the medieval era's literate few..., the BroadVision, Inc. | turn of the millenium held a particular alure. 585 Broadway | After all, with the stroke of a quill, the Redwood City, CA 94063 USA | world went from DCCCCLXXXXVIIIJ to...M. | -- Rachel Emma Silverman, Wall St. Journal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:27 EDT