Configuration management

Configuration managementWhat is CM?Configuration management (CM) is the discipline of controlling the evolution of complex systems; software configuration management (SCM) is its specialization for computer programs and associated documents.IEEE standard 729-1983 definitionIdentification: an identification scheme reflects the structure of the product, identifies components and their type, making them unique and accessible in some form"This program worked yesterday. What happened?"I cant reproduce the error in this configuration. "I fixed this problem long ago. Why did it reappear?"The online documentation doesnt match the program."Do we have the latest version?"Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product"How do I configure a test system that contains my temporary fixes to the last baseline, and the released fixes of all other components?"Given a list of fixes and enhancements, how do I configure a system that incorporates them?"This enhancement wont be ready until the next release. How do I configure it out of the current baseline?"How exactly does this version differ from the Baseline?"Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product."Has this problem been fixed?"Which bug fixes went into this copy?"This seems like an obvious change. Was it tried before?"Who is responsible for this modification?"Were these independent changes merged?"Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that the product is a well-defined collection of components

CM in a hardware-development environmentA computer has a processor, a mainboard, some memory, a hard drive, a monitor, and a keyboard. Each of these hardware items has an interface that connects it to other hardware items. Your mouse has a plug, and your computer has a port into which you plug your mouse, and makes everything works.If the plug on the mouse was not compatible with the port on the computer, there would be no way to connect the two pieces of hardware into a working system.

Throughout the computer, there are many other similar interfaces. The processor and memory plug into the mainboard, the hard drive plugs into the computer, and the printer, monitor, and keyboard all have interfaces.When the hardware is manufactured, the interfaces that are essential for the operation of the final system are easily seen. Therefore, they are well known and are carefully examined whenever changes are made to the hardware design.For a hardware system, configuration management has the following aspects. Each system is numbered or identified and also has a version number. Each version number identifies different designs of the same part.When the design of a hardware system is changed, the system gets a new version number.A hardware system can be made up of hundreds, thousands, or tens of thousands of parts.The next thing that must be recorded is which versions of these parts go together.version of the mouse, hard drive, processor, and monitor go together to make a complete system. Each of these parts, such as a hard drive, is made of many, many subparts, all of which must go together to have a working unit.

Software development and maintenance phases and CM

WHY CM?Software configuration management must ensure that:software components can be identified;software is built from a consistent set of components;software components are available and accessible;software components never get lost (e.g. after media failure or operator error);every change to the software is approved and documented;changes do not get lost (e.g. through simultaneous updates);it is always possible to go back to a previous version;a history of changes is kept, so that is always possible to discover who did what and when.Software develops from baseline to baseline until it can be released.Changes to baselines must be controlled throughout the life cycle by documenting the:problems, so that they can be understood;changes that are proposed to solve the problem;modifications that result.ESA PSS-05-0 identifies five primary configuration management activities:configuration identification;configuration item storage;configuration change control;configuration status accounting;release.Software Configuration Management Activities

(Software configuration management plan)SPMP Software project management planImportant concepts and terms in CMComponent Item (CI)A CI is an aggregation of hardware, software or both that is designated as a unit for configuration management, and treated as a single entity in the configuration management processA CI can be an aggregation of other CIs, organised in a hierarchy.Any member of this hierarchy can exist in several versions, each being a separate CI.Examples of configuration items(CI) are:software component, such as a version of a source module, object module, executable program or data file;support software item, such as a version of a compiler or a linker;baseline, such as a software system under development;release, such as a software system in operational use;document, such as an ADD.Types of CIThe type field of a CI identifier should identify the processing the CI is intended for. There are three main types of CI: source CIs; derived CIs; tools to generate derived CIs from source CIs.

Configuration identificationConfiguration identification conventions should state how to:name a CI;decide who is the control authority of a CI;describe the history of a CI.At the top level, the whole system is a CI.Several factors may be relevant in deciding what to identify as the lowest level CI, such as the:software design defined in the ADD and DDD (the lowest level of the software design sets the lowest possible level of configuration management);capabilities of the software development tools (e.g. the units that the compiler or linkers input and output);bottom-level work packages defined in the SPMP.BaselinesA baseline' is a CI that has been formally reviewed and agreed upon (i.e. approved), and declared a basis for further development.Although any approved CI in a system can be referred to as a baseline, the term is normally used for the complete system.Early baselines contain only documents specifying the software to be built; later baselines contain the code as well.The CIs in a baseline must be consistent with each other. Examples of consistency are:code CIs are compatible with the design document CIs;design document CIs are compatible with the requirements document CIs;user manual CIs describe the operation of the code CIs.

VariantsThe term variant' is often used to identify CIs that, although offering almost identical functionality, differ in aspects such as: hardware environment; communications protocol; user language (e.g. English, French).Variants may also be made to help diagnose software problems.The usefulness of such variants is often temporary, and they should be withdrawn when the problem has been solved.Configuration item control authorityEvery CI should have a unique control authority that decides what changes will be made to a CI. The control authority may be an individual or a group of people. Three levels of control authority are normally distinguished in a software project: software author; software project manager; review board.Software authorSoftware authors create low-level CIs, such as documents and code. Document writers are usually the control authority for draft documents. Programmers are normally the control authority for code until unit testing is complete.Software project managerSoftware project managers are responsible for the assembly of high-level CIs (i.e. baselines and releases) from the low-level CIs provided by software authors. Software project managers are the control authorities for all these CIs. Low-level CIs are maintained in software libraries. On most projects the software project manager is supported by a software librarian.Configuration item historyThe development history of each CI must be recorded from the moment it is first submitted for review or integration. For documents, this history is stored in Document Change Records (DCRs) and Document Status Sheets (DSS).Change records in module headers should reference the Software Change Request (SCR) that actioned them. For derived code, the development history is stored in the librarian's database.The development history should include records of the tests that have been performed. The Software Modification Report (SMR) should summarise the changes to CIs that have been revised in response to an SCR.Configuration item storageAll CIs must be stored securely so that they never get lost. Software projects can accumulate thousands of low-level CIs, and just as books are stored in libraries, it is necessary to store low-level CIs in software libraries.The software libraries are themselves CIs.Software CIs reside on hardware media (e.g. paper, magnetic disk).Storage media must be maintained securely and safely so that software is never lost or its integrity compromised.Software librariesA software library is a controlled collection of configuration items (e.g. source module, object module and document). Low-level CIs are developed and stored in libraries (e.g. source and object libraries), and then extracted to build high-level CIs (e.g. executable images).As a minimum, every project must use the following software libraries to store CIs: development (or dynamic) libraries master (or controlled) libraries archive (or static) libraries Master libraries store CIs in the current baselines. Archive libraries store CIs in releases or retired baselines. CIs in archive libraries must not be modifiedAccess control to librariesAccess to software libraries should be controlled so that it is impossible: to access CIs without the correct authorisation; for two people to simultaneously update the same CI.Read access allows a CI to be examined or copied. Insert access right allows a new CI to be added to a software library. Delete access right allows a CI to be removed from a library. Replace right allows a CI to be removed from a library and another version inserted.

Development staff access rightsSoftware librarian access rightsTable 1 does not mean that a development library should be accessible to all developersApart from the software librarian, only the person directly responsible for developing or maintaining the CIs in a development library should have access to them. For sharing software, master libraries should be used, not development libraries.Simultaneous update occurs when two or more developers take a copy of a CI and make changes to it. When a developer returns a modified CI to the master library, modifications made by developers who have returned their CI earlier are lost. A charge-in/charge-out or locking mechanism is required to prevent simultaneous update.

Table 1: Development staff access rightsMedia controlAll CIs should be stored on controlled media (e.g. tapes, disks).Media should be labelled, both visibly (e.g. sticky label) and electronically (e.g. tape header). The label should have a standard format, and must contain the: project name configuration item identifier (name, type, version) date of storage content description Procedures for the regular backup of development libraries must be established. Up-to-date security copies of master and archive libraries must always be available . An aim of good media control is to be able to recover from media loss quickly.VERSION CONTROLVersion controlManagement of multiple revisions of the same unit of information.Changes identified by incrementing an associated number or letter code - revision number, or revision level.Revision numbers (levels) are associated historically with the person making the changeRepository A server where the files are stored.Check-Out copies a working copy from the repository (the opposite of an import).Change A specific modification to a document under version control.The granularity of the modification considered a change varies between version control systems.

Change List The set of changes made in a single commit. A sequential view of the source code.Commit or Check-inCopy the changes on the local files to the directory.(the VC software takes care of changes since the last synchronization).Updatecopies the changes that were made to the repository into your working directory.(opposite of a commit).Merge / Integration brings together (merges) concurrent changes into a unified revision.Revision or version one version in a chain of changes.Conflict Occurs when two changes are made by different parties to the same document or place within a document.Resolve The act of user intervention to address a conflict between different changes to the same document.

28ExampleCM ClientsCM ServerTrunkMachine AMachine BVersion B BranchVersion A BranchVersion A.1 BranchCheck OutACheck OutBMergeDCheck InCCheck InE

29HistoryCM systems save the files history.Old versions can be viewed, compared, and downloaded.New versions can be (irreversibly) replaced with old versions and wiped off the map.Central repositoriesFiles are saved in a central file server.Developers can view the files in the repository, through the use of filters.Several files can be labeled together.Allows :Access to the label as a whole set of files.Changes to the labeled files as a unit.Useful for marking product releases. Labels Check-inCopies a file into the database.The version you see is (usually) the latest version that was checked in.The old version is kept and can be accessed later.Check outCopies the database file to your personal folder, and raises a flag on the database copy.Need to check out before checking in.Undo check out (uncheck-out)The undo checkout command does just that the file returns to the status it had before it was checked out. This can be done even if changes have been made to the local copy of course, these do not go into the database!Problems with file sharingAll version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet?

Scenario Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry madewon'tbe present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lostor at least missing from the latest version of the fileand probably by accident.Versioning ModelsLock-Modify-Unlock Solution:Only one person can change a file at a time. Example: VSS.

Copy-Modify-Merge Solution:Users modify private copies only - in parallelPrivate copies are merged together into a new, final version. Example: CVS, Subversion.

36The Lock-Modify-Unlock Solution

Problems With LockingAdministrative problems: A user can lock a file and forget about it.Time is wasted while others wait to edit the file. Unnecessary serialization:Different parts of a file dont necessarily overlap. E.g.: Alice works on the beginning of a file, Bob wants to edit the end of the same file. False sense of security: Lets say Alice locks and edits file A, while Bob simultaneously locks and edits file B.Lets say 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.

38

The Copy-Modify-Merge SolutionRepository

A

AAviva and Arik both check out file A. Here, checkout has no locking effect its just a local copy.Read

ARead39

The Copy-Modify-Merge Solution Both edit their local files.

Repository

A

Arik

Aviva40

The Copy-Modify-Merge SolutionRepository

Aviva

Arik

AvivaAviva checks in her file to the repository first.Write41

The Copy-Modify-Merge SolutionRepository

Aviva

Arik

AvivaNow, Arik tries to check-in his file. He gets an up-to-date check errorWrite42

The Copy-Modify-Merge SolutionRepository

Aviva

A(=Aviva+Arik)

AvivaArik updates his local copy to contain the changes made by Aviva. Changes are added to the local file.During this merge, conflicts may occur.Read43

The Copy-Modify-Merge SolutionRepository

Aviva

B

AvivaA new merged file is created on Ariks machine.44

The Copy-Modify-Merge SolutionRepository

B

B

AvivaArik commits his file to the repository.Write45

The Copy-Modify-Merge SolutionRepository

B

B

BAviva updates her file from the repository.Read46THE SOFTWARE CONFIGURATION MANAGEMENT PLANIntroduction All software configuration management activities shall be documented in the Software Configuration Management Plan Each SCMP section must document all software configuration management activities, specifically the: organisation of configuration management; procedures for configuration identification; procedures for change control; procedures for configuration status accounting; tools, techniques and methods for software configuration management; procedures for supplier control; procedures for the collection and retention of records.IEEE Guide to Software Configuration Management contains examples of plans for: a complex, critical computer system; a small software development project; maintaining programs developed by other activities or organisations; developing and maintaining embedded software.Configuration management procedures must be in place before software production (code and documentation) startsSoftware configuration management procedures should be easy to follow and efficient. Wherever possible, procedures should be reusable in later phases.Instability in software configuration management procedures can impede progress in a software project.About SCMPSTYLEThe SCMP should be plain and concise. The document should be clear, consistent and modifiable.The author of the SCMP should assume familiarity with the purpose of the software, and not repeat information that is explained in other documents.RESPONSIBILITYThe developer is responsible for the production of the SCMP.MEDIUMIt is usually assumed that the SCMP is a paper document. There is no reason why the SCMP should not be distributed electronically to participants with the necessary equipment.

SCMP content

Reference:Guide to software configuration management by ESA Board for Software Standardisation and Control (BSSC), ESA PSS-05-09 Issue 1 Revision 1, March 1995Software Configuration Management Overview by Walter Tichyhttp://svnbook.red-bean.com/en/1.0/ch02s02.html

Thank you