Configuration Management

Version: 1.1
Author: Nguyen Lam Phuong / Dao Duy Cuong

Nov-2003

Instructor: Nguyen Lam Phuong

Operation Manager

©2003 FPT-SOFT 04e-BM/NS/HDCV/FSOFT

 Introduction

Course Objective
The purpose of this course is to explain various terms and concepts
related to Configuration Management, and also to describe
different best practices as well as how to use version management
tool effectively
Duration: 2 hours
Targeted attendees:
Configuration Controller and Acting PL + to-be PL

FPT-Soft Confidential TRAINING MATERIALS 2

 Objectives

After the course, student will achieve (be able

to):
 Identify CSCI, CI, Baselines

 Baseline

 Understand and implement the CM

processes

FPT-Soft Confidential TRAINING MATERIALS 3

 Need for CM

 Enables the team to work together in

a stable and flexible environment
 Maintains the integrity and control of
software products throughout the life
cycle
 Enforces the discipline on the control
in the change of the software
product and documents
 Enhances the productivity in long run
 Easy identification of artifacts in case
of future maintenance and
 Mainly the success of any project
depends on the strong CM plan

FPT-Soft Confidential TRAINING MATERIALS 4

 Steps involved in CM

 Configuration Identification :
Identification of Items to be put under
configuration management
 Configuration Control
Provides mechanism to process change
requests, to track changes, to distribute
changes and to maintain past versions
 Status Accounting
Provides formalized recording and
reporting of established configuration items
 Reviews/Audits
 Access Control

FPT-Soft Confidential TRAINING MATERIALS 5

 CI Concept

 Computer Software Configuration Item

Software Project Artifacts (CSCI)
 A software item which is identified for
configuration management or, an
CSCI aggregation of software that satisfies an
CI CI end user function and designated for
separate configuration management
 Configuration Item (CI)
 A configuration item is a uniquely
identifiable subset of the CSCI that
represents the smallest portion of the
CSCI system to be subject to independent
CI CI configuration management change
control procedures. Configuration items
need to be individually controlled
because any change to a configuration
item may have some effect upon the
properties of the system

FPT-Soft Confidential TRAINING MATERIALS 6

 Categories of CSCI
 Project management configuration
items
• Project plans
• Schedules
 Requirements & design configuration
items
• Requirements specifications
• High level design
• Detailed design
• Use case model files
• Test plans
 Build configuration items
• Source files

FPT-Soft Confidential TRAINING MATERIALS 7

 Promotion Model of CSCI

Development

Next-Build

QA

Release

FPT-Soft Confidential TRAINING MATERIALS 8

 Baseline process
Baseline
Config Baseline
Create CI Register
Record
Record

Baseline
Draft Area Baseline area
(WIP) (Controlled)

Revise
Release CI
CSCI type Before Baseline point At Baseline

Source Store in a folder of VM Put under common label inside VM

Tool repository
Binary Store in WIP project Store in FINAL project sub-
directory directory according to baseline ID

FPT-Soft Confidential TRAINING MATERIALS 9

 Baseline for All Types of CI

Configuration Item CSCI Type Baseline Point VM Label

Documents & Sources before Requirement START-UP Startup_DDMMMYY
starting the modifications
Requirements specification Requirement After Requirements ForReview_DDMM
specification approval BaselineAt_DDMM
Design documents Design After Design approval ForReview_DDMM
BaselineAt_DDMM
Project Plan Project After review and ForReview_DDMM
Management approval. BaselineAt_DDMM
Source Code & related files Source Ready for Review ForReview_DDMMMYY
Ready for Next_Build ForBuild_DDMMYY
Ready for System test ForTest_DDMMMYY
Ready for release Release_DDMMMYY
WRAP-UP Wrapup_DDMMMYY

FPT-Soft Confidential TRAINING MATERIALS 10

 Proposed directory structure
 Project repository directory
 <Domain Name>/<Project Name>
 FINAL
 <BaseLine Names>
 Deliverables + Baseline record

 WIP
 Plan
 Deliverables
 Report
 Minutes
 Temp
 Users

 REFERENCE
 CustomerSupplied
 ProcessTemplate

 Workstation control
 Dual boots

FPT-Soft Confidential TRAINING MATERIALS 11

 Access control

Environment Directory VM Folder Role Access Rights

Development WIP DEV_xxx Development Read, Write, Execute
Team
Test TST_xxx Configuration Read, Rights to migrate
Controller from Development to test
environment
Testing Team Read, Execute

Release Team Rights to migrate from test

to Pre Production
environment
Pre Production FINAL PRO_xxx Release Team Read, Execute, Rights to
migrate from Pre
Production to Production
environment
Production (Depend on (Depend on Release Team Read, Execute, Rights to
client) client) migrate from Pre
Production to Production
environment

FPT-Soft Confidential TRAINING MATERIALS 12

 Configuration Control Process
Project created in VM by CC. All
Project created in VM by CC. All
sources/documents are added to VM
sources/documents are added to VM
Repository by development team.
Repository by development team.

Developer checks out files (and locks) to Once coding & review are completed, PL
Developer checks out files (and locks) to Once coding & review are completed, PL
working directory from VM. or developer does the labelling of CSCI
working directory from VM. or developer does the labelling of CSCI
for migration to Next_build environment.
for migration to Next_build environment.
Modification if any, after unit testing
Changes are made & tested in working
Changes are made & tested in working
directory by Developer Developer of other CSCI can make use
directory by Developer Developer of other CSCI can make use
of shared CSCIs stored in Next_buld
of shared CSCIs stored in Next_buld
environment to build their executable
Unit testing is done in the working environment to build their executable
Unit testing is done in the working
directory by the developer
directory by the developer
Project leader can choose whether to
Project leader can choose whether to
Developer checks-in the file back in VM migrate individual CSCI or whole project
Developer checks-in the file back in VM migrate individual CSCI or whole project
repository (with appropriate remarks) to the QA level. The promotion is done
repository (with appropriate remarks) to the QA level. The promotion is done
by CC
by CC

Development team gives proper labels to

Development team gives proper labels to
the sources before giving it for the Testers get the latest version from QA
the sources before giving it for the Testers get the latest version from QA
review. Reviewer in the development environment and conduct testing. If
review. Reviewer in the development
team checks the sources along with the environment and conduct testing. If Bug fix
team checks the sources along with the defect found, the code is fall back at
appropriate checklist and gives the defect found, the code is fall back at
appropriate checklist and gives the Development level and after bug-fix, it
comments. Modification if any, Development level and after bug-fix, it
comments. then will be promoted again
after review then will be promoted again

Release team will do FIR on the content CC promote the whole project from QA
Release team will do FIR on the content CC promote the whole project from QA
of Release level. After that the project level to Release level (after certain
of Release level. After that the project level to Release level (after certain
will be released to client from there. quality criteria has been meet) & produce
will be released to client from there. quality criteria has been meet) & produce
corresponding baseline record
corresponding baseline record

FPT-Soft Confidential TRAINING MATERIALS 13

 Setting up the CM

 Trace the flow of work in the project. Identify the outputs in each of the life
cycle stages
 Define what your computer software configuration items (CSCIs) are:
individual modules, subsystems, etc.
 For each CSCI, determine its lowest level of decomposition, i.e. configuration
items (CIs). For example. the set of all project related documents will be one
CSCI, while each element of this set like the project plan, the CM plan etc. will
be a CI
 Determine a method to identify and categorize your CIs and their revision level
 Baseline the current code at some meaningful point in the development and
start change control on baselined items
 Document your baseline with a version description document (or baseline
record)
 Implement access control and maintain up-to-date config-register

FPT-Soft Confidential TRAINING MATERIALS 14

 Change control

 Control the changes of approved CIs (baselined & released or delivered to the
customer)
 The change should be logged in the ChangeRequest form
 Each change of a CI is a small software-developing project that needs
analysing, impact estimating and approving by the CCB
 Regression tests need to be implemented to ensure that changes have not
caused unintended effects on the baseline

FPT-Soft Confidential TRAINING MATERIALS 15

 Release

 Verify the work-product completion (according to Release Notes)

 All Items in Release Notes are identified
 Traceability to the Requirement is established
 Test & review have been carried
 Status of open defects and issues
 Check the content of Release Notes against actual package
 Check Version & Date of Release Notes
 Check-out the CIs from Release Area
 Rebuild executable
 Follow setup instruction on fresh machine
 Quick check on product consistency
 Archive the release

FPT-Soft Confidential TRAINING MATERIALS 16

 Configuration Audit

 Assess the integrity of software baseline

 Review structure and facility of CM system
 Check the completeness and correctness of software baselines
 Process compliancy check
 Prepare audit report

FPT-Soft Confidential TRAINING MATERIALS 17

 CM with VSS - Concepts

 Revision
 A particular version of a particular CI
 Sharing
 Provide views of a particular version in a file or project's history – using pins or
branches.
 Pin
 Pins are simply pointers to a particular version in a file's history. In SourceSafe, a
pinned file will appear in the project tree with an icon next to it that looks like a
pushpin. To change the version of the file the pin points to, you simply unpin the
shared file, then pin it again to the version you want. In the context of a project,
pins are used to provide specific snapshots of the project configuration.
 Branch
 Branches differ from pins in that they represent a completely separate baseline for
the source code that is entirely independent from which the version they branch
was originally created. Branches are used when a new baseline is needed to permit
development or maintenance of one baseline independent of development or
maintenance of another.

FPT-Soft Confidential TRAINING MATERIALS 18

 Promote Subtree to Next_Build
 Steps to promote a subtree from DEVELOP to NEXT_BUILD:
1. Delete subtree from NEXT_BUILD if already exists.
2. Label the subtree in DEVELOP with appropriate label.
3. Choose Show History… in pop-up menu of the subtree.
4. Check the Include Labels and Labels Only checkboxes.
5. Click OK to show history dialog box.
6. Select the version in history with the label you just applied.
7. Click Share. Then choose parent node in NEXT_BUILD segment.
8. Make sure the Branch after share checkbox is not checked.
9. Click OK, then enter name of new node when asked.
10. Check the Recursive checkbox.
11. Click OK and done.

FPT-Soft Confidential TRAINING MATERIALS 19

 Promote Files to Next_Build
 Steps to promote a file from DEVELOP to NEXT_BUILD:
1. Check in file in DEVELOP segment.
2. Select the file in NEXT_BUILD segment and right click to display pop-up
menu.
3. Choose Show History… in pop-up menu of the file.
4. Make sure Labels Only checkbox is NOT checked.
5. Click OK to show history dialog box for the file.
6. Click Unpin. SourceSafe will remove the pin icon.
7. Select new version to include in NEXT_BUILD.
8. Click Pin. SourceSafe will place a pushpin icon next to the version.
9. Click OK and done.

FPT-Soft Confidential TRAINING MATERIALS 20

 Create Quality_Control in VSS
 Steps to create Quality_Control segment in VSS:
1. Label the NEXT_BUILD segment with appropriate label.
2. Choose Show History… in pop-up menu of NEXT_BUILD.
3. Check the Include Labels and Labels Only checkboxes.
4. Click OK to show history dialog box.
5. Select the version in history with the label you just applied.
6. Click Share. Then choose Quality_Control as parent node.
7. Make sure the Branch after share checkbox is NOT checked.
8. Click OK, then enter name of new node when asked.
9. Check the Recursive checkbox.
10. Click OK and done.

 Note:
 For large project, this may take a while. Once completed, you can use the
Get Latest Version to reproduce this Quality_Control version in the future.

FPT-Soft Confidential TRAINING MATERIALS 21

 Create Release Version in VSS
 Steps to create Release version in VSS:
1. Label the Quality_Control version with appropriate label.
2. Choose Show History… in pop-up menu of Quality_Control.
3. Check the Include Labels and Labels Only checkboxes.
4. Click OK to show history dialog box.
5. Select the version in history with the label you just applied.
6. Click Share. Then choose Release as parent node.
7. This time, make sure the Branch after share checkbox IS checked.
8. Click OK, then enter name of new node when asked (e.g. Release_10Oct03).
9. Check the Recursive checkbox, click OK to finish.

 Note:
 Since it’s a branch rather than a pin, maintenance staff can update code
and provide patch releases independently of continuing work on future
releases.
 We can use “Merge Branch” feature of VSS to merge fixes of Release
branch into original code branch (preferably before next release).

FPT-Soft Confidential TRAINING MATERIALS 22

 Conclusion
 In this course, we’ve learned
 Most important concepts about CM
 The relationship between CM and Development processes
 CM Processes
 Using VSS for version control

FPT-Soft Confidential TRAINING MATERIALS 23

 Resources & references
 Resources
 Infosys – WebMethodology version 1.0 and 2.0
 FPT – CM guidelines
 Recommended readings

FPT-Soft Confidential TRAINING MATERIALS 24

Questions and Answers