Hello ClearCase Community,
IBM Rational Clearcase Support would like to welcome you to the second Clearcase Open Mic conference call.
Date: Tuesday April 21st 2009
Time: 1pm-2pm Eastern Time
Topic: UCM Stream Strategies - Component vs Release Architecture
Conference telephone numbers:
Participants, Toll: 1-312-470-7379
Participants, Toll free: 800-988-9407
Participants, Passcode: 7097901
Confirmation Code: 3084629
Title: ClearCase UCM Open Mic call
This will be a phone conference only, there will be no accompanying webcast. The intent of this conference is to have a casual discussion with IBM Rational Support, to share thoughts, ideas, and information to enable all attendees on the topic.
This discussion will not cover future product direction or the status/progress on open RFEs, APARs or PMRs.
The conference will be moderated to keep the call moving and to appropriately triage issues/concerns to PMRs as needed.
Anyone planning on attending that would like to submit a question or idea for discussion beforehand, or anyone who cannot attend and would like a question or thought added to the discussion, please post here on this thread.
Every effort will be made to speak to all items posted here, time permitting, in the conference.
For additional detail on the Rational Open Mic Program please see --> Link: Rational OpenMic Landing page
Jay Morrissey - firstname.lastname@example.org
Kelly Drahzal - email@example.com
This topic has been locked.
12 replies Latest Post - 2009-06-10T17:48:40Z by SystemAdmin
Pinned topic FYI - Rational Support Open Mic - UCM Stream Strategies
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2009-06-10T17:48:40Z at 2009-06-10T17:48:40Z by SystemAdmin
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-08T13:59:13Z in response to JmorrissHello,
Thanks for the opportunity to discuss this topic.
Here are some suggested questions:
1. Each of our apps are single-component, managed by a UCM project per app. The integration stream is our mainline, and developers join with their own dev streams. We use an integration view to the mainline stream on a windows-based server for performing builds. Environment-specific configuration settings are managed by the ANT build. Frequent baselines (1-2x per week) are created to collect deliveries, and builds are sent to the QA server. Once QA passes, the same baseline is used to create a production build and then that is released when scheduled (2-3x per month). It should be noted that our apps are stable, and most of our work is small to medium fixes/enhancements.
MY QUESTION is: does this approach make sense in terms of best practices, and are there other, possibly better ways?
2. Our builds, while frequent, run very quickly so it does not take long to turn around an iteration and deploy a build to QA (15 minutes). While the build is scripted (ant/batch), kicking it off is manual, and then the build has to be manually moved to the server. Once on the server, we have scripts to kick off an install to Websphere. What would be the tipping point at which we should consider a strategy such as continuous integration with something like Build Forge or CruiseControl?
3. How do other SCM folks stay sharp on ClearCase kung fu (advanced troubleshooting/administration) if your shop stays quiet enough that weird things rarely happen?
4. Is there any real reason for a small shop (4-5 devs) to ever need to move beyond ClearCase LT to full CC, if snapshot views and the traditional deliver/rebase approach is working well for us?
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-13T17:41:14Z in response to SystemAdminExcellent Matt. Thank you for the submission and I will make sure your suggestions are put in front of the topic lead, Richard Robards.
Have a good day.
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-13T16:28:11Z in response to JmorrissTo help eliminate the 266 character path issue in Windows, we have a branch strategy where we create a Master project first, then seed a 1.0 project from the Master baseline. When branching to 2.0, we first deliver the last 1.0 baseline to Master, create a new Master baseline, then seed 2.0 from Master. With this approach, our developers are usually one branch off Master. We may have a patch project seeded off 1.0 or 2.0, but usually don't go further down from there.
1) When we deliver back to Master, would it be better to create a full baseline rather than an incremental? At what point is a full baseline better to use than an incremental?
We currently have about 40 PVOBs to break down our company into divisions of applications. ClearQuest has a user database for each PVOB. We are currently reworking this because the divisions of applications has gotten out of hand. We are reworking the division into about 8 business units for PVOBs and having one enterprise-wide ClearQuest database. We currently have about 650 VOBs with one application per project family and component VOB.
2) Will there be any issues over time having only 8 PVOBs for the enterprise?
3) It didn't seem to be a good idea to have one enterprise-wide PVOB. Is 8 better than 1? Or should we go with just 1 PVOB? Having one seems to be messy when users go to drill down at the project level.
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-13T17:43:47Z in response to SystemAdminHello Jim, thanks very much for the submission. I'll make sure the topic lead, Rick Robards, gets visibility to your post.
- Jay Morrissey
kellypuffs 06000168YK6 Posts
Tgefen 270000RX1Q713 PostsACCEPTED ANSWER
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-21T13:30:05Z in response to kellypuffsHere is my question. I hope it is not too late...
A few years ago, I wrote my reasons why multi-projects approach is better than sub-streams project approach (In general: you acquire more governance and compliance in the first approach). Since it was written when ClearCase 2003.06 was the common version in market, I'd like to know if things have changed during ClearCase 7 and 7.1. IMHO, it is just the same. I'd like to know your opinion in this dilemma.
My article: http://almmmm.wordpress.com/2008/04/28/multi-project
CM, ALM and IT
ClearEnv - Create your UCM environments in a click!
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-06-10T17:48:40Z in response to TgefenHi Tamir,
The points you make promoting component based strategies are accurate and they are indeed the reasons why most of us prefer to use component based architecture in UCM.
But let's keep in mind that some users cannot deconstruct existing legacy code into reliable components, and there are customers with smaller code bases that benefit more from release based architecture.
Both architectures are valid, both have their pro's and con's (as discussed in this open mic). So the only thing I'm missing is why you state that component based architecture is more compliant from a governance point of view. Both models are equally valid provided the rules of UCM are respected.
If you would like to discuss this further, please feel free to contact me at firstname.lastname@example.org
Thanks for your interest and participation in this open-mic
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-21T18:06:36Z in response to JmorrissJay & team,
Could you please re-list the 3 major types of project architectures you had mentioned at the beginning of the call? I joined in right at the end of that and didn't catch those.
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-22T11:34:07Z in response to SystemAdminHello Matt,
I've pointed Rick and Will to answer your question here on the forum.
Thanks for stopping in yesterday and for your interest in this topic.
Have a good day.
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-30T16:44:30Z in response to SystemAdminHi Matt,
The three major stream strategies are:
1. Release oriented: These typically have all or most components as modifiable and all developers can and will eventually work on all the code. The streams are setup such that they correspond to a specific release cycle. The benefit of this model is that it is the easiest to setup and get going without knowing too much detail of the code architecture. Additionally, the patching process is made simpler since the release engineers know exactly what stream was released to the field. The negative is that this type of architecture leads to a greater amount of history and metadata since all components are modifiable by all streams. The use of alternate target delivers will often make this worse by creating identical versions on the target. This architecture often gets slower as more and more releases are introduced into the system.
2. Component oriented: Sometimes called the producer/consumer model, this model has multiple projects and each project is specifically intended to modify a small subset of all the components. The other components are rebased in for read only. The advantage is that the amount of history and metadata is greatly reduced. Additionally if a producing project accidently creates a very bad baseline, then the other projects have the option to rebase backwards to the last known good stable baseline. The releases are not marked by any stream, but rather the promotion level of baselines from the producing projects. The disadavantage is that it requires a good deal of analysis to break up the code base into specific components that can be built individually. Additionally, any given developer might have to join multiple projects if he is tasked with modifying unrelated components.
3. IS/IT oriented: This could be either component-oriented, release oriented, or typically a combination of the two and makes use of feature streams for large feature implementations. The major difference is that the executables being generated are for internal in-house deploy...there is no customer base or sellable product. Typically, there is only one release of the software in production at any given time and since there are no other external users, patching is avoided and bugfixes always occur moving forward. There is no need to maintain parallel releases. The advantage is a reduction in alternate target delivers. Another advantage is the user base has a strong say in what should get implemented since there is less than if there was a multiple customer base.
The descriptions of these models and more detail can be found in chater 7 of:
Software Configuration Management Strategies and IBM Rational ClearCase
kellypuffs 06000168YK6 PostsACCEPTED ANSWER
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-21T19:49:00Z in response to JmorrissThanks to everyone who attended today's Open Mic on UCM stream strategies.
We had a great conversation with lots of energy.
We would appreciate hearing what you thought. Please feel free to leave your feedback here, or directly to me at email@example.com.
You can also send suggestions or requests for future Open Mic topics to the same email.
Re: FYI - Rational Support Open Mic - UCM Stream Strategies2009-04-28T12:11:20Z in response to JmorrissHello Folks,
Echoing KellyPuffs, yesterday's session exceeded my expectations. It was a great casual discussion with lots of questions and sharing of knowledge. Thanks to Rick Robards and Will Frontiero for leading the topic!!!.
Just to let you all know, the session was recorded and will be posted on the OpenMic Landing page --> HERE sometime in the next week.
Tamir, Rick and Will did answer your posted question above in the session, so you will be able to hear the answer in the recording. Happy
I've received a number of direct emails with excellent feedback and some suggestions for future sessions, Thank you!!. I have responded to each directly outside of this forum.
I've also received a number of follow up technical/topic questions to the session that I have asked Rick and Will to answer here in the forum.
Thanks again to all the contributions to yesterdays OPenMic and look for the next session planned for sometime in June on Install Manager.
Have a good day.