Copyright, 2006 Dipl. Inform. Uwe Satthoff 1. Basic concepts for usage 2. Basic concepts for administration 3. Setup of example environment Configuration Management with ClearCase

Copyright, 2006 Dipl. Inform. Uwe Satthoff Configuration Management with ClearCase Setup of example environment

Copyright, 2006 Dipl. Inform. Uwe Satthoff The real world Project A Project B Project C Project D DeploymentDeployment CostumerCostumer problem tracking change tracking parallel development/maintenance

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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 .....

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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.

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff 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

Copyright, 2006 Dipl. Inform. Uwe Satthoff QUESTIONS & ANSWERS