A Software Engineering Lecture by Steven Choy
Lecture Overview:
In this lecture, we will start to learn Software Configuration Management, or SCM in short. SCM is the discipline of monitoring and controlling change in the evolution of software system. More specifically, you will learn the following concepts and activities in the process of SCM:
- Configuration item identification
- Promotion management
- Release management
- Branch management
- Variant management
- Change management
Reading: Chapter 13 of the textbook Configuration Management
What is SCM?
- Software Configuration Management (SCM) is the discipline of managing and controlling change in evolution of software system.
CM Terminologies
- Configuration item
- A work product or a piece of software that is treated as a single entity for the purpose of configuration management
- Change Request
- A formal procedure to initiate a change process
- The change may be a bug or enhancement of the existing software system
- Promotion
- A version that is made available to other developers
- A promotion denotes a configuration item that has reached a relatively stable state and ready for other developers' review
- Release
- A version that is released to users
- Workspace
- Each developer owns his/her workspace to store the configuration items that he/she is working on
- The configuration items under workspace are freely editable
- The workspace cannot be accessed by other developers
- Master Directory
- When the developer thinks it's ready to share his/her work with other, it moves the files to a master directory
- Shared by all developers of the team
- Repository
- After more rigorous testing and reviewed by QA team, the whole trunk of code can move to a repository
- The configuration items in repository are ready for release
Configuration Management System
CM Tools
- Revision Control System (RCS)
- Concurrent Version System (CVS)
- Perforce
- IBM ClearCase
Lock-Modify-UnLock Model
Characteristic of Lock-Modify-UnLock Model
- At one time, only one developer can edit the same file
- Developer B has to wait until developer A unlock the file for editing
- RCS is an example of configuration management system that utilizes this model
Copy-Modify-Merge Model
Characteristics of Copy-Modify-Merge Model
- Multiple developers can concurrently work on the same file together
- Concurrent changes by multiple developers are merged by configuration management system
- CVS is an example of configuration management system that utilizes this model
Configuration Management Activities
CM Activities
- Configuration Item and CM Aggregate Identification
- Promotion Management
- Release Management
- Branch Management
- Variant Management
- Change Management
Configuration Item and CM Aggregate Identification
- Potential configuration items:
- User level document including RAD, user manual
- System document including SDD, ODD, test plan, test specification
- Source code
- Database schema
- Installation script
Promotion Management
- Individual developers work on their own piece of code
- When the developer feels it's comfortable to share the code with other, the code is checked into the CM system (this is what so-called "promotion")
- Once promoted, the code can be checked out by other developers for review or editing
- Rule of promotion: Make sure the code compiles before promotion
Repositories and Workspaces
Build/Release Management
- What's a build? What composes a build?
- A build, normally, consists of the compiled classes, data files, images, library dependencies, help files, etc.
- A build is a candidate for release
- Current Trend in making a build
- ANT (Build tool for Java application)
- What's the difference of a build and a release?
- A build can be created anytime and it's up to the development team to make the decision
- A release is a management decision, usually based on marketing or client's requirement
Branch Management
- Developers usually work on multiple versions of the same piece of software concurrently:
- With the release of v1.0, developer continues to add in new features for v2.0
- But at the same time, developer needs to provide bug fixes for v1.0 and probably released as v1.1
- So, v1.1 is known as branch
- Most of configuration management system provides branching support
What branches are good for
Suppose that release 1.0 of tc has been made. You are continuing to develop tc, planning to create release 1.1 in a couple of months. After a while your customers start to complain about a fatal bug. You check out release 1.0 (see section Tags--Symbolic revisions) and find the bug (which turns out to have a trivial fix). However, the current revision of the sources are in a state of flux and are not expected to be stable for at least another month. There is no way to make a bugfix release based on the newest sources.
The thing to do in a situation like this is to create a branch on the revision trees for all the files that make up release 1.0 of tc. You can then make modifications to the branch without disturbing the main trunk. When the modifications are finished you can select to either incorporate them on the main trunk, or leave them on the branch.
Variant Management
- Variants are versions that are intended to coexist
- A system may have variants
- When it is supported on different OS and different hardware platform
- When it is released with different levels of functionalities (e.g. professional edition, enterprise edition)
Change Management
- The handling of "Change" is known as Change Management
- The process of change management is normally defined by management and across multiple teams
- Change management process concerns about:
- How is a change request be submitted?
- Who is allegeable to submit a change request?
- Who approves/rejects the change request?
- Who audits the implementation of the change request?
- Change management process may vary in their formality and complexity, depending on project size and goals
Change Request
- A change request may be initiated by a reported bug or a change of requirement
- Normally a change request is submitted by user, though developer/testers are also allowed
- A change request includes the following items:
- Change request number
- System name/version
- Requester name
- Date
- Description
- Developer assigned
- Affected components
- Priority
- Resolution
- Estimated efforts (man days)
Common Change Management Process
Managing Version
Versioning
- In configuration management system, every file only owns a version, commonly known as "revision"
- Example of revision: 0.1, 1.1, 2.0, 2.11
- A release version is a combination of different configuration items (with distinct revision number)
Versioning Illustrated
Version Identification Scheme
Baseline
- A baseline is a version of a configuration item that has been formally reviewed and agreed on, by management or client
- For baseline, change can only be made by a formal change request
Managing Multiple Versions
- Now you got v1.0 released and you're heading towards v2.0
- But you still needs to handle bug fix for v1.0 and release a patch version 1.1
- How does the CM system help you manage multiple versions?
Version Branching
Merging Versions
- Branches are likely to merge into the main trunk from time to time
- Example: The bug fixes done in v1.1 of the previous is merged with main trunk. So, the bug fixes are included in v2.0 release
- Best practices for merging:
- Identify likely overlaps early
- Merge frequently
- Communicate likely conflicts
- Minimize changes on the main trunk
- Minimize the number of branches
Concurrent Versions System
CVS Overview
- An "open-source" source code control system
- Short for "Concurrent Versions System"
- Use "Copy-Modify-Merge" model
- You can download freely at http://ximbiot.com/cvs/wiki/
Using CVS
Checkout File
Update File
- "Update" refers to synchronize files with the repository
- Command Syntax:
cvs update <filename>
Commit Changes
- "Commit" refers to update changes to the repository
- Command Syntax:
cvs commit
- Or if you just want to commit changes for a single file:
cvs commit <filename>
Add Version
CVS Command Reference
Subversion: the typical work cycle
Reference: Version Control with Subversion
1. Update your working copy
$ svn update
U foo.c
U bar.c
Updated to revision 2.
2. Make changes
svn add
svn delete
svn copy
svn move
3. Examine your changes
$ svn status
? scratch.c # file is not under version control
A stuff/loot/bloo.h # file is scheduled for addition
C stuff/loot/lump.c # file has textual conflicts from an update
D stuff/fish.c # file is scheduled for deletion
M bar.c # the content in bar.c has local modifications
4. Possibly undo some changes
$ svn revert README
Reverted 'README'
5. Resolve conflicts (merge others' changes)
$ svn update
U INSTALL
G README
Conflict discovered in 'bar.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options:
6. Commit your changes
$ svn commit -m "Corrected number of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3.
$ svn commit -F logmsg
Sending sandwich.txt
Transmitting file data .
Committed revision 4.
Extra Materials about Software Configuration Management
The following lists seven software configuration management tools. Some of them offer test drive to play with.
Build and release management tools:
Popular Version Control Systems:
Reference: The Top 7 Open Source Version Control Systems
CVS is the grandfather of revision control systems. It was first released in 1986, and Google Code still hosts the original Usenet post announcing CVS. CVS is the de facto standard and is installed virtually everywhere. However, the code base isn’t as fully featured as SVN or other solutions.
Subversion is probably the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code.
Git is the new fast-rising star of version control systems. Initially developed by Linux kernel creator Linus Torvalds, Git has recently taken the Web development community by storm. Git offers a much different type of version control in that it’s a distributed version control system. With a distributed version control system, there isn’t one centralized code base to pull the code from. Different branches hold different parts of the code. Other version control systems, such as SVN and CVS, use centralized version control, meaning that only one master copy of the software is used.
Mercurial is another open-source distributed version control system, like Git. Mercurial was designed for larger projects, most likely outside the scope of designers and independent Web developers. That doesn’t mean that small development teams can’t or shouldn’t use it. Mercurial is extremely fast, and the creators built the software with performance as the most important feature. The name “mercurial” is an adjective that means “Relating to or having characteristics (eloquence, swiftness, cleverness) attributed to the god Mercury.”
Bazaar is yet another distributed version control system, like Mercurial and Git, that offers a very friendly user experience. It calls itself “Version control for human beings.” It supports many different types of workflows, from solo to centralized to decentralized, with many variations in between.
LibreSource is a Web portal used to manage collaborative projects. It’s based on Java/J2EE and is more a set of visual collaborative tools to help facilitate projects and teams. While the other systems discussed so far have been designed more on a “command line” level, LibreSource is centered more on tools that don’t have a big learning curve.
Monotone is the baby of the distributed revision control bunch. While many of Monotone’s peers focus on performance, Monotone places higher value on integrity than performance. In fact, it can take quite a bit of time for a new user of Monotone to simply download the initial repository due to the extensive validation and authentication required.
Thanks for Reading
If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.
If you find any problem in this lecture note, please feel free to tell Steven by steven@findaway.hk
