Hi,
I have a system which works great for me.
I have serialized addition of development branches into the mainline
by using an integration view. I do nightly builds on the integration views.
I have a web interface through which developers can add integration branches
or lock the integration view to prevent others from adding integration branches.
After the developers branch is integrated, other developers are informed through
mail
about the integration.
Hope it Helps,
Prasad
"Sussmilch, John" wrote:
> Hi Julie,
>
> I encountered the same problems with my developers. Part of it is
> related to poor coding practice - checking in files that don't compile is
> something Configuration management is supposed to discourage.
>
> I have related our build procedures with our branching strategy.
> Basically, anything that could pose sufficient risk to the main
> developements' progress (Bug or PCR) is put on a branch off the integration
> branch. Simple changes can still be done on the integration branch by the
> developers, but they're encouraged to use the branches for the risky stuff.
>
> Our branching strategy is currently being trialed and appears to be
> working OK at this stage. The Integration branch is a subbranch of the
> system test branch thus :
>
> \main\acceptance\system\int
>
> All Developers have an integration view for their miscellaneous,
> unrisky stuff.
>
> If a PCR is approved with Clearquest, a branch is made via a perl
> script off the int branch thus :
>
> \main\acceptance.1\system.1\int.1\pcr_0339
>
> The perl script also creates a view for each developer thus :
>
> richardson_pcr_0339
> coulter_pcr_0339
>
> Then the developers simply map a network drive to the view created for
> them and they can work on that PCR.
>
> If a developer wants the PCR branch to be rebaselined, I do this for
> them via a perl script - shortly the developers will do this themselves as
> the script is pretty simple to run. There are issues with not being able to
> merge due to people having files on the integration branch checked out,
> although in principle, they shouldn't have stuff checked out on the
> integration branch for too long anyways (in practice, it's another story).
>
> When the developers are happy that a PCR is complete, I merge the PCR
> into the integration branch, check that it compiles and check in the files
> on the integration branch.
>
> When a build is requested, I ask the developers if any PCRs are ready
> to be integrated, and I integrate them.
>
> I then merge the integration branch with the system branch adn build off
> the system branch, attaching labels etc. The release package is then
> copied to a network drive for the testers to implement on their machine -via
> a shortcut on their desktop. This may be regarded as a waste of time by
> some people, however, I find it easier to establish changes made to files
> for a particular build in the version tree -i.e. I can see that formx was
> changed for build 50, but not for build 51 etc.
>
> When the code is ready for acceptance testing, I merge from the system
> branch to the acceptance branch. This hasn't been done yet, however, I am
> confident I can avoid the issue of the merge manager coming up for each and
> every file because of the amount of time since the system branch was
> created. When I resolve this one, the Code will be put into the main
> branch when the project is complete.
>
> When another project starts with the same code, the process continues
> with the following branching strategy :
>
> \main\acceptance.2\system.2\int.2\pcr_0449
>
> And the whole process begins again.
>
> The labelling strategy for the builds is as follows :
>
> CCCPPP-VP.A.S
>
> where CCC is the custoemr code, PPP is the Project Code, P is the
> Production(main) release, A is the acceptance release and S is the system
> release.
>
> I hope this helps to give you some ideas.
>
> With regards to the branching strategy, it has not been easy getting
> the developers to accpet branching and merging ( a couple of bad cases of
> merge phobia, I'm afraid). Having said this, when they see how automated
> it can be via the perl scripts, they have gradually come to accept it.
>
> Another point worth mentioning, is that the merge manager rarely comes
> up because the rational merge tool is superb. OIt does come up when the
> same lines of code have changed on different branches - this usually
> indicates duplicated developement, which again, is not to be encouraged
> either.
>
>
>
>
>
>
> -----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
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:25 EDT