Configurationmanagement What 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 definition • Identification: 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 can’t reproduce the error in this configuration.” • "I fixed this problem long ago. Why did it reappear?“ • "The online documentation doesn’t 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 won’t 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 environment • A 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. • version of the mouse. many subparts. • Each of these parts. is made of many. processor. thousands. hard drive. • The next thing that must be recorded is which versions of these parts go together. and monitor go together to make a complete system. all of which must go together to have a working unit. or tens of thousands of parts. such as a hard drive. Software development and maintenance phases and CM . Configurati on manageme nt Documenta tion CM Code CM . • software components never get lost (e.WHY CM? • Software configuration management must ensure that: • software components can be identified. • every change to the software is approved and documented.g. after media failure or operator error). so that is always possible to discover who did what and when. through simultaneous updates). .g. • it is always possible to go back to a previous version. • changes do not get lost (e. • a history of changes is kept. • software components are available and accessible. • software is built from a consistent set of components. identification. . item storage. • modifications that result. change control. • changes that are proposed to solve the problem. status accounting. • Changes to baselines must be controlled throughout the life cycle by documenting the: • problems.• Software develops from baseline to baseline until it can be released. • ESA PSS-05-0 identifies five primary configuration management activities: • • • • • configuration configuration configuration configuration release. so that they can be understood. Software Configuration Management Activities (Software configuration management plan) SPMP – Software project management plan . and treated as a single entity in the configuration management process • A CI can be an aggregation of other CIs. each being a separate CI. • Examples of configuration items(CI) are: • software component. software or both that is designated as a unit for configuration management. • Any member of this hierarchy can exist in several versions. • support software item.Important concepts and terms in CM • Component Item (CI) • A CI is an aggregation of hardware. . • release. organised in a hierarchy. such as a software system in operational use. such as a version of a source module. • baseline. object module. executable program or data file. • document. such as a version of a compiler or a linker. such as a software system under development. such as an ADD. There are three main types of CI: • · source CIs. . • · derived CIs.Types of CI • The type field of a CI identifier should identify the processing the CI is intended for. • · tools to generate derived CIs from source CIs. • bottom-level work packages defined in the SPMP. the units that the compiler or linkers input and output).g. • describe the history of a CI.Configuration identification • Configuration identification conventions should state how to: • name a CI. • Several factors may be relevant in deciding what to identify as the lowest level CI. • decide who is the control authority of a 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). . the whole system is a CI. • At the top level. • capabilities of the software development tools (e. and declared a basis for further development. later baselines contain the code as well. • Early baselines contain only documents specifying the software to be built. . • The CIs in a baseline must be consistent with each other. • user manual CIs describe the operation of the code CIs. Examples of consistency are: • code CIs are compatible with the design document CIs. • design document CIs are compatible with the requirements document CIs. • Although any approved CI in a system can be referred to as a baseline. approved).Baselines • A ‘baseline' is a CI that has been formally reviewed and agreed upon (i.e. the term is normally used for the complete system. English.g. and they should be withdrawn when the problem has been solved. differ in aspects such as: • · hardware environment. • The usefulness of such variants is often temporary. • Variants may also be made to help diagnose software problems. French).Variants • The term ‘variant' is often used to identify CIs that. • · communications protocol. • · user language (e. although offering almost identical functionality. . • · software project manager.Configuration item control authority • Every 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. . • · review board. Software author • Software authors create low-level CIs. • Programmers are normally the control authority for code until unit testing is complete. such as documents and code. • Document writers are usually the control authority for draft documents. . baselines and releases) from the low-level CIs provided by software authors.e. • Low-level CIs are maintained in software libraries. . • On most projects the software project manager is supported by a software librarian. • Software project managers are the control authorities for all these CIs.Software project manager • Software project managers are responsible for the assembly of high-level CIs (i. • For documents. • 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 history • The development history of each CI must be recorded from the moment it is first submitted for review or integration. this history is stored in Document Change Records (DCRs) and Document Status Sheets (DSS). . • For derived code. • Change records in module headers should reference the Software Change Request (SCR) that actioned them. the development history is stored in the librarian's database. g. • Storage media must be maintained securely and safely so that software is never lost or its integrity compromised. and just as books are stored in libraries. it is necessary to store low-level CIs in software libraries. • Software CIs reside on hardware media (e.Configuration item storage • All CIs must be stored securely so that they never get lost. • The software libraries are themselves CIs. • Software projects can accumulate thousands of lowlevel CIs. paper. magnetic disk). . object module and document).g. • Archive libraries store CIs in releases or retired baselines. source and object libraries). • As a minimum. and then extracted to build high-level CIs (e.g.g. • Low-level CIs are developed and stored in libraries (e. executable images). 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.Software libraries • A software library is a controlled collection of configuration items (e. source module. • CIs in archive libraries must not be modified . Access control to libraries • Access to software libraries should be controlled so that it is impossible: • · to access CIs without the correct authorisation. • Replace right allows a CI to be removed from a library and another version inserted. Development staff access rights Software librarian access rights . • Read access allows a CI to be examined or copied. • Delete access right allows a CI to be removed from a library. • · for two people to simultaneously update the same CI. • Insert access right allows a new CI to be added to a software library. • Simultaneous update occurs when two or more developers take a copy of a CI and make changes to it. Table 1: Development staff . master libraries should be used. 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. For sharing software. only the person directly responsible for developing or maintaining the CIs in a development library should have access to them. • When a developer returns a modified CI to the master library.• Table 1 does not mean that a development library should be accessible to all developers • Apart from the software librarian. not development libraries. g. and must contain the: • • • • · · · · project name configuration item identifier (name.g. both visibly (e. disks). . type. • An aim of good media control is to be able to recover from media loss quickly. sticky label) and electronically (e. tapes. version) date of storage content description • Procedures for the regular backup of development libraries must be established. • Media should be labelled.Media control • All CIs should be stored on controlled media (e. • The label should have a standard format. • Up-to-date security copies of master and archive libraries must always be available . tape header).g. VERSION CONTROL . • Changes identified by incrementing an associated number or letter code . • Change • A specific modification to a document under version control. . • Check-Out • copies a working copy from the repository • (the opposite of an import). or “revision level”.“revision number”.• Version control • Management of multiple revisions of the same unit of information. • The granularity of the modification considered a change varies between version control systems. • Revision numbers (levels) are associated historically with the person making the change • Repository • A server where the files are stored. • Commit or Check-in • Copy the changes on the local files to the directory. . • Update • copies the changes that were made to the repository into your working directory. • Conflict • Occurs when two changes are made by different parties to the same document or place within a document. • Merge / Integration • brings together (merges) concurrent changes into a unified revision. • (opposite of a commit). • Revision or version • one version in a chain of changes. • Resolve • The act of user intervention to address a conflict between different changes to the same document. • (the VC software takes care of changes since the last synchronization).• Change List • The set of changes made in a single commit. • A sequential view of the source code. 1 Branch Check Out Check In C A Machine B B Check Out D Merg e E Check In Version B Branch .Example CM Clients Trunk CM Server Version A Branch Machine A Version A. • New versions can be (irreversibly) replaced with old versions and ‘wiped off the map’. compared.History • CM systems save the files’ history. . • Old versions can be viewed. and downloaded. .Central repositories • Files are saved in a central file server. • Allows : • Access to the label as a whole set of files. • Developers can view the files in the repository. Labels • Several files can be labeled together. • Useful for marking product releases. through the use of filters. • Changes to the labeled files as a unit. Check out • Copies the database file to your personal folder. • The version you see is (usually) the latest version that was checked in. • The old version is kept and can be accessed later. and raises a flag on the database copy. • Need to check out before checking in. .Check-in • Copies a file into the database. • This can be done even if changes have been made to the local copy – of course. these do not go into the database! .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. Problems with file sharing • All 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? . Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident. .Scenario • Suppose we have two co-workers. While Harry's version of the file won't be lost forever (because the system remembers every change). Harry and Sally. any changes Harry made won't be present in Sally's newer version of the file. If Harry saves his changes to the repository first. They each decide to edit the same repository file at the same time. because she never saw Harry's changes to begin with. then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. Subversion.in parallel • Private copies are merged together into a new. Copy-Modify-Merge Solution: • Users modify private copies only . • Example: VSS. • Example: CVS. final version.Versioning Models Lock-Modify-Unlock Solution: • Only one person can change a file at a time. . The Lock-Modify-Unlock Solution . • E. . while Bob simultaneously locks and edits file B. Bob wants to edit the end of the same file. • Unnecessary serialization: • Different parts of a file don’t necessarily overlap. and the changes made to each are semantically incompatible. • Suddenly.: Alice works on the beginning of a file.g. • False sense of security: • Let’s say Alice locks and edits file A. A and B don't work together anymore. • Time is wasted while others wait to edit the file.Problems With Locking • Administrative problems: • A user can lock a file and forget about it. • Let’s say A and B depend on one another. A Repository A Read A . Here. checkout has no locking effect – it’s just a Read local copy.The Copy-Modify-Merge Solution Aviva and Arik both check out file A. The Copy-Modify-Merge Solution Both edit their local files. Repository A Aviva Arik . The Copy-Modify-Merge Solution Aviva checks in her file to the repository first. Repository Aviva Write Aviva Arik . He gets an “upto-date check error” Write Arik Repository Aviva Aviva .The Copy-Modify-Merge Solution Now. Arik tries to check-in his file. conflicts may occur. During this merge. Changes are added to the local file.The Copy-Modify-Merge Solution Arik updates his local copy to contain the changes made by Aviva. Read A’ (=Aviva+Arik ) Repository Aviva Aviva . The Copy-Modify-Merge Solution A new merged file is created on Arik’s machine. Repository Aviva Aviva B . Repository B Write B Aviva .The Copy-Modify-Merge Solution Arik commits his file to the repository. The Copy-Modify-Merge Solution Aviva updates her file from the repository. Repository B Read B B . THE SOFTWARE CONFIGURATION MANAGEMENT PLAN . specifically the: • • • • • · organisation of configuration management.Introduction • All software configuration management activities shall be documented in the Software Configuration Management Plan • Each SCMP section must document all software configuration management activities. · procedures for configuration status accounting. · tools. · procedures for change control. · procedures for configuration identification. techniques and methods for software configuration management. • · procedures for supplier control. . • · procedures for the collection and retention of records. • · developing and maintaining embedded software. • Instability in software configuration management procedures can impede progress in a software project. • · a small software development project.• IEEE Guide to Software Configuration Management contains examples of plans for: • · a complex. critical computer system. . procedures should be reusable in later phases. • · maintaining programs developed by other activities or organisations. • Configuration management procedures must be in place before software production (code and documentation) starts • Software configuration management procedures should be easy to follow and efficient. • Wherever possible. • RESPONSIBILITY • The developer is responsible for the production of the SCMP. • MEDIUM • It is usually assumed that the SCMP is a paper document. consistent and modifiable. • There is no reason why the SCMP should not be distributed electronically to participants with the necessary equipment. • The document should be clear. . and not repeat information that is explained in other documents. • The author of the SCMP should assume familiarity with the purpose of the software.About SCMP • STYLE • The SCMP should be plain and concise. SCMP content . 0/ch02s02.html Thank you . March 1995 • Software Configuration Management Overview by Walter Tichy • http://svnbook.redbean.com/en/1.• Reference: • Guide to software configuration management by ESA Board for Software Standardisation and Control (BSSC). ESA PSS-05-09 Issue 1 Revision 1.