1. 2. Configuration Management
Yan Shi
SE 3730 / CS 5730 Lecture Notes

2. Outline What is configuration management? CM techniques and practices
Identification
Change control
Status accounting
Audit and review
CM techniques and practices
lock-modify-unlock
copy-modify-merge
RCS
branching
deltas
CM tools

3. Why is CM needed?
``This worked yesterday and doesn't work now.” What happened?
``The user manual says to do this, but when I do it, something different happens.'' Which is correct, the manual or the code? Why was one changed?
``The code changes that I made last week are no longer in the code.” What happened to the fix? Who changed the code and Why?
``The listing doesn't match what the program does!'' Which is correct?
``Did the bug get fixed in this copy, too?''

4. Why is CM needed? Control the changes Required for testing
Versions of document need to be combined to form a product, or configuration
With many people working on many files, inconsistencies can occur
Required for testing
We must know and control what source was used to produce a software system in order to know what is being tested
We need to be able to build and rebuild a software system reliably

5. CM Concepts and components

6. What is Configuration Management?
Software CM is a discipline for managing the evolution of software systems throughout all stages of the software life cycle.
SCM is a component of SQA system.
Infrastructure component
Organizational framework
SQA teams are often required to take the responsibility of managing the CM system.

7. Support, Control and Service
Developers, organization, customer
Control
Specifications, documents, software, and other deliverables
Service
“SCM is a service provider in that it supports people and controls data.”

8. Software configuration item
Software configuration item (SCI):
An approved unit of software code, a document or piece of hardware that is designed for configuration management and treated as a distinct entity in the SCM process.
The main criterion: whether needed for future development or maintainace
Each SCI must have a unique name:
Augment the name with various attributes such as type of document, OS, language, etc.
It is a terrible practice to have an SCI change name for each version.  Use a consistent name and let the CM system to handle versions.
main a.cpp, main b.cpp, main a.cpp
main.cpp

9. Typical SCI Documents Software code Data files
development plan, requirement specifications, design specifications, database description, test plan, test report, user manuals, maintenance plan, change requests, CM plan, version description, standards, etc.
Software code
source code, prototype
Data files
parameters, codes, etc.
test cases and test scripts
Software development tools
compilers, debuggers, linkers, etc.
CASE tools

10. Version SCI version: Software configuration version:
The approved state of an SCI at any given point of time during the development and maintainace process.
Software configuration version:
An approved selected set of documented SCI versions that constitute a software system or document at a given point of time, where the activities to be performed are controlled by SCM procedures. The software configuration versions are released according to the cited procedures.

11. SCM functional areas Identification Control: Status accounting
identify components, structure
Control:
control releases and changes
Status accounting
record, report status
Audit and review
validate completeness
IEEE

12. Configuration identification
What is the configuration of my system?
What version of the file is this?
What are the components of the system?
Version control is involved during identification.
Prerequisite for other CM functionalities

13. Identification activities
Select items to be placed under SCM control
Create an identification scheme
Identify which version of a SCI can or cannot be included in a working release
Uniquely identify various versions of the software
Define relationships and interfaces between various software products
Release configuration documentation
Establish configuration baselines

14. Configuration baselines
Configuration baseline is a fixed reference configuration established by defining and recording the approved SCI at a milestone event or at a specified time.
Each configuration baseline serves as a point of departure for future SCI changes.
Baselines for different SCIs may occur at different times, (e.g., requirement baselined before code)
Once an SCI is baselined, modifications are strictly controlled by CM policies.
Incremental baselines occur sequentially over the life cycle.

15. Configuration change control
What is controlled?
How are the changes to the products controlled?
who controls the changes?
when are the changes accepted, received, and verified?
Configuration change control makes sure the product is in a consistent state and enforces access control

16. Access control
We don’t want multiple people writing to the same file concurrently.
Different groups in an organization play different roles with respect to the development process.
Coders and testers need read access to requirements, but they should not be permitted to directly change them.
Marketing and requirement engineers should be able to write requirements, but not change code.
Quality Assurance Engineers should have write access to test cases, but coders should not be able to change test cases.

17. Change Control
Change control: a process for proposing, evaluating(feasibility, marketability, economics, risks, etc.) and changing an existing system.
Types of changes:
Defects fixing
Enhancement
Ports: modifying a system so that it can run in different environments.

18. Change control process
A generic change control process [Berlack 1992]
Software changes
Analyze and assess impact
Software enhancement
Prepare change proposal
Problems
Control Board
Evaluate
change proposal
Yes No
Incorporate change
Approve
Archive change
Supply feedback to originator
Verify change
end

19. Configuration Control Board
CCB is a committee of many stakeholders
sales, marketing
development
quality assurance
customer support
who meet regularly to execute this change control process.

20. Standard Change Request Form

21. Change control policies
Who can initiate the change requests
criteria for placing an SCI under formal change control
The “change impact” analysis expected for each requested change
How revision history should be kept
The check-in/check-out procedure
Procedure to approve changes
How change requests are tracked and resolved
The reviews and regression tests required
The procedure to update all affected software life cycle components to reflect the approved changes

22. Configuration status accounting
Accounting is the art of recording, summarizing, reporting, and analyzing financial transactions. 
What is the status of an SCI?
Which version of an SCI implements an approved change request?
What is different about a new version of a system?
How many faults are detected and how many are fixed each month?
What is the cause of the change?
the change process

23. Configuration auditing
Is a change properly resolved?
Does the system satisfy the requirement?
Are all changes incorporated in this version?
Configuration auditing verifies that the software product is built according to the requirements, standards, or contract agreement.
an audit is a planned and documented activity to determine the adequacy and compliance with established procedures

24. Informal and formal audits
Informal audits are performed at key phases of the software life cycle.  Reviews
Two formal audits are conducted before the software is delivered to the customer:
functional configuration audit (FCA)
validate the system against the requirement
physical configuration audit (PCA)
whether the design and reference document represent the software that was built.

25. CM techniques

26. History of SCM techniques
change and configuration control concepts (UCSB);
1970s:
diff algorithm (by bell labs)
SCCS(Source Code Control System by bell labs );
1980s:
RCS (Revision Control System) : only for single files
CVS (Concurrent Version System)
2000: Subversion
2000s: distributed revision control systems (BitKeeper, GNU arch, git)

27. Software Repository Sources files reside in a software repository.
once it has been added to the repository, it becomes subject to version control.
version control tools are responsible for managing the repository.
A.K.A. project databases or project libraries.

28. Workspace
Each team member has a workspace, which is designed to prevent members from interfering with each other’s work.
When a change to a document is required, it is checked out to a team member’s workspace.
Any changes made in the workspace don’t affect the repository.
Test/review the document and then check it in. changed documents are copied back into the repository after approved.

29. The problem of file sharing

30. Versioning models The File-Sharing problem: Versioning models:
how will the system allow users to share information, but prevent them from accidentally stepping on each other’s feet?
Versioning models:
Lock-Modify-Unlock: SourceSafe, RCS, Subversion
Copy-Modify-Merge: SourceSafe, Subversion, CVS

31. Lock-Modify-Unlock
Only one person is allowed to change a file at a time.
Problem:
Harry locks a file and forgets about it. Sally is waiting and cannot do anything else.
Unnecessary serialization.
false sense of security.
The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:
Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.
Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.
Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that 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 locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

32. Copy-Modify-Merge

33. Conflict
What if Sally’s changes overlap with Harry’s changes?  conflict!
Solution:
Harry’s copy is flagged as in conflict.
He can see both sets of conflicting changes.
He manually resolves the conflict (perhaps after discussing with Sally) and safely save the merged file back to the repository.
Communication is the key to reduce conflicts!

34. Revision Control System (RCS)
RCS was first developed by Walter F. Tichy at Purdue University in the early 1980s.
RCS was one of the first version control systems that allowed branching.
better isolation and control of individual software assets;
increased productivity (work in parallel)
may increase risk (merging)
SCCS
RCS
CVS
SCCS: software code control system

35. Branching Support multiple versions of a product.
1.2.1
1.1
1.2
1.3
1.4
2.1
1.1.1
1.1.2
Support multiple versions of a product.
fixes to distributed releases can be done concurrently with maintenance updates
support development of variants (e.g. help doc in different languages, ports to different OS’s)

36. Branching Branches should be merged ASAP
1.2.1
1.1
1.2
1.3
1.4
2.1
1.1.1
1.1.2
Branches should be merged ASAP
Maintaining multiple branches requires significant effort.
When a defect is found, it must be fixed and tested in each branch.

37. Deltas Keeping a copy of each entire version is space consuming
Delta: differences between revisions
forward deltas (SCCS)
backward deltas (RCS)

38. Forward deltas
1.2.1
1.1
1.2
1.3
1.4
2.1
1.1.1
1.1.2
Start at the last complete version (1.1) and applies each of the deltas to construct the version needed.
Most time-consuming to reconstruct the latest version.

39. Backward deltas
1.2.1
2.1
1.1
1.2
1.3
1.4
1.1.1
1.1.2
Keep a full copy of the most recent version (2.1) and store backward changes to reconstruct earlier versions when needed.
Branches still need to be kept as forward deltas. Why?
What is most time consuming to reconstruct?

40. Branching strategies Branch per release Branch per project phase
Branch per task
Branch per technology
Decisions on branch strategies are based on the system architecture and organizational structures.
It is a trade-off between productivity and risk.
reference:
Using branches provides better isolation and control of individual software assets and increases productivity, because teams or individuals can work in parallel. However, using branches also requires an increase in merge activities and therefore risk, because you must later reassemble branches into a whole.
One way to validate a chosen strategy is to consider a scenario of change. For example, if you decide to align branches with the system architecture (for example, a branch represents a system component) and you expect significant architectural changes, you might have to restructure your branches and associated processes and policies with each change. Choosing an inadequate branching strategy can cause process overheads and lengthy integration and release cycles that prove frustrating for the whole team.

41. Branch per release One of the most common branching strategies
one branch hold all the software development assets for a single release.
Occasionally merge updates from one release to another.
Discontinue a branch when discontinue its release.

42. Branch per project phase
Align branches with project phases. For example,
All integration and system testing is performed in a Test branch.
During testing, update the code as you find and fix bugs.
After testing is completed
SCIs are branched into the Production branch and ultimately deployed.
Changes due to bug fixing are merged back to the Development branch.

43. Branch per task
Isolate a task on a separate branch to avoid overlapping tasks
increase productivity: work in parallel
short-term branches: must merge back as soon as you complete the task
otherwise, the merging effort required might exceed the productivity benefits of creating a separate branch for a task.
A similar strategy is to branch per component.

44. Branch per technology Align branches to technology platforms
Common code is managed on a separate branch.
Probably never merge the branches.

45. Distributed version control (DVC)
RCS, CVS, SourceSafe, Subversion:
Centralized system
Client-server approach
GNU arch (now Bazaar), Git:
Distributed system
Peer-to-peer approach
Pull and push
Benefits of a DVCS:
Allow users to work productively when not connected to a network: entire product is local!
Most operations are faster: no network is required!
More resistant to server failure: many “central” repositories!

46. Summary What is CM: CM techniques and tools:
Identification: SCI, version
Control: access control, baseline, change control process
Accounting
Audit
CM techniques and tools:
Centralized: SCCS, RCS, CVS, Subversion, SourceSafe…
Repository, workspace
Check-out/check-in policy:
Lock-Modify-Unlock
Copy-Modify-Merge
Branching
Forward delta vs. backward delta
Branching strategies
Distributed: BitKeeper, Git, GNU arch…