Configuration Management -...

Real-Time Computing and Communications Lab., Hanyang University

http://rtcc.hanyang.ac.kr

Real-Time Computing and Communications Lab., Hanyang University


Configuration Management

Minsoo Ryu

Hanyang University

[email protected]

2Real-Time Computing and Communications Lab., Hanyang University

http://rtcc.hanyang.ac.kr 2Real-Time Computing and Communications Lab., Hanyang University


Outline

Introduction

SCM Activities

SCM Process




Software Configuration Management

Definition

▪ A set of management disciplines within a software

engineering process to develop a baseline

▪ Software Configuration Management encompasses the

disciplines and techniques of initiating, evaluating and

controlling change to software products during and after a

software project

Standards (approved by ANSI)

▪ IEEE 828: Software Configuration Management Plans

▪ IEEE 1042: Guide to Software Configuration Management.




SCM in CMMI

CM is a key process in CMMI▪ Level 1-Initial: ad hoc/chaotic

▪ Level 2-Managed: basic project management and documentation

▪ Level 3-Defined: standard and complete process control and procedures

▪ Level 4-Quantitatively Managed: predictable process performance and precise measurements

▪ Level 5-Optimizing: continuous and recursive improvement to performance

CM operates through the software life cycle




What is SCM Not

Not just version control

Not just for source code management

Not only for development phase

Selecting and using tools are important, but design and management of SCM process are more crucial for project success




Some Simple CM Scenarios

Developer A wants to see latest version of foo.c and its change history since last week

B needs to revert foo-design.doc to its version two days ago

B makes a release of the project and he needs to know what items to include and which version

A lives in New Dehli, India and B lives in Boston, US, they want to work on HelloWorld.java together

In the latest release, a serious bug is found and manager C wants to track what changes caused the bug, who made those changes and when

C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release




Configuration Management Activities

Software Configuration Management Activities:

▪ Configuration item identification

▪ Change management

▪ Promotion management

▪ Release management

▪ Branch management

▪ Variant management

▪ Build management

No fixed order:

▪ These activities are usually performed in different ways

(formally, informally) depending on the project type and life-

cycle phase (research, development, maintenance)




Configuration Management Activities

Configuration item identification

▪ Modeling the system as a set of evolving components

Change management

▪ The handling, approval & tracking of change requests

Promotion management

▪ The creation of versions for other developers

Release management

▪ The creation of versions for clients and users

Branch management

▪ The management of concurrent development

Variant management

▪ The management of coexisting versions

Build management

▪ The management of building executable applications




Configuration Management Roles

Configuration Manager▪ Responsible for identifying configuration items

▪ Also often responsible for defining the procedures for creating promotions and releases

Change Control Board Member▪ Responsible for approving or rejecting change requests

Developer▪ Creates promotions triggered by change requests or the

normal activities of development. The developer checks in changes and resolves conflicts

Auditor▪ Responsible for the selection and evaluation of promotions

for release and for ensuring the consistency and completeness of this release.




Configuration Item Identification

Configuration Item▪ An aggregation of hardware, software, or both, designated for

configuration management and treated as a single entity in the configuration management process.

Software configuration items are not only source files but all types of documents▪ Code files

▪ Drivers for tests

▪ Analysis or design documents

▪ User or developer manuals

▪ …

In some projects, not only software but also hardware configuration items (CPUs, bus speed frequencies) need to be put under control!





Any entity managed in the software engineering process can potentially be brought under configuration management control▪ But, not every entity needs to be under configuration

management control all the time

Two Issues:▪ What: Selection of Configuration Items

• What should be under configuration control?

▪ When: When do you start to place entities under configuration control?

Choices for the Project Manager:▪ Starting with Configuration Items too early introduces

bureaucracy

▪ Starting with Configuration Items too late introduces chaos.





Selecting the right configuration items is a skill that

takes practice

▪ Very similar to object modeling

▪ Use techniques similar to object modeling for finding

configuration items!

• Find the configuration items

• Find relationships between configuration items




Which Should Be Chosen?

Problem Statement

Software Project Management

Plan (SPMP)

Requirements Analysis

Document (RAD)

System Design Document (SDD)

Project Agreement

Object Design Document (ODD)

Dynamic Model

Object model

Functional Model

Unit tests

Integration test strategy

Source code

API Specification

Input data and data bases

Test plan

Test data

Support software (part of the

product)

Support software (not part of the

product)

User manual

Administrator manual




Possible Selection of Configuration Items

Problem Statement

Software Project Management

Plan (SPMP)

Requirements Analysis

Document (RAD)

System Design Document (SDD)

Project Agreement

Object Design Document (ODD)

Dynamic Model

Object model

Functional Model

Unit tests

Integration test strategy

Source code

API Specification

Input data and data bases

Test plan

Test data

Support software (part of the

product)

Support software (not part of the

product)

User manual

Administrator manual




Configuration Item Tree

Configuration Item

Candidates

Models Subsystems Documents

Object Model Dynamic Model

Database User Interface

. . . .

Code Data Unit Test

RAD ODD

. . . . . . . .

. . . .




Change Management

Change management is the handling of change

requests

The general change management process:

▪ The change is requested

▪ The change request is assessed against requirements and

project constraints

▪ Following the assessment, the change request is accepted or

rejected

▪ If it is accepted, the change is assigned to a developer and

implemented

▪ The implemented change is audited




Version, Revision, and Release

Version

▪ The initial release or re-release of a configuration item associated with a complete compilation or recompilation of the item (different versions have different functionality)

▪ Many naming scheme for versions exist (1.0, 6.01a, …)

▪ A 3-digit scheme is quite common

Revision

▪ Change to a version that corrects only errors in the design or code, but does not affect the documented functionality

Release

▪ The formal distribution of an approved version

Major, External Release

(Customer)

Minor,Internal Release

(Developer)

Small Revision (Developer)

7.5.5




How Versions are Stored

Full copy of each version

Delta (differences between two versions)

Forward delta

Reverse delta

Mixed delta

1.1 1.2 1.3 1.4

1.1 1.2 1.3 1.4




Version Control Model

Basic problem of collaborative work





Model 1-Pessimistic: lock-modify-unlock

Problems:

Forget to unlock

Parallel work not possible

Deadlock

(1) (2)

(3) (4)





Model 2-Optimistic: copy-modify-merge

(1) (2)

(3) (4)

(5) (6)

(7) (8)




Baseline

Baseline

▪ “A specification or product that has been formally reviewed

and agreed to by responsible management, that thereafter

serves as the basis for further development, and can be

changed only through formal change control procedures.”

Examples:

▪ Baseline A: The API has been completely been defined; the

bodies of the methods are empty

▪ Baseline B: All data access methods are implemented and

tested

▪ Baseline C: The GUI is implemented




Types of Baselines

As systems are developed, a series of baselines is

developed, usually after a review (analysis review,

design review, code review, system testing, client

acceptance, ...)

▪ Developmental baseline (RAD, SDD, Integration Test, …)

• Goal: Coordinate engineering activities

▪ Functional baseline (first prototype, alpha release, beta

release, …

• Goal: Get first customer experiences with functional system

▪ Product baseline (product)

• Goal: Coordinate sales and customer support




Transitions between Baselines

Release

Baseline A (developmental)

Baseline B (functional, first prototype)

Baseline C (product, beta test)

How do we manage changes in baselines?

=> Change Management




Controlling Changes

Two types of making changes

▪ Promotion: The internal development state of a software is

changed

▪ Release: A changed software system is made visible outside

the development organization

User

Release

Software

Repository

Master

DirectoryProgrammer

Promotion




SCM Directories

Programmer’s Directory (IEEE: Dynamic Library)

▪ Library for holding newly created or modified software

entities

▪ The programmer’s workspace is controlled by the

programmer only

Master Directory (IEEE: Controlled Library)

▪ Manages the current baseline(s) and for controlling changes

made to them

▪ Changes must be authorized

Software Repository (IEEE: Static Library)

▪ Archive for the various baselines released for general use

▪ Copies of these baselines may be made available to

requesting organizations.




Promotion and Release Policies

Whenever a promotion or a release is performed, one

or more policies apply

▪ The purpose of these policies is to guarantee that each

version, revision or release conforms to commonly accepted

criteria

Examples for change policies

▪ “No developer is allowed to promote source code which

cannot be compiled without errors and warnings”

▪ “No baseline can be released without having been bet-tested

by at least 500 external persons”




Git

A distributed version control system

▪ created by Linus Torvalds in 2005 for Linux development




Branch Management

In practice, teams of developers work on different features and functionalities concurrently▪ Teams working on related features may find themselves

modifying the same configuration items

▪ Branching permits teams to work on the same configuration item independently

• Trunk: a main version, usually also a promotion

• Branch: a sequence of version that are later merged back to the trunk

Branch management deals with the creation and tracking of branches and their subsequent merging▪ Merging process must identify and reconcile conflicting or

interfering changes




Heuristics for Branch Management

Identify likely overlaps

Merge frequently with the main trunk

Communicate likely conflicts

Minimize changes to the main trunk

Minimize the number of branches




Variant Management

Variant▪ Versions that are intended to coexist

▪ Purposes

• To support the software on different platforms

• To customize features for different customers

Two approaches▪ Redundant teams

• Assign one team on each variant

• Each variant essentially becomes an independent project

• Software base easily diverges

• Potential duplication of errors

▪ Single project

• Distinguish between common code and variant-specific code during subsystem decomposition

• Some teams maintain the common code while others maintain variant-specific code

• Product build rules assemble the correct pieces for the appropriate variant




Redundant Teams vs. Single Project




Build Management

The transition from source code to the executable

application contains many mechanical steps:

▪ Settings required paths and libraries

▪ Compiling source code

▪ Copying source files (e.g. images, sound files, start scripts)

▪ Setting of file permissions (e.g. to executable)

▪ Packaging of the application (e.g. zip, tar, dmg)

Executing these steps manually is time-consuming

and the chance of introducing failures is high




Build Management

Large and distributed software projects need to

provide a development infrastructure with an

integrated build management that supports:

▪ Regular builds from the master directory

▪ Automated execution of tests

▪ E-mail notification

▪ Determination of code metrics

▪ Automated publishing of the applications and test results

(e.g. to a website)




SCM Processes

Change control process

Status accounting

Configuration audit

Release management

CM planning




Change Control Process

Submission of Change Request (CR)

Technical and business evaluation and impact analysis

Approval by Change Control Board (CCB)

Engineering Change Order (ECO) is generated stating

▪ changes to be made

▪ criteria for reviewing the changed CI

CI’s checked out

Changes made and reviewed

CI’s checked in




Status Accounting

Administrative tracking and reporting of CIs in CM system

Examples

▪ Status of proposed changes

▪ Status of approved changes

▪ Progress of current version, on or behind schedule

▪ Estimate of resources to finish one task

▪ bugs identified by configuration audit




Configuration Audit

Independent review or examination to assess if a product or process is in compliance with specification, standards, contractual agreement, or other criteria

Examples

▪ Verifies that CIs are tested to satisfy functional requirements

▪ Verifies that baseline contains necessary and correct CI

versions

▪ Ensures that changes made to a baseline comply with the

configuration status reports




Release Management

Creation and availability of a new version of software to the public

Release format▪ Source code + build script + instructions

▪ Executables packaged for specific platforms

▪ Other portable formats: Java Web Start, plugins

▪ Patches and updates: automatic, manual

Release content▪ Source and/or binary, data files, installation scripts, libraries,

user and/or developer documentation, feedback programs, etc.




Make a CM Plan

Standards▪ IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc.

CM plan components▪ What will be managed (list and organize CIs)

▪ Who will be responsible for what activities (roles and tasks)

▪ How to make it happen (design processes for change requests, task

dispatching, monitoring, testing, release, etc.)

▪ What records to keep (logs, notes, configurations, changes, etc.)

▪ What resources and how many (tools, money, manpower, etc.)

▪ What metrics to measure progress and success




CM Tools

Version control▪ RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase

Bug tracking▪ Bugzilla, Mantis Bugtracker, Rational ClearQuest

Build▪ GNU Make and many variants, Ant

Project management▪ Sourceforge.net, freshmeat.net, GForge, DForge

Configuration Management -...

Documents

Transcript of Configuration Management -...