>From my experience there is a learning curve in any company. It just takes
some time for everybody to get used to the powerful features of CC.
It does help if an experienced CC admin is hired who can wholeheartedly say
"I've done it this way and it works". Management buy in and buy in from the
core opinion makers (usually some senior techies) is another important
thing.
On one project, we went from pretty much total chaos (CC installed, nobody
trained, looming deadlines) in the first version, to a quite orderly system
now, in the 3rd & 4th version. The chaos early on made people quite open to
any improvement, but I also found out that any process has to be supported
by scripts and triggers. So usually it's a thing that grows, because the CC
admin can't just whip up these scripts and triggers and it is very hard to
change project policies midstream in the development cycle.
I also found out that once a product is out in the market and needs bugfixes
and high quality releases, all of a sudden everybody is screaming much more
for automatic tracking of bug numbers and changes.
So, you'll have to look to where and how you can make things easier, get buy
in, get time to automate it, roll it out. I suggest you do it in smaller
increments, so everybody gets used to it.
I have everybody very comfortable now using labels and basing their builds
on the last official build label. Also everybody puts their bug number in
the HOC and a tool gets it out of there, to generated a list of bugs fixed
per build. We still have major cases of merge phobia, but also some people
requesting to work on user branches for development of new features. So word
gets around that a CC merge is pretty painless, reliable and stable.
Martina
Don't Postpone Joy - Have Fun
Martina Riedel Siemens Information and Communication
Networks
phone: 561-997-3774 Martina.Riedel@ICN.Siemens.com
<mailto:Martina.Riedel@ICN.Siemens.com>
-----Original Message-----
From: Sussmilch, John [mailto:jack.sussmilch@compaq.com
Sent: Wednesday, February 23, 2000 3:26 PM
To: 'Julie Rudinski'; cciug@Rational.Com
Subject: RE: [cciug] Build Procedures/Policy
Hello all,
Something else worth considering is that if you have all
developers working
on teh smae branch (i.e. main or integration), and you're
using dynamic
views, as soon as someone checks in something thayt doesn't
compile, they
break everyones code, which I have found very effective in
encouraging the
correct procedures before checking in -believe me when I say
it only takes
once or twice for a developer to do this before either they
become extremely
unpopular with their peers and management or they get their
stuff sorted
out. As soon as the developers were happy with this, I
implemented the
branching strategy in my previous email.
-----Original Message-----
From: Julie Rudinski [mailto:julier@techapp.com
Sent: Thursday, February 24, 2000 8:19 AM
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
with
body
can also
unsubscribe
customers-only
website
http://clearcase.rational.com/cciug/mailing_list.html
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:26 EDT