Chapter 4: Software Configuration Management (SCM) Omar Meqdadi SE 3860 Lecture 4 Department of Computer Science and Software Engineering University of Wisconsin-Platteville

Topic Covered SCM Activities SCM Tools Why do we need SCM? SCM Terminologies SCM Roles SCM Activities SCM Tools

Definition Software Configuration Management(SCM) - is the discipline of managing the evolution of complex software systems The process of controlling and monitoring change to work products Appropriate documentation of changes Registering the approved software versions

Why do we need SCM? To answer the following questions: Regarding last version Who can provide me with an accurate copy of the last year’s version of the software package? Can we be sure that the version installed does not include undocumented changes and changes that have not been approved? Regarding current version What is the correct version of the software module that I have to continue its coding? What changes have been introduced in the current version? Where can I find the full list of customers that use current version of our software?

Why do we need SCM? Easy access to all previous revisions/versions/releases To deal with conflicts in team software development: Simultaneous updates – how to prevent one person from undoing the changes of another Concurrent Development Shared code – how to inform everyone who needs to know about a change Versions – how to make changes to all affected

SCM Terminologies Configuration Item: an item of software or work product which is subject to change and Needs to be under configuration management control all the time Example: a unit of software code, a system document , Hardware unit Change Request: a formal report that contains the request for modification in a configuration item

SCM Terminologies Version : a specific instance of a configuration item (state of a particular configuration item at a given point of time) Promotion: a version of a configuration item that has been available to other developers in a project Release: a version of the system that has been available to the users Repository: it stores the various releases of the system

SCM Terminologies Three Main Types of Releases Revisions Intermediate Versions Baseline Versions

Revisions Minor changes and corrections May include several small changes in a revision Sometimes we have several small revisions prior to a major baseline release

Intermediate (Minor) Version Usually designed to address immediate problems as to correct defects , adaptive changes May be done to serve only a part of the company’s clients , for a limited period until a new baseline is developed. all clients may not be using the same version of software

Baseline Versions Product that has been formally reviewed , tested and agreed to by responsible management Milestone in the software system’s life cycle Major releases Have major changes , upgrades or enhancements Serves as the basis for further development

Numbering Schemes for Baselines Many naming scheme for baselines exist A 3 digit scheme is quite common Example: Linux Kernel Versions 2.6.0 Major Release Minor Release Small Revision Linux kernels come in two flavors: stable or development Stable kernels are production-level releases are released typically only to provide bug fixes or new drivers (Minor is even) Development kernels undergo rapid change where (almost) anything goes (Minor is odd)

SCM Roles Configuration Manager Change Control Board Member Developer Responsible for identifying configuration items Defining the procedures for creating promotions and releases Change Control Board Member Responsible for approving or rejecting change requests Developer Creates promotions triggered by change requests or the normal activities of development. The developer checks in changes and resolves conflicts Auditor Responsible for the selection and evaluation of promotions for release and for ensuring the consistency and completeness of this release.

SCM Activities Configuration item identification Change Management Controlling Changes Promotion management Release management

Configuration Item Identification Not every item needs to be under configuration management control all the time Two concerns: What should be under configuration control? When do you start to place entities under configuration control? Selecting the correct configuration items is a skill Maintainer should find relationships between configuration items

Which of these entities should be configuration items? Problem Statement Software Project Management Plan (SPMP) Requirements Analysis Document (RAD) System Design Document (SDD) Project Agreement Object Design Document (ODD) Dynamic Model Object model Functional Model Unit tests Integration test strategy Source code API Specification Input data and data bases Test plan Test data Support software (part of the product) Support software (not part of the product) User manual Administrator manual : Yes

Change Management Change management is the handling of change requests Change requests could be from Users Developers Market forces

Change Request Form

Change Management Process

Proposed Change Approval Factors to be considered as to whether to approve the change: Urgency of the change (change priority) Contribution of the change Effect of the proposed change on project timetables, level of service Estimated resources and cost of performing the change Software quality assurance

Change Tracking Tools A major problem in change management is tracking change status Change tracking tools keep track the status of each change request Status could be: Rejected Approved Implemented Automatically ensure that change requests are sent to the right people at the right time.

Implementing Change Identify the activities for Assigning the change request to developers Coordinating multiple changes and promotions Identifying audits and reviews for the project Verifying and testing implemented changes Archiving completed change requests Planning and control of releases

Controlling Changes Two types of controlling change: Promotion: The internal development state of a software is changed Release: A changed software system is made visible outside the development organization Two types of management : Promotion management The creation of versions for other developers Release management The creation of versions for users

Controlling Changes User Master Developer Directory 1- Checkout Promotion Policy Release Policy User Master Directory Software Repository Developer 2- Promotion 3- Release

SCM Directories Programmer’s Directory (Dynamic Library) Library for holding newly created or modified entities by a programmer Completely under control of one programmer Master Directory (Controlled Library) Manages the current baseline(s) and for controlling changes made to them Changes must be authorized Software Repository (Static Library) Archive for the various baselines released for general use Copies of these baselines may be made available to requesting organizations.

SCM Directories: Master Directory Central database What should be in this database? Source Code Documentation Build Tools Often need old versions of the tools to build old versions of the software Ensures software is rebuilt exactly as the customer received it Test Suites

Promotion Management Programmer/Developer File sharing management Check out the latest version of a file/document Make the changes Update the database (check in) File sharing management Multiple people can work on the same source base without colliding Approaches: Locking : Locks individual files so only one person at a time can modify it Merging: Allows multiple people to modify a source file and the system will automatically merge the changes

Promotion Management: Locking Only one person can work on a file at once Works fairly well if developers work on different areas of the project and don’t conflict often Problems: Problem 1: People forget to unlock files when they are done Problem 2: People work around locking by editing a private copy and checking in when the file is finally unlocked - easy to goof and lose changes

Promotion Management: Merging Several people can work on a file at once Before committing changes, each user merges their copy with the latest copy in the database This is normally done automatically by the system and usually works

SCM Change Policies Change Policies guarantee that each promotion or release conforms to commonly accepted criteria Example: Promotion Policy: No developer is allowed to promote source code which cannot be compiled without errors and warnings Release Policy: No baseline can be released without having been beta-tested by at least 200 external persons Approaches: Informal Promotion Policies Formal Release Policies

Configuration Audits and Reviews An audit : determines for each configuration item if it has the required physical and functional characteristics A review : is a management tool for establishing a baseline Audit/Review Plan: The Configuration Items under review The schedule for the review Procedures for conducting the review Participants by job title Required documentation Procedure for recording deficiencies and how to correct them Approval criteria

Release Management Releases must incorporate changes because of: New system functionality Bug fixing Hardware changes Release planning is concerned with when to issue a system version as a release based on the following factors Technical quality of the system Competition Marketing requirements Customer change requests

Release Management Release creation involves: Collecting all files and documentation required to create a system release Configuration descriptions have to be written for different hardware and installation scripts have to be written The specific release must be documented to record exactly what files were used to create it. This allows it to be re-created if necessary

SCM Tools Examples RCS (Revision Control System) Solaris: man rcsintro Promotion management : Locking Little support for binaries CVS (Concurrent Versions System) Built on top of RCS (Little support for binaries) Database can be remote Promotion management : Merging Fast Integrates with emacs

SCM Tools Examples SourceSafe Clearcase Microsoft’s entry, Integrates with MSDEV Promotion management : Locking Built-in web site creation tools (Project-based) Clearcase SCM on steroids You create a view of the database with a config spec, which describes how to select files from the database (Slow) Promotion management : Merging and locking Distributed System : Several groups at different locations can work on the same database Integrates with MSDEV

Case Study : CVS Software repository that preserves changes to source code artifacts during maintenance of software systems Hold a wealth of information and provide a unique view of the actual evolutionary path taken to realize a software system Individual versions of a system Software changes and their metadata Maintenance changes are documented as commits Each commit represents an undertaken change Log file : file contains all commits within a period of time

Case Study : CVS Commit

Case Study : CVS Challenge problems: Huge number of commits Version history does not keep a tag that would identify the purpose of each change