Hi Julie,
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
- 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)
-- 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.
- 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
- 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...
- 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)
Sometimes you have to document and show patterns of areas that need some
process improvement.
Basically, make it simple for development to associate SCRs with file
versions (preop checkin), but don't make it mandatory. Then do you best to
report on and document/audit the build. As you create this reports, people
will see the reasons why you propose things to improve the process. If your
report format does not a personal attack (obviuos or implied) on anyone, and
just reports on the facts/decrepancies for the build, being objective.
Hopefully management will see the benifits of what you are trying to do.
Once you get buyin for management/some of develepment (rarely will you get
all). You can alter your build report/audit to highlight
problems/decrepancies your next proposed small procedure will help solve.
Small steps at a time.
How that helps a bit,
Mark
-----Original Message-----
From: Julie Rudinski [mailto:julier@techapp.com
Sent: Wednesday, February 23, 2000 2:19 PM
To: cciug@Rational.Com
Subject: [cciug] Build Procedures/Policy
Hello everyone,
I was wondering if I could get some input on how everyone manages their
build schedules.
Currently we have a development branch which all the work is done on. The
developers check in their code when they are finished and when it comes time
to build I pick up the latest elements on the development branch. This has
caused a few problems with files not being checked in, and developers not
testing their code.
I want to enforce a more "strict" policy. My idea is as follows:
All changes to the code are related to a software change number and I
have a script prompting for the SCR# upon check in. An attribute is then
placed on the element. <This is the new part --> I want the developers to
submit the SCR# with a listing of all changed files (I have a script for
this, they just need to run it). Then I can build based only on the
submitted SCR#'s.
Unfortunately, the developers are adamantly against this idea because it
requires them to do extra work (running a script) and remembering to submit
their SCR's. (since I said non submitted SCRs would not go into the build).
So I am back to square one, building the latest elements which I do not
think is adequate procedure.
Does anybody have any suggestions?
I would appreciate it greatly.
Thank you,
Julie Rudinski
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:25 EDT