1 / 14

Configuration Management with ClearCase

Configuration Management with ClearCase. 1. Basic concepts for usage 2. Basic concepts for administration 3. Setup of example environment 27.09.2006 - 28.09.2006 12.10.2006 - 13.10.2006. Configuration Management with ClearCase Setup of example environment. The real world. D e

Download Presentation

Configuration Management with ClearCase

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Configuration Managementwith ClearCase 1. Basic concepts for usage 2. Basic concepts for administration 3. Setup of example environment 27.09.2006 - 28.09.2006 12.10.2006 - 13.10.2006

  2. Configuration Managementwith ClearCaseSetup of example environment

  3. The real world D e p l o y m e n t C o s t u m e r Project D Project C Project B Project A problem tracking change tracking parallel development/maintenance

  4. 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 ..... ..... Which “factors” determine setup of an IT environment ?

  5. 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 Example requirements

  6. 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

  7. 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 Possible scenarios for CC environments

  8. “straight forward” development, only one mainline of development: => minimal parallel development => minimal change tracking How product categories determine usage of ClearCase in projects Point of delivery

  9. Product is delivered to different customers, it is based on a standard SW product: => maximum parallel development => maximum change tracking How product categories determine usage of ClearCase in projects New import of Std SW Import line Customer one Customer two

  10. 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. Breakdown to basic requirements

  11. 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 Example setup: Our job ...

  12. 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 Before we start. Remember the basics.Think simple:What are the jobs based on what material.

  13. 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 What do we have to do ...

  14. QUESTIONS&ANSWERS

More Related