Configuration Management Minsoo Ryu Hanyang University msryu@hanyang.ac.kr
Outline Introduction SCM Activities SCM Process 2 2
Software Configuration Management Definition A set of management disciplines within a software engineering process to develop a baseline Software Configuration Management encompasses the disciplines and techniques of initiating, evaluating and controlling change to software products during and after a software project Standards (approved by ANSI) IEEE 828: Software Configuration Management Plans IEEE 1042: Guide to Software Configuration Management. 3 3
SCM in CMMI CM is a key process in CMMI Level 1-Initial: ad hoc/chaotic Level 2-Managed: basic project management and documentation Level 3-Defined: standard and complete process control and procedures Level 4-Quantitatively Managed: predictable process performance and precise measurements Level 5-Optimizing: continuous and recursive improvement to performance CM operates through the software life cycle 4 4
Not just version control What is SCM Not Not just for source code management Not only for development phase Selecting and using tools are important, but design and management of SCM process are more crucial for project success 5 5
Some Simple CM Scenarios Developer A wants to see latest version of foo.c and its change history since last week B needs to revert foo-design.doc to its version two days ago B makes a release of the project and he needs to know what items to include and which version A lives in New Dehli, India and B lives in Boston, US, they want to work on HelloWorld.java together In the latest release, a serious bug is found and manager C wants to track what changes caused the bug, who made those changes and when C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release 6 6
Configuration Management Activities Software Configuration Management Activities: Configuration item identification Change management Promotion management Release management Branch management Variant management Build management No fixed order: These activities are usually performed in different ways (formally, informally) depending on the project type and lifecycle phase (research, development, maintenance) 7 7
Configuration Management Activities Configuration item identification Modeling the system as a set of evolving components Change management The handling, approval & tracking of change requests Promotion management The creation of versions for other developers Release management The creation of versions for clients and users Branch management The management of concurrent development Variant management The management of coexisting versions Build management The management of building executable applications 8 8
Configuration Management Roles Configuration Manager Responsible for identifying configuration items Also often responsible for 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. 9 9
Configuration Item Identification Configuration Item An aggregation of hardware, software, or both, designated for configuration management and treated as a single entity in the configuration management process. Software configuration items are not only source files but all types of documents Code files Drivers for tests Analysis or design documents User or developer manuals In some projects, not only software but also hardware configuration items (CPUs, bus speed frequencies) need to be put under control! 10 10
Configuration Item Identification Any entity managed in the software engineering process can potentially be brought under configuration management control But, not every entity needs to be under configuration management control all the time Two Issues: What: Selection of Configuration Items What should be under configuration control? When: When do you start to place entities under configuration control? Choices for the Project Manager: Starting with Configuration Items too early introduces bureaucracy Starting with Configuration Items too late introduces chaos. 11 11
Configuration Item Identification Selecting the right configuration items is a skill that takes practice Very similar to object modeling Use techniques similar to object modeling for finding configuration items! Find the configuration items Find relationships between configuration items 12 12
Which Should Be Chosen? 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 13 13
Possible Selection of 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 14 14
Configuration Item Tree Configuration Item Candidates Models Subsystems Documents Object Model Dynamic Model RAD ODD.... Database User Interface........ Code Data Unit Test.... 15 15
Change Management Change management is the handling of change requests The general change management process: The change is requested The change request is assessed against requirements and project constraints Following the assessment, the change request is accepted or rejected If it is accepted, the change is assigned to a developer and implemented The implemented change is audited 16 16
Version, Revision, and Release Version The initial release or re-release of a configuration item associated with a complete compilation or recompilation of the item (different versions have different functionality) Many naming scheme for versions exist (1.0, 6.01a, ) A 3-digit scheme is quite common Major, External Release (Customer) 7.5.5 Minor, Internal Release (Developer) Small Revision (Developer) Revision Change to a version that corrects only errors in the design or code, but does not affect the documented functionality Release The formal distribution of an approved version 17 17
How Versions are Stored Full copy of each version Delta (differences between two versions) Forward delta Reverse delta 1.1 1.2 1.3 1.4 1.1 1.2 1.3 1.4 Mixed delta 18 18
Version Control Model Basic problem of collaborative work 19 19
Version Control Model Model 1-Pessimistic: lock-modify-unlock (1) (2) Problems: Forget to unlock (3) (4) Parallel work not possible Deadlock 20 20
Version Control Model Model 2-Optimistic: copy-modify-merge (1) (2) (5) (6) (3) (4) (7) (8) 21 21
Baseline Baseline A specification or product that has been formally reviewed and agreed to by responsible management, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures. Examples: Baseline A: The API has been completely been defined; the bodies of the methods are empty Baseline B: All data access methods are implemented and tested Baseline C: The GUI is implemented 22 22
Types of Baselines As systems are developed, a series of baselines is developed, usually after a review (analysis review, design review, code review, system testing, client acceptance,...) Developmental baseline (RAD, SDD, Integration Test, ) Goal: Coordinate engineering activities Functional baseline (first prototype, alpha release, beta release, Goal: Get first customer experiences with functional system Product baseline (product) Goal: Coordinate sales and customer support 23 23
Transitions between Baselines Baseline A (developmental) Baseline B (functional, first prototype) Baseline C (product, beta test) Release How do we manage changes in baselines? => Change Management 24 24
Controlling Changes Two types of making changes Promotion: The internal development state of a software is changed Release: A changed software system is made visible outside the development organization Programmer Promotion Master Directory Release Software Repository User 25 25
SCM Directories Programmer s Directory (IEEE: Dynamic Library) Library for holding newly created or modified software entities The programmer s workspace is controlled by the programmer only Master Directory (IEEE: Controlled Library) Manages the current baseline(s) and for controlling changes made to them Changes must be authorized Software Repository (IEEE: Static Library) Archive for the various baselines released for general use Copies of these baselines may be made available to requesting organizations. 26 26
Promotion and Release Policies Whenever a promotion or a release is performed, one or more policies apply The purpose of these policies is to guarantee that each version, revision or release conforms to commonly accepted criteria Examples for change policies No developer is allowed to promote source code which cannot be compiled without errors and warnings No baseline can be released without having been bet-tested by at least 500 external persons 27 27
Branch Management In practice, teams of developers work on different features and functionalities concurrently Teams working on related features may find themselves modifying the same configuration items Branching permits teams to work on the same configuration item independently Trunk: a main version, usually also a promotion Branch: a sequence of version that are later merged back to the trunk Branch management deals with the creation and tracking of branches and their subsequent merging Merging process must identify and reconcile conflicting or interfering changes 28 28
Heuristics for Branch Management Identify likely overlaps Merge frequently with the main trunk Communicate likely conflicts Minimize changes to the main trunk Minimize the number of branches 29 29
Variant Management Variant Versions that are intended to coexist Purposes To support the software on different platforms To customize features for different customers Two approaches Redundant teams Assign one team on each variant Each variant essentially becomes an independent project Software base easily diverges Potential duplication of errors Single project Distinguish between common code and variant-specific code during subsystem decomposition Some teams maintain the common code while others maintain variantspecific code Product build rules assemble the correct pieces for the appropriate variant 30 30
Redundant Teams vs. Single Project 31 31
Build Management The transition from source code to the executable application contains many mechanical steps: Settings required paths and libraries Compiling source code Copying source files (e.g. images, sound files, start scripts) Setting of file permissions (e.g. to executable) Packaging of the application (e.g. zip, tar, dmg) Executing these steps manually is time-consuming and the chance of introducing failures is high 32 32
Build Management Large and distributed software projects need to provide a development infrastructure with an integrated build management that supports: Regular builds from the master directory Automated execution of tests E-mail notification Determination of code metrics Automated publishing of the applications and test results (e.g. to a website) 33 33
Change control process Status accounting Configuration audit Release management CM planning SCM Processes 34 34
Change Control Process Submission of Change Request (CR) Technical and business evaluation and impact analysis Approval by Change Control Board (CCB) Engineering Change Order (ECO) is generated stating changes to be made criteria for reviewing the changed CI CI s checked out Changes made and reviewed CI s checked in 35 35
Status Accounting Administrative tracking and reporting of CIs in CM system Examples Status of proposed changes Status of approved changes Progress of current version, on or behind schedule Estimate of resources to finish one task bugs identified by configuration audit 36 36
Configuration Audit Independent review or examination to assess if a product or process is in compliance with specification, standards, contractual agreement, or other criteria Examples Verifies that CIs are tested to satisfy functional requirements Verifies that baseline contains necessary and correct CI versions Ensures that changes made to a baseline comply with the configuration status reports 37 37
Release Management Creation and availability of a new version of software to the public Release format Source code + build script + instructions Executables packaged for specific platforms Other portable formats: Java Web Start, plugins Patches and updates: automatic, manual Release content Source and/or binary, data files, installation scripts, libraries, user and/or developer documentation, feedback programs, etc. 38 38
Make a CM Plan Standards IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc. CM plan components What will be managed (list and organize CIs) Who will be responsible for what activities (roles and tasks) How to make it happen (design processes for change requests, task dispatching, monitoring, testing, release, etc.) What records to keep (logs, notes, configurations, changes, etc.) What resources and how many (tools, money, manpower, etc.) What metrics to measure progress and success 39 39
CM Tools Version control RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase Bug tracking Bugzilla, Mantis Bugtracker, Rational ClearQuest Build GNU Make and many variants, Ant Project management Sourceforge.net, freshmeat.net, GForge, DForge 40 40