Developing different projects with CM Synergy.

[Daniel Watford]

Hi all,

I'm fairly new the the configuration management domain. My past experience
has been pretty much limitted to version control (using CVS and Versions
from Starteam).

At our company we purchased Telelogic CM Synergy. I've been looking at it
to try and find out how we may best use it within our development
environment.

We are a R&D dept with 6 engineers (software and hardware). We always have
lots of different projects on the go. Each project was represented in
Versions as a different repository project.

I would like to use cm synergy beyond basic version control and use the
configuration management facilities to assign tasks to individuals (as well
as the other benefits that come with cm).

With cm synergy this is possible if all data is stored in a single
database. However the downside seems that we then need a means of
identifying the product development that an object belongs to. (I didn't
want to use the term, project, since synergy has other meanings for
that). As far as I can tell an object is marked as belonging to a
particular product by assigning an appropriate release value. This means we
would need to use appropriate release naming conventions within the
database and I am worried about the list of release names growing very
fast.

Does anyone use cm synergy in a similar environment (many different product
developments all within the same database), and if so how do you group
objects into their logical product development?

Many thanks,

Dan

--
Daniel Watford

[Frank Schophuizen]

> With cm synergy this is possible if all data is stored in a single database. However the downside seems that we then need a means of identifying the product development that an object belongs to. (I didn't want to use the term, project, since synergy has other meanings for that). As far as I can tell an object is marked as belonging to a particular product by assigning an appropriate release value. This means
we would need to use appropriate release naming conventions within the database and I am worried about the list of release names growing very fast.

Don't worry about the size of the list of release values, it WILL grow very
fast for certain. It will probably cause a lot of confusion especially if
you also use it to identify releases, unless you define a proper naming
convention.

Confusion you will get anyway:
- release value is used to identify projects
- release value is used to identify releases within projects
- project in cmsynergy is not a project but a directory structure
- tasks in cmsynergy are not tasks, merely changesets (i.e. they can not be
managed by a Gantt chart)
- the number of tasks will grow until it is more difficult to manage the
tasks than it is to manage files (for object-based approach)
- performance will drop dramatically the longer you use cmsynergy. We
require over 2 hours to create a baseline, over 4 hours to do a DCM generate
(delta of 1 week!), over 4 hours to do a DCM receive, reconfigure takes
about 15 to 30 minutes
- developers productivity will drop as configuration problems will rise

As problems rise, you are likely to try to find "solutions" to the problems
that introduce more overhead, to keep it under control, which will decrease
the performance again and increase the complexity. This will make you more
and more dependent on a small number of individuals who "know the system".

We implemented a strategy that all tasks are associated with a problem
report (in changesynergy), because this clusters tasks into more managable
chunks. The PRs in a resolved state are used in the query based
task-folders. Result: query result is not reproducable, since PR states
change, meaning that there is no 100% certainty what tasks/object-versions
were taken in the build yesterday or last week.
So we had to write our own scripts to log task-folders for the build, and
even to log the complete version overview (listing the exact version for
every file and directory in the tree!!). Given the bad performance of the
reconfigure the build takes a long time before it actually starts compiling.

In other words: I wish you the best luck with cmsynergy... you will need it.

Frank

[Daniel Watford]

"Frank Schophuizen" <fs5628@hotmailnospam.com> writes:
In other words: I wish you the best luck with cmsynergy... you will need it.

Thanks Frank. Forewarned is forearmed i suppose! :)

If it turns out to be a bad solution I'll have to put my hands up as the
one that chose it! But thats what happens when you have no experience in
the field.

Our directors are hoping that the process control aspect will reduce our
paper work as well. We bought Change synergy too!

Just out of interest, what was it that made you decide to choose cmsynergy,
or was it all you were given?

Many thanks,

Dan.


--
Daniel Watford

[Stephen Baynes.]

"Daniel Watford" <dan-comp.software.config-mgmt@foomoo.co.uk> wrote in
message news:brvv1smm.fsf@mailhost.zen.co.uk... At our company we purchased Telelogic CM Synergy. I've been looking at it to try and find out how we may best use it within our development environment. We are a R&D dept with 6 engineers (software and hardware). We always have lots of different projects on the go. Each project was represented in Versions as a different repository project. I would like to use cm synergy beyond basic version control and use the configuration management facilities to assign tasks to individuals (as
well as the other benefits that come with cm). With cm synergy this is possible if all data is stored in a single database. However the downside seems that we then need a means of identifying the product development that an object belongs to. (I didn't want to use the term, project, since synergy has other meanings for that). As far as I can tell an object is marked as belonging to a particular product by assigning an appropriate release value. This means
we would need to use appropriate release naming conventions within the database and I am worried about the list of release names growing very fast.

Releases are the way to go. In earlier versions there were problems with
long release tables. Now you can inactivate releases so you only see the
active releases most of the time. CMS6.3 makes many more improvements to
release table management. We have had databases with hundreds of releases,
even on old versions the only problem was the dropdown for all the releases
more than filled the screen on Unix.

In extream cases of very large databases, it may be useful to DCM out the
starting baseline to a new database, do the project in this database and DCM
the results back in to the main database.

You can also use different databases for development, but DCM all tasks and
problems into one database for central management. Does anyone use cm synergy in a similar environment (many different
product developments all within the same database), and if so how do you group objects into their logical product development?

We do all the time.

We also use separate Synergy project names for each distinct product and the
release name and the project name are related. eg for product X version Y,
the release label will be X_Y (or X-Y in CMS6.3) and the Synergy project
X-Y_Z where Z indicates the build management purpose (eg 'approved',
'integrate', 'test', 'release'. Subprojects might be named X_W-Y_Z or W-Y_Z
(both conventions used)

We also use separate databases for completely different bits of work
(typically where there is a different team or there is no connection at all
between the products).

--
Stephen Baynes CEng MBCS
DTG-S&S, Philips Semiconductors Southampton
Tel +44 23 80316431

[Daniel Watford]

"Stephen Baynes." <stephen.baynes@soton.sc.philips.com> writes:
Releases are the way to go.

Excellent
In earlier versions there were problems with long release tables. Now you can inactivate releases so you only see the active releases most of the time. CMS6.3 makes many more improvements to release table management. We have had databases with hundreds of releases, even on old versions the only problem was the dropdown for all the releases more than filled the screen on Unix.

The release table was what I was worried about. Glad to see that it
shouldn't be a problem
In extream cases of very large databases, it may be useful to DCM out the starting baseline to a new database, do the project in this database and DCM the results back in to the main database.

We didn't buy DCM (AFAIK). If it is too expensive we may have to rule it out.
You can also use different databases for development, but DCM all tasks and problems into one database for central management.

This seems like a good way to go. However I would be worried about the
overhead in creating the new (small) databases for the developers. The
security should be a bonus though.
We also use separate Synergy project names for each distinct product and the release name and the project name are related. eg for product X version Y, the release label will be X_Y (or X-Y in CMS6.3) and the Synergy project X-Y_Z where Z indicates the build management purpose (eg 'approved', 'integrate', 'test', 'release'. Subprojects might be named X_W-Y_Z or W-Y_Z (both conventions used)

I guess the developer's own work area would be a project called
X_Y-developer_name?
We also use separate databases for completely different bits of work (typically where there is a different team or there is no connection at all between the products).

Any particular reason for this? Would performance and security be a
suitable answer?


Thank you for your reply, Stephen. You have helped put my mind at ease a
little :)

Dan.

--
Daniel Watford

[William]

"Frank Schophuizen" <fs5628@hotmailnospam.com> wrote in message
news:5_qRa.421174$gs1.26261225@amsnews03.chello.com...
[...] A lot of customers think in initial investments (e.g. roll-out,
customizing, training) and license costs (ad other costs of ownership) as a major criterion for deciding for a CM tool, but neglect the fact that hampering the development process (e.g. because of trouble with the CM tool) has far more business impact.

When I was tasked with recommending a CM tool there was pressure
to pick one of the biggies (Continuus, ClearCase) because certain
managers thought the features would improve our process. I, on the
other hand, knew we had no process to improve and anything much
more complex than RCS at the client level would meet massive
resistance to use. Fortunately, I managed to make my case that ease
of use, which would improve data gathering, was of major importance.
After that, it needed sufficient bells and whistles to improve the way
we worked and provide for growth down the road. (I also wanted
something reasonably priced so we wouldn't have to abandon it if
times got lean - which, of course, they did for everyone.)

It seems to be a rule of thumb that tools picked primarily for top-level
functionality (report generating, for example), often suck for the
people who have to put the most effort into using them. (I'm saddled
with several right now.)
But don't forget, with any CM tool you can make a complete mess of it.

That's beyond true, for sure. -Wm

[Stephen Baynes.]

"Daniel Watford" <dan-comp.software.config-mgmt@foomoo.co.uk> wrote in
message news:4r1mforl.fsf@mailhost.zen.co.uk... "Stephen Baynes." <stephen.baynes@soton.sc.philips.com> writes: We also use separate Synergy project names for each distinct product and
the release name and the project name are related. eg for product X version
Y, the release label will be X_Y (or X-Y in CMS6.3) and the Synergy project X-Y_Z where Z indicates the build management purpose (eg 'approved', 'integrate', 'test', 'release'. Subprojects might be named X_W-Y_Z or
W-Y_Z (both conventions used) I guess the developer's own work area would be a project called X_Y-developer_name?

Yes (by default).
We also use separate databases for completely different bits of work (typically where there is a different team or there is no connection at
all between the products). Any particular reason for this? Would performance and security be a suitable answer?


Mainly just for clarity to keep really separate stuff separate.
There is a small benifit from security gain is a marginal thing. It does
mean we can hand out ccm_admin and type_developer and know that people can
only mess up themselves.One can also use GroupSecurity to partition access
in a database.
We do get some gains for performance and reliability and maintenance as
things like backups lock the database for less time, one can move databases
between servers, problems (rare) only affect one database, one can upgrade
to a new release in smaller steps etc.
It also makes it easier to archive things when a group of products reach the
end of their life. You can just archive the database as a whole. [Note
CMS6.3 has new archiving features.]

--
Stephen Baynes CEng MBCS
DTG-S&S, Philips Semiconductors Southampton
Tel +44 23 80316431