Wouldn't it have been easier to enforce a policy where all developers must
do their work on a private branch and, when they deem their work ready for
submission, they must merge it to the nightly build branch?
Advantages:
* Developer is still responsible for deciding when to submit and doing
submission.
* If necessary, build branch can be locked against developers until the meet
submission guidelines (for instance, unit test logged and passed).
* Nightly build uses simple config-spec that picks up latest code on the
build branch and locks the build branch while build is going on.
-----Original Message-----
From: Krishnan Srinivasan [mailto:Srini.Krishnan@nmg.sms.siemens.com
Sent: Wednesday, February 23, 2000 12:44 PM
To: 'Julie Rudinski'; cciug@Rational.Com
Subject: RE: [cciug] Build Procedures/Policy
I had the same situation. My policy works great, and the developers are very
happy with this scenario:
- Enforce a "submission scheme" to the nightly build. i.e., every identified
component will have a submitted label (say, COMP_A_SUBMITTED). Then, the
responsible engineer will label the code of the component A with the
submitted label.
Advantage of submission scheme: the developer decides when his/her code is
fit for going into the build/foundation. you dont need to worry about
whether that code is tested or not..
- Before you start your build:
1. set the config specs pointing to the set of submitted labels (I have
this automated in the build script in such a way that config specs is under
version control, so that I can go back to any old build)
2. lock these submitted labels (so that no one submits anything new when
the build goes)
3. Perform your build..
4. ci bins and label bins and src with a build label (which later
becomes a baseline label during releases)
5. unlock the submitted labels for next build submission
As vobadm, one needs to worry about growing size of bin location. For this,
I keep only last (say) 5 build binaries and delete the previous versions of
the DOs.
This works great for me. no hazzles!
good luck!
-Krish..
-----Original Message-----
From: Julie Rudinski [mailto:julier@techapp.com
Sent: Wednesday, February 23, 2000 1: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:26 EDT