Configuration Management Aviva Dayan Arik Gendelman Pablo Galiana Seminar in Software Design -...

Configuration Management

Aviva DayanArik GendelmanPablo Galiana

Seminar in Software Design - 2005/6


What is Configuration Management?

The control of changes made throughout the system lifecycle.

Allows changes to be evaluated before they are approved.

Considers interrelationships among system components.


Software Configuration Management

A software engineering discipline Comprised of tools and techniques used to manage change to software assets.

A set of activities to control change by: identifying the products & establishing relationships defining mechanisms for management, control,

auditing and reporting on changes made.

In short: “A methodology to control and manage a software development project.”


Why do we need SCM?

To manage:Many people working on the same code.Projects delivered in several releases

(builds).Rapid evolution of software and hardware.Project surveillance:

i.e. project’s status, bugs, features, etc.Concurrent support and development.Stress time requirements of projects.


Goals of SCM

Configuration Control Controlling product release and its updates.

Status Accounting Recording and reporting components’ status.

Review Ensuring completeness and consistency of all

parts.

Build Management Managing the build process and its tools.


Goals of SCM – cont.

Process Management Ensuring adherence to the development

process.Environment Management

Managing the components that host our system.

Teamwork Facilitate team interactions


SCM – How it is accomplished?

All these goals are accomplished through

Version control

Management of multiple revisions of the same unit of information.


Version control

Commonly used in engineering and software development.

Changes identified by incrementing an associated number or letter code - “revision number”, or “revision level”.

Revision numbers (levels) are associated historically with the person making the change.


Vocabulary

Repository A server where the files are stored.

Check-Out copies a working copy from the repository (the opposite of an import).

Change A specific modification to a document under version control. The granularity of the modification considered a change

varies between version control systems.


Vocabulary – cont.

Change List The set of changes made in a single commit. A sequential view of the source code.

Commit or Check-in Copy the changes on the local files to the directory. (the VC software takes care of changes since the last

synchronization).

Update copies the changes that were made to the repository into your

working directory. (opposite of a commit).


Vocabulary – cont.

Merge / Integration brings together (merges) concurrent changes into a unified

revision. Revision or version

one version in a chain of changes.

Conflict Occurs when two changes are made by different parties

to the same document or place within a document. Resolve

The act of user intervention to address a conflict between different changes to the same document.


Example

CM Clients CM ServerTrunk

Machine A

Machine B

Version B Branch

Version A Branch

Version A.1 Branch

Check Out

A

Check Out

B

Merge

D

Check In

C

Check InE


History

CM systems save the files’ history.

Old versions can be viewed, compared, and downloaded.

New versions can be (irreversibly) replaced with old versions and ‘wiped off the map’.


Central repositories

Files are saved in a central file server.

Developers can view the files in the repository, through the use of filters.


Labels

Several files can be labeled together.

Allows :Access to the label as a whole set of files.Changes to the labeled files as a unit.

Useful for marking product releases.


Check-in

Copies a file into the database.

The version you see is (usually) the latest version that was checked in.

The old version is kept and can be accessed later.


Check out

Copies the database file to your personal folder, and raises a flag on the database copy.

Need to check out before checking in.


Undo check out (uncheck-out)

The “undo checkout” command does just that – the file returns to the status it had before it was checked out.

This can be done even if changes have been made to the local copy – of course, these do not go into the database!


Versioning Models

Lock-Modify-Unlock Solution: Only one person can change a file at a time.

Example: VSS.

Copy-Modify-Merge Solution: Users modify private copies only - in parallel Private copies are merged together into a new,

final version. Example: CVS, Subversion.


Problems With Locking

Administrative problems: A user can lock a file and forget about it.

Time is wasted while others wait to edit the file.

Unnecessary serialization:Different parts of a file don’t necessarily

overlap. E.g.: Alice works on the beginning of a file, Bob

wants to edit the end of the same file.


Problems With Locking – cont.

False sense of security: Let’s say Alice locks and edits file A, while

Bob simultaneously locks and edits file B.Let’s say A and B depend on one another,

and the changes made to each are semantically incompatible.

Suddenly, A and B don't work together anymore.


The Copy-Modify-Merge Solution

Repository

A

A

Aviva and Arik both check out file A.

Here, checkout has no locking effect – it’s just a local copy.

ReadA

Read



Both edit their local files.Repository

A

Arik

Aviva



Repository

Aviva

Arik

Aviva

Aviva checks in her file to the repository first. Write



Repository

Aviva

Arik

Aviva

Now, Arik tries to check-in his file.

He gets an “up-to-date check error”

Write



Repository

Aviva

A’(=Aviva+Arik)

Aviva

Arik updates his local copy to contain the changes made by Aviva. Changes are added to the local file.

During this merge, conflicts may occur.

Read



Repository

Aviva

B

Aviva

A new merged file is created on Arik’s machine.



Repository

B

B Aviva

Arik commits his file to the repository.

Write



Repository

B

B

B

Aviva updates her file from the repository.

Read


Check-out etiquette

If two people have a file checked out, they have to merge their changes before check-in

Merging files can be messy!

This requires coordination and responsibility on the part of developers, not to make unnecessary check-outs, and not to hold check-outs for too long.


File Comparison

Users can graphically compare two versions of files, in or out of the database. Tools: BeyondCompare, Windiff,

AraxisMerge…

This helps with manual mergesAlso helps people decide which version

to access


SourceSafe

Central repository of read-only files.Everybody sees the same version.Only one user can check in at once.

No branching.Limited merge capabilities.

Synchronized with Visual Studio


Advantages of SourceSafe

Synchronized with Visual Studio.

Relatively inexpensive.

Relatively simple to administrate.


Disadvantages of SourceSafe

Does not support branching Requires verbal coordination.Poses a problem for large projects.Complicates development of features

Not compatible with other OS’s.


Get Latest Version (?)

Getting the latest version copies (rather than links) the file from the database to your personal directory - And so:

Getting latest version overwrites files in personal folders.

Rename local files beforehand if you want to keep them.

Database updates do not update local copies. Changes to database necessitate manual merges.


Preserving Database Integrity (or: watch SourceSafe limp…)

Before a SourceSafe check-in: Verify thoroughly that the modified file works with other files Otherwise there could be big trouble…

Other systems allow for new branches Files can be updated there. Branch is merged with main trunk only after integrity checks. Advantage: source control throughout the checking process!


Demo- SourceSafe

Demo – SourceSafe


Concurrent Versions System

CVS has UNIX origins. Available also for Linux and Windows.

Stores only the differences between versions.


Clients

Command line.

GUI (i.e. WinCVS, tkCVS, etc)NOTE: Most GUI/Plugins are wrappers

around the basic CVS command line client.


Revisions

Each version of a file has a unique Revision number. Revision numbers look like ‘1.1’, ‘1.2’, ‘1.3.2.2’ or even ‘1.3.2.2.4.5’.

Main.c 1.1 1.2 1.3 1.4


Revision Numbering

By default: revision 1.1 is the first revision of a file.

Successive revisions incremement the rightmost number.


Tags

Tags are used to give a symbolic name to a certain collection of file revisions.

Main.c

Main.h

1.1 1.2 1.3 1.4

1.1 1.2

Lala.c 1.1 1.2 1.3

TAG_XXX


Branching

Like ClearCase, CVS allows branches:Allows changes to be isolated into a

separate development line.

Branches are good for: Fixing bugs in historical releases. Developing features without disrupting primary

development.


Trunks and Branches

The main branch is called the “main trunk”.

A branch can be merged back to the main trunk, or left as a branch.


Branches and Revisions

Main.h 1.1 1.2 1.3 1.4

1.2.2.1 1.2.2.2

1.2.4.1 1.2.4.2 1.2.4.3

1.2.2.2.2.1 1.2.2.2.2.2Branch 1.2.2.2.2 ->

Branch 1.2.2. ->

Branch 1.2.4. ->

Main Trunk


ClearCase - Overview

Rational ClearCase is a software tool for revisioncontrol of source code and other softwaredevelopment assets.

Basic concepts: Items under ClearCase are generally referred toas “elements”.

For example:design models, source files, project files, DLLs, etc.


VOB

All elements stored in VOBs – Version Object Bases.

Depending on the size and complexity of your SW development environment – ClearCase elementsmay be distributed across more than one VOB.

For example: elements used by the Documentation group can be stored

in one VOB, while elements contributing to software builds can be stored in a different VOB.


VOB – Illustration

This diagram

illustrates a VOB

that contains the

file elements :

prog.c,

util.h,

msg.cat,

and lib.c


View

To access an element under ClearCase, you set up and work in a view,

A view shows a directory tree of specific versions of the element.


Two kinds of views:

Snapshot viewscopy files from VOBs to your computer.

Dynamic views, use the multiversion file system (MVFS) of

ClearCase to provide immediate, transparent access to the data in VOBs.


Configuration Specifications

A set of rules called a configuration specification determines which files are in a view.

These rules are written in a special and powerful script language.


Version Trees

Each time an element is revised and checked in, ClearCase creates a new version of the element in the VOB.

ClearCase organizes the different versions of an element in a VOB into a version tree.


Version Trees and Branches - Illustration

This

diagram

illustrates a

version tree

and several

branches:


Advantages of ClearCase

Can handle projects that:

a) Consists from a lot of developers.

b) Go on for a very long time.

Developed and marketed by IBM, i.e. very smooth and natural integration with a

lot of other IDE/CM/test/profiling… Tools.

Versatile – lots of possibilities and capabilities.


Advantages – cont.

Supported by multiple OS Windows, Unix (Solaris, AIX, …), Linux. Can be accessed from client on one OS to a server

on another OS.

Enables real parallel development - work on multiple versions of the same source file concurrently.


Disadvantages

High price.

Too versatile one can never learn all capabilities.

Complex support must have very good - full time - administrator.


ClearCase View Snapshots

Windows Unix


ClearCase Integrated in Visual Studio IDE.


Checkout Operation SnapshotWindows Unix


ClearCase Merge Utility

Windows Unix


Version Tree SnapshotWindows Unix


General Info – Unix version

General information about a file in the repository – in the Unix GUI.


THE END

Configuration Management Aviva Dayan Arik Gendelman Pablo Galiana Seminar in Software Design -...

Documents

Transcript of Configuration Management Aviva Dayan Arik Gendelman Pablo Galiana Seminar in Software Design -...