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