Change/Version ManagementChange/Version Management

INFT13/73-316INFT13/73-316

Bond UniversityBond University© 1998 - 2003 K. J. Ross & Associates Pty Ltd© 1998 - 2003 K. J. Ross & Associates Pty Ltd

2 - Lect 3

OverviewOverview

Software Configuration Management

Change Processes

Versioning

CM Plans

3 - Lect 3

Software Development and Software Development and ChangeChange

No matter where you are in the system No matter where you are in the system life cycle, the system will change, and the life cycle, the system will change, and the desire to change it will persist throughout desire to change it will persist throughout the life cycle.the life cycle.

Bersoff, et al, 1980Bersoff, et al, 1980

• Software development involves change– A defect to be fixed– An existing function to be enhanced– A new feature to be added– A new platform to support– A customer-driven special project– Internationalization

4 - Lect 3

Change Causes Developers PainChange Causes Developers Pain

• Working in isolation, you can’t “see” code changes made by team members

• You can’t work in parallel on files that a co-worker is modifying

• You frequently lose time and have to redo work because of lost defects or overwritten code

• You have trouble determining which versions of the code you should be working on

• You have difficulty answering your manager’s questions about project status

• You don’t know who on the team is working on what

• You have no idea which versions of files went into a build

5 - Lect 3

Software Configuration Software Configuration ManagementManagement

• Software Configuration Management is a discipline for controlling the evolution of software systems.

6 - Lect 3

Software Configuration Software Configuration ManagementManagement

• Standard definition for CM taken from IEEE standard 729-1983[SCM] includes:– Identification: identifies structure of the product, its

components and its type, making it unique (CI*). Addresses “What version of the file is this?”

– Control: Manages release of a product and changes done throughout the life cycle. Uses baseline** product. Addresses “What changes went into the latest version of this product ?”

– Status Accounting: Recording and reporting the status of components & change requests. Addresses “How many files were affected by fixing this bug?”

– Audit and Review: Maintaining consistency, validating completeness of components that form a product. Addresses “Are all the correct versions of files used in this current release?”

7 - Lect 3

SCM DefinitionsSCM Definitions

*Configuration Item - collection of hardware, software, and/or firmware, which satisfies an end-user function and is designated for configuration management.

**Baseline - collections of configuration items at a particular point in time

8 - Lect 3

Benefits of SCMBenefits of SCM

• A modern CM solution can provide companies with many benefits such as :– Providing integrity and hence improving the complete software

development and maintenance cycle. – Parallel planning and development. Offshore, distributed

development.– Management of change complexity and its evolution.– Making testing and QA structured and easier. – Removing error-prone steps from product release management.– Providing traceability of related components. – Automating the CM processes and procedures.– Dramatically easing change management and problem tracking

challenges. Support for variant baselines.

– ** More responsive to customers’ growing need for bug fixes, enhancements and support.

9 - Lect 3

ReferencesReferences

• IEEE STD 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology."

• ISO 10007:1995 (E), "Quality Management - Guidelines for Configuration Management.“

• Rigg, W., C. Burrows, and P. Ingram, Ovum Evaluates: Configuration Management Tools, Ovum Limited, 1995

• Susan Dart - The Past, Present & the future of CM– Dart Technology Strategies, Inc.

• Susan Dart – Achieving the best CM solution – Dart Technology Strategies, Inc.

• Bob Ventimiglia, Effective Software Configuration Management• Ovum.com – Product Evaluation

http://www.ovum.com/go/product/sample/0048437.htm

10 - Lect 3

OverviewOverview

Software Configuration Management

Change Processes

Versioning

CM Plans

11 - Lect 3

Change Control ProcessChange Control Process

Need for change is recognised

Change request from user

Developer evaluates

Change report is generated

User is informed

Change request is denied

Change control authority decides

Request is queued for action

Assign people to SCIs

Make the change

Check-in the SCIs

Review/audit the change

Perform SQA/Testing activities

Establish a baseline for testing

Check out SCIs

Promote SCIs for inclusion in next release

Rebuild appropriate version

Review/audit the change

Include all changes in release

12 - Lect 3

Change RequestChange Request

• A change request form is used to capture the intended change

• Used as a tracking/audit mechanism

13 - Lect 3

Configuration Control BoardConfiguration Control Board

• Necessary on larger projects• Performs evaluation, approval, triage

– Evaluate cost, resourcing, impact, risk

• Approves all baseline changes

• Can be excessively loaded on large projects

• How often should you meet?

14 - Lect 3

Iteration and Release PlanningIteration and Release Planning

• Plan out iterations and releases against change requests

15 - Lect 3

Change Tracking SoftwareChange Tracking Software

• Bugzilla• ClearQuest• Many others• See http://testingfaqs.org/t-track.html

16 - Lect 3

OverviewOverview

Software Configuration Management

Change Processes

Versioning

CM Plans

17 - Lect 3

The Release ProcessThe Release Process

1.0

1.1

1.2

2.0

Change Requests,Defects

Release Candidate: Test Completed

(delta)

Release Candidate: what new tests???

• What’s new?• What components have changed?• What is the impact of the changes?• What tests were completed

previously?

18 - Lect 3

Change LogChange Log

• Show revisions• Diff indicates changes to files

and folders between each build

• Change messages can be kept– Often trace back to change

request / defect report

19 - Lect 3

DiffsDiffs

20 - Lect 3

WorkspacesWorkspaces

• Developers check-out code from a shared repository into their own workspace

• Enables them to work independently

• Check-in code when complete

21 - Lect 3

Simultaneous UpdateSimultaneous Update

• When 2 developers change at the same time changes can be lost

22 - Lect 3

Locking ModelsLocking Models

• Locking is too restrictive– Forget to cancel lock– Unneccessary serialisation

23 - Lect 3

Copy MergeCopy Merge

• Simultaneous updates cause a conflict– Second write creates

conflict when commit is attempted

24 - Lect 3

Copy MergeCopy Merge

• Update is performed• Conflict is highlighted• Conflict is resolved by

merging changes• Changes are committed• Other users get merged

changes on their next update

25 - Lect 3

Updates and CommitsUpdates and Commits

• Updates refresh workspace with latest changes• Commit is performed to check-in changes• Change Conflicts

26 - Lect 3

Branching and MergingBranching and Merging

• Branches are separate development streams– Allows part of the development team to

continue developing future changes/enhancements in the main line of the archive while another part of the team makes changes that only apply to the branch.

– Branching also provides reproducibility, allowing developers to “go back in time” and check out source code as it existed at any point. This makes it possible to recreate a previous version of the product, regardless of the number of subsequent changes, additions, or deletions to the project.

• A merge later synchronises changes back into the main development path

MERGE

0

1

2

3

5

6

7

0

1

0

1

2

4

2

/special

/mainfile101.c

BRANCHES

/rls2_bugfix

27 - Lect 3

Versioning ToolsVersioning Tools

Subversion http://subversion.tigris.org/

Windows GUI - http://tortoisesvn.tigris.org/

Eclipse PlugIn - http://subclipse.tigris.org/

CVS http://www.cvshome.org

DaRCS http://darcs.net

Many others Visual Source Safe, Clearcase, PVCS, RCS, SCCS,

Continuous, …

28 - Lect 3

OverviewOverview

Software Configuration Management

Change Processes

Versioning

CM Plans

29 - Lect 3

CM Planning ActivitiesCM Planning Activities

Four main activities in planning a CM approach• Identification• Control• Status Accounting• Audit and Review

30 - Lect 3

CM IdentificationCM Identification

• Identification of all the components and their versions, baselines and configurations which represent the systems

Specifications, designs, code

User manuals, operational instructions, installation procedures

Inspection reports, change requests, problem statements

Test plans, stubs, harnesses, test data

• Identify the configurations of different components that make up a product

– e.g. a parts list describing the versions of subcomponents used

31 - Lect 3

CM IdentificationCM Identification

• Identify the attributes that can be assigned to components

– e.g. whether a variant for a specific platform, such as Windows vs. Unix specific variants.

• Define how the components can be stored in a repository

– what directory hierarchies are used for supporting projects and the different kinds of information in a project.

32 - Lect 3

CM ControlCM Control

• Describes how changes to components of software development and testing activities are controlled How to access the components

e.g. release components only found in a particular repository

Who can access components e.g. authority to hand components over to testers/release.

When components can be accessed e.g. the preconditions to be satisfied before release of the

system, configuration of system under test is frozen while testing

Assessment of the impact of proposed changes e.g. reviews of proposed changes made and approval granted

prior to changes being made.

33 - Lect 3

CM ControlCM Control

• CM control is established through defined procedures, for example: Configuration Control Boards

Change requests/authorizations

34 - Lect 3

CM Status AccountingCM Status Accounting

Reporting functions for assessing state of development configurations

When development phases are complete

e.g. whether system testing phase is complete

Components tested

e.g. all those modules which have undergone unit testing.

Work pending

e.g. notification that a system configuration has changed since the released/tested configuration

Changes requested

e.g. what changes remain pending for a component to decide whether the testing/release should be postponed

35 - Lect 3

CM Audit and ReviewCM Audit and Review

Verifies whether: The configuration is complete

e.g. all components necessary for release are included.

The configuration is a consistent set of parts.

e.g. specifications packaged with a system ready for release are the correct version.

36 - Lect 3

OverviewOverview

Software Configuration Management

Change Processes

Versioning

CM Plans

37 - Lect 3

Putting It All TogetherPutting It All Together

To Do List

Organized ActivitiesOrganized ActivitiesRequestRequest PriorityPriority OwnerOwner ProjectProject

Bug 98Bug 98 11 SamSam WebRelayWebRelay

Bug 527Bug 527 33 SandySandy WebRelayWebRelay

Add GUI buttonAdd GUI button 11 KimKim WebRelayWebRelay

Bug 98Bug 98Bug 98Bug 98

New GUI ButtonNew GUI ButtonNew GUI ButtonNew GUI Button

Bug 527Bug 527Bug 527Bug 527

System

Acceptance

ProductionWork OnWork OnWork OnWork On

CommitCommitCommitCommit

Make Make BaselineBaseline

Make Make BaselineBaseline

Promote Promote BaselineBaseline

Promote Promote BaselineBaseline

UpdateUpdateUpdateUpdateBaselineDevelopersDevelopers IntegratorIntegrator

Project ManagerProject Manager