configuration management with clearcase

Copyright, 2006Dipl. Inform. Uwe Satthoff

1. Basic concepts for usage2. Basic concepts for administration3. Setup of example environment

27.09.2006 - 28.09.200612.10.2006 - 13.10.2006

Configuration Managementwith ClearCase


Configuration Managementwith ClearCase

Setup of example environment


The real world

Project A

Project B

Project C

Project DDeployment

Costumer

problem tracking

change trackingparallel development/maintenance


Which “factors” determine setup of an IT environment ? IT security management

permission system, access control requirements concept of desaster recovery .....

IT quality management test environment setup, concepts, tools, .... .....

IT process management change tracking change control .....

.....


Example requirements name/UID and name/GID must not be re-used at all

=> accounting system => VOB / View owner & group concept all product deliveries must be maintainable for at least 10 years

=> backup system => VOB size, location of VOBs, Views => branching strategy in VOBs => global naming conventions => label, branch type names in VOBs

turn-around time from bug report to patch delivery must be less 1 day, including all required quality tests => branching strategy in VOBs, parallel development => build system setup in VOBs, Views

all software changes must be tracked by unique “request for change” description => control changes in VOBs with triggers


Possible scenarios for CC environments

Scenario 1:only some VOBs, network organized in independent subnets => all VOBs are owned by one account => VOBs are grouped acc. to existing project organizations on several

different hosts => VOBs on one host are owned by the same group, different from VOBs

on other hosts => each VOB host with seperate disk for VOB backup, stores backup of

last 3 days => views can be located anywhere, only users are responsible


Possible scenarios for CC environments

Scenario 2:many VOBs, many projects, subnets are connected to high speed backbone, many developers working in several projects in parallel => all VOBs are stored in a VOB cluster connected to backbone => delivery/build views are stored in a View cluster connected to backbone => VOBs are owned by groups per project, some have additional groups => VOBs of a project are owned by same admin account per project => all VOBs are stored in one big file system to allow for file system

snapshot backup => VOBs are organized in different categories for VOBs

source code VOBs documentation VOBs build / delivery VOBs


How product categories determine usage of ClearCase in projects

“straight forward” development, only one mainline of development: => minimal parallel development => minimal change tracking

Point of delivery


How product categories determine usage of ClearCase in projects

Product is delivered to different customers, it is based on a standard SW product: => maximum parallel development => maximum change tracking

New import of Std SW

Import line

Customer one

Customer two


Breakdown to basic requirements

Each product delivery must identify with one unique identifier the complete software production environment, which was actual at the time of the product version production.

All changes have to be qualified in one central integration and testing working environment. It has to be guaranteed, that each change, even the smallest one, can not be integrated in a new product version without being qualified in this central testing environment.

The process of software qualification must not hinder the developers in their personal individuality (to do it how they are used to do it), because the quality of a software product depends mainly on the competence of the developers.


Example setup: Our job ... Two projects, developing different systems 1. Project: small one, only developing some basic libraries 2. Project: developing adaptions of a standard SW using basic

libraries of project 1 one developer of project 1 is permitted to work in project 2 two developers of project 2 are permitted to work in project 1 project 1 does NOT deliver SW to customers project 2 has one customer to whom deliveries are shipped. In project 2 we have to be able to deliver the actual state of work

at any time in both projects: developers have to be forced to enter a change

number for every new version created


Before we start. Remember the basics.Think simple:What are the jobs based on what material.

Identify the basic tasks define the baseline for each task define the independent work area for the task define the interfaces of each task to other tasks


What do we have to do ...

Administrative tasks create accounts and groups create storage locations for VOBs and Views create the VOBs fill the VOBs with the initial data

Project tasks identify branches of development & integration establish interaction between predefined branches how to incorporate changes from project 1 into project 2 create the views in the predefined view locations

Daily tasks develop software, integrate changes, make deliveries


QUESTIONSQUESTIONS&&

ANSWERSANSWERS

configuration management with clearcase

Documents