alm Questions

By Mani P - April 12, 20131 Answer

We have some need to allow self-registration with ClearQuest for some database. We have integrated CQ with LDAP. Appreciate your ideas on the same.

One way i thought is too have link in CQ startup screen for self-registration which will get all relevant info from user and via perl create new account in CQ.

By Bob Aiello - March 10, 20137 Answers

Hi everyone,

my esteemed colleague Marc Bools and I have started working on bringing back the CM Wiki and we want you to help us with the design and requirements of a new CM Wiki!!!

Here is a hight level list of the topics from the old wiki. This is your chance to help!!

Topics you will find in the CM web 


  • Configuration Management 
  • Software Configuration Management 
  • Build Management 
  • Change Management 


  • CM Tools - Software and tools for Change and Configuration Control - HCM/SCM 
  • CM Integrations - Integration of CM tools with other tools 
  • Frequently Asked Questions 

Concepts and theories: 

  • ConfigurationManagementBodyOfKnowledge (a.k.a. CMBoK ™) 
  • CM versus SCM - Thoughts on the differences between the terms CM and SCM 
  • CM Metrics - What you could gain in time and money when using CM. 
  • CM Metaphors and Analogies -- metaphors and analogies for describing CM 

Processes and practices: 

  • Agile Development and Agile SCM - Ideas on Agile Development and how it affects CM 
  • Configuration Management Process 
  • Change Management Process 
  • Branching and Merging for Parallel Development 
  • CM and Web Engineering 
  • CM and Databases 

Templates and Examples: 

  • CM Templates - Quick templates to help you start implementing a CM solution 


  • TBD 


  • Suite Vs Best Of Breed 
  • SCM Readings - Some recommended SCM books and papers 
  • History of CM 
  • WhosWhoInSCM  

Starting points

  • TBD 

What other topics should we include?? How do we provide more value from our new and improved CM Wiki.

Drop me a line and get involved!

Bob Aiello
Editor in Chief
[email protected]

Hi everyone,

as always we love to get YOUR input on which topics we should be covering in the coming months. 
Obviously, DevOps is hot, Cloud & Mobile are essential. We have had many issues dedicated to CM for Small Teams, Process and more process and tips and strategies for Build Engineers.

What topics would you like us to cover? What topics would you like to write about yourself??
(Hint - I will help you! - just contact me directly)

Bob Aiello
Editor in Chief
[email protected]

Hi Everyone!

this is a great time to get involved with CM Crossroads by submitting your own articles on software and systems development. CM Crossroads has always had a strong focus on Configuration Management within the full software and systems lifecycle and this means that we are interested in articles on a wide array of topics. Contact me directly to get involved with submitting your own articles and I will help you with getting started, forming your ideas and editing your article for publication.

Common topics include:

  • Build and Release Engineering
  • Source Code Management including branching and streams
  • Deployment Engineering (DevOps)
  • Development in the Cloud
  • Configuration Management (including the CMDB)
  • Continuous Integration and Deployment
  • Environment Management
  • Change Management

    and much more! 

    Bob Aiello
    Editor in Chief
    [email protected]

Many of us support automated Windows installation. I have used MS Build for some time and most recently got to play with ClickOnce which is great. But what about legacy Windows applications? Do you still use Wise or InstallShield? What are the best practices and best products for supporting legacy windows application installation?

Bob Aiello
Editor in Chief
twitter: @bobaiello, @cmbestpractices

How does everyone like the new CM Crossroads website?

Bob Aiello
Editor in Chief

We are a small IT company developing a variety of IT products. I want to incorporate best practices into our product lifecycle management (PLM) process


Can anyone shed some light on best practices of when / where/ how to establish the scope of the Release in the Agile Development Lifecycle model?

Our problem seems to be that we can never get to the point when we can nail down what the scope of the release is. When we do, it seems to be last minute and I am sure that this is not the best method for testing.

I recently assisted a presentation of Rational Team Concert, and I am shocked.

It could have been, I am sure, some other product. I don't intend to bash RTC.

Only, here is a large vendor which spends large amounts of money (I assume) to produce something I believe and I hope can only be a terrible flop. Nobody will buy that, will they?
Only, they won't buy it for the wrong reason: because it costs money, and the market of ...CM/SCM/ALM/whatever has now gone such a way that nobody will anymore pay anything for that. Everybody knows that whatever allegedly useful there might be in that domain has to be free (like beer, not like speech).

No, my problem is elsewhere: this big company must have targeted a potential customer base, and beyond that, well, somewhere *users*. But who would *use* that?

It is the answer to that question which is frightening.

Pseudo-management. People who would be completely helpless faced to software development, yet in a situation of having some hope to survive this obvious fact in the context of some organization.

The kind of tools I am talking about is meant to hide incompetence, by creating a virtual reality from quantifying the activity of others (developers?) without needing to understand anything of what it consists in.

There are several problems bound to this.

This is not only useless, but lethal. It creates a reality made of amounts of resources, of milestones, of names, of tokens of various kinds, of percentages (passed tests ratios, coverage, numbers of lines of code changed, etc.), which takes precedence over the primary reality made of semantics and of symptoms. It eventually makes it impossible to analyze issues, to fix code, to discuss the compatibility of options and the propagation of changes.

The ultimate problem lies in the paradox that organizations which could put such a dangerous amount of power into the hands of structurally irresponsible people do not seem to fear facing quick bankruptcy. Quite on the contrary.

Stalin has come back?


Below are some observations I've made and I'd like to solicit the communities feedback on the conclusion I've drawn from it.

When looking at industrializing software development by creating a fully integrated and automated pipeline through which changes flow from check-in, through integration, build, testing, packaging and deployment; there are 2 paths one can follow:

1) Buy and implement a single vendor solution that covers the whole pipeline from check-in to deployment, the main drawback with this option being that most of the tools that make up the pipeline will do an OK job, not great, not the best in the industry but they will get the job done. Secondly there is the tie-in to a single vendor which is often perceived as a thorny issue because of the usual what-ifs and the constraints on customization of processes, tools etc.

2) Buy individual 'best of breed' tools to cover each of the stages in the pipeline and integrate these tools with your own resources. Creating this integrate pipeline with your own resources will take time, most likely a couple of man years to get a fully automated pipeline in place and then there is the support. Second because of the less than 'uber' tight integration the value of all the tools together is less than the sum of their individual value.

The above observations bring me to the conclusion that there isn't that much to be gained from buying the best of breed tools for the individual areas, sure you will have the most powerful tool for this and the other, but in the bigger picture that value won't be that noticeable. Just like a single vendor solution won't give you the best pipeline just because it's fully integrated as each of the stage which will be performed OK.

At the end of the day the value you will gain from both paths will be more or less equal, some areas will be better in one others will be better in the other.

What do you say? Did I miss something obvious?

- Antoni


CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.