Our VOB's currently have the feature level 5 and I'm tasked with upgrading to level 9 and making sure that everything still works. I've already read the technote from IBM about feature levels.
For feature level 7 it states:
Improved UCM performance
I somehow want to put this into numbers. Can someone give me a broad overview on how I could achieve that. Im relatively new to ClearCase and prior to ClearCase I only knew git so I would be thankful for some guidance
Yu can find concrete criteria for measuring UCM performance in:
the whitepaper "Component Organization and UCM Performance" (Richard Curtis, David Qiang Li)
the feature levels (similar to what you have seen)
From the first paper, you can derive the setup configuration:
Our test environment consisted of a VOB server host and a fixed number of clients connected by a 100MB full-duplex network.
The VOB server hosted one PVOB and one component VOB.
The component VOB was created initially with a single, root-level component.
In subsequent tests, the component VOB was created with one or more sub-VOB components.
The number of elements (32,768) remained constant, regardless of the number of components.
And the commands which are measured.
Non-UCM commands in UCM views:
checkout file
checkin file
setact activity_name
setact -none
mkelem file
UCM commands for developers:
diffbl -ver
deliver -pre -l -str -to
deliver -str -to -f
deliver -com -f
rebase -rec -view
rebase -com
UCM commands for project managers:
chstream -rec
diffbl -act
mkbl -inc
UCM commands for release engineer:
rebase -rec
rebase -com
mkbl -full -ide -com
Once you have an environment, and a script with those commands, you can run said scripts a few time before the feature level upgrade, then run the same script after, and measure the execution time delta.
Related
So Someone from my team has deleted some foundation Baselines from an Integration Stream and now when people rebase their development stream many of the folders and files inside them are missing.
We can see those missing foundation baselines in the development streams of that Integration Stream.
So I wanted to know how I can add those missing foundation Baselines from those dev stream to int stream, we only have access to IBM ClearTeam explorer to do it.
we only have access to IBM ClearTeam explorer to do it.
So you still have the CCRC CLI (rcleartool) (assuming the CCRC WAN Server is upgraded to ClearCase® version 8.0.0.3 or higher)
mkbl, however, is a cleartool command only (not rcleartool) in CC8, but rcleartool mkbl does exist for CC 9.x.
You could use that to recreate your fundation baseline, assuming you can tweak a (preferable dynamic or webview) config spec to select the right versions.
The baseline still exists, so you should be able to rebase the integration stream to re-add the baselines. You may want to describe the baseline to find the stream the baseline was created in to be sure you know everything you need to know about it.
rcleartool rebase -baseline baseline1#/vobs/mypvob,baseline2#/vobs/mypvob
Should be enough to accomplish the job. If your int stream has a successor baseline as the foundation now, and the component is not read-only in your project, you'll get an error message. The error message should tell you more about why you can't do the rebase.
In the industry I work in it's customary to do integration from source (i.e. compile all libraries from scratch). This means that the source code tree has to be configured to show the appropriate content.
I know that for binary integration there a lot of tools out there, tailored to the programming languages (Maven, CMake, Gradle, etc.).
We use base ClearCase as a source control tool. How does one go about implementing dependency management when integrating from source? In ClearCase I would imagine this entails setting up the config spec to select the required versions of all of the required files. Are there any tools out there that implement this?
Are there any tools out there that implement this?
Yes: ClearCase UCM, meaning not base ClearCase.
Building from different version of "components" (group of files) is why you have the notion of:
UCM components
baseline: a label applied on all files in an UCM component)
stream, which lists the exact foundation baselines you need for your program to work, or in your case, for your CI to take place.
Any UCM view on an UCM stream would generate the right config spec for you.
This is what a CI engine like Jenkins would use with JENKINS ClearCase UCM Plugin.
UCM does make this easier. But if your organization is politically averse to trying it, you can do a lot of the same thigs using base clearcase.
Streams are not much more than branches with additional metadata added on (activities, timeliness, baseline links, etc)
Baselines are essentially labels with more metadata. That metadata connects baselines to descendant and sibling baselines, and let's you have a baseline that maps baselines across components. It also links baselines to streams so you can't delete a baseline used by a stream.
You don't need UCM to do UCM-like things, it just takes more time and isn't as nicely encapsulated.
We have created multiple Development streams under Integration and also have one Deployment stream.
When the developer will do the changes and any one of the Dev stream and create the Baseline on Int, it automatically triggers rebase on Deploy stream, then build and deployment will happen.
The issue here is how do I know which development steam created the baseline when I have one deployment stream for rebasing against, with many Development streams for build and deployment.
Is there any command to find the latest baseline created and on which still the rebasing is not happened?
You have this I presume:
Int
|
-----Deployment
|
-----Dev1
|
-----Dev2
|
-----Dev3
You deliver to Int, then rebase to Deployment.
You know which baseline has just been rebased from Int (since a rebase simply replace the foundation baseline of Depl with one coming from Int)
But you don't know what that baseline on Int comes from Dev.
Simplest solution: if that baseline on Int is created each time one dev baseline is delivered: naming convention.
A proper baseline name can help you remember the dev baseline it comes from.
The problem with rebase is that, once you rebase on deployment, you don't know what was the baseline present on deployment just before the rebase.
That is why, in addition of a rebase, you need to update a metadata attached to, for instance, the Deployment stream object, in order to keep a list of the rebased baselines.
See as an example cleartool mkattr illustrated in "How to update the property for all member baseline in UCM?".
I have recently joined a team that has several applications that perform workload automation. They use ClearCase for version control but the development and test environments are (I surmise due to a lack of ClearCase expertise within the team) not checked out/deployed out of ClearCase but simply FTP-ed to respective Unix servers from Window. I said "simple deployment" because all the code is interpreted (Perl and shell) so no need to compile. Needless to say, many things are wrong with this approach, most specifically the lack of version management in these environments from the point of deployment onward.
So I would like to bind our deployments to the repository and start controlling changes but I am only a ClearCase novice. My specific question is: what is it that I deploy, a VIEW or a STREAM? I would say the latter cause views are user-specific while (according to my understanding) a stream is a project trunk off of each view is like a branch and views are integrated into their stream.
If anyone has any pointers on some useful yet succint and lightweight ClearCase tutorials for an "accidental" CM liason, please share.
Alternatively, if you think this task is suitable for Jenkins, despite being relatively simple (no build/compile involved) please chime in.
Thanks in advace
You would need to use the Jenkins ClearCase UCM plugin (in combination with Jenkins ClearCase plugin) in order to start jobs based on a ClearCase Stream
Jenkins will create an UCM snapshot view based on the stream you will specify in it.
See also, for more on the stream:
"Difference between branches and streams in ClearCase?"
"Integration stream vs integration view in ClearCase"
We set policy to force rebase before delivery if any baseline is recommended.
But we would not recommend baseline everyday. We will do it once in 2 weeks like that.
In between recommend baseline duration, people are often facing issues in functionality as they have not taken latest code base.
Is there any way to force to rebase before each delivery? [irrespective of baseline is recommended or not].
Is it recommended practice to rebase before each delivery?
It is recommended to rebase before delivering, and it usually is based on the "recommended baseline" mechanism.
So even if you said "irrespective of baseline is recommended or not", I would still suggest you look at "this deliver policy: 'Rebase before delivery'".
This policy (Require development stream to be based on the project's recommended baseline(s) prior to delivery) requires developers to rebase their source streams to the target stream current recommended baselines before they deliver work to the target stream.
The policy can be set per project or per stream, for interproject and intraproject deliver operations.
The goal of this policy is to have developers build and test their work in their development work areas against the work included in the most recent stable baselines before they deliver to the target stream. This practice minimizes the amount of merging that developers must do when they perform deliver operations.
From UCM policies:
If you don't recommend baselines on the parent stream, then you need to define a preop deliver trigger (as in this thread):
cleartool mktrtype -ucm -preop deliver_start -execwin ccperl "\\share\path\to\script.pl" -c "Check if rebase activity exists before delivering" rebase_before_delivery#\pvob
With script.pl a script which would list all activities of the current stream, checking if the latest activity is a rebase.xxx one.
http://www.ibm.com/developerworks/forums/message.jspa?messageID=14116547