A. Configuration Infrastructure
T he configuration infrastructure provides the organizational structure, tools, and processes that create the discipline upon which to build a consistent and effective software configuration management (SCM) system. The organizational structure requires project-level SCM groups and the specific assignment of SCM roles and responsibilities at the project level. It may also include the creation of an organizational-level SCM group with defined roles and responsibilities. The selection of the appropriate SCM tools and the establishment of SCM libraries, which support the established SCM system, greatly improve the ability to build, release, and distribute high-quality software products with the least amount of effort and allow organizations to retain and protect their software intellectual property.
1. CONFIGURATION MANAGEMENT TEAM
Describe the roles and responsibilities of a configuration management group. (Understand) [NOTE: The roles and responsibilities of the configuration control board (CCB) are covered in area VII.C.2.]
BODY OF KNOWLEDGE VII.A.1
Trained, qualified people are needed to perform the activities required to implement an effective SCM system both at an organizational level and at a project level. The number of people needed at each level depends on the size, complexity, and objectives of the organization and of the individual projects. In the case of large projects with hundreds of developers in geographically dispersed teams, with each team creating multiple software components, the project’s SCM group might include several full-time specialists. For a small project, with a few co-located developers creating a limited increment of functionality, the SCM group may consist of one or more individuals performing the SCM activities as just one of their multiple project responsibilities.
Organizational-Level SCM Group Roles and Responsibilities
Many organizations establish an organizational-level SCM function to oversee the SCM system. This centralized SCM group may select industry standards and models as guidance for their SCM program to leverage good industry practices and keep from “reinventing the wheel.” The organizational-level SCM group establishes, documents, and distributes standardized SCM policies, processes, and work instructions, as well as defining and implementing standardized metrics, that can be shared across multiple projects.
The organizational-level SCM group also defines, implements, and maintains an organizational-level SCM infrastructure, including:
Having a standardized SCM system and infrastructure benefits the organization by making it easier for individuals to move from project to project without a steep SCM learning curve. There may also be economy-of-scale benefits derived from having a few centralized experts who act as internal consultants to projects rather than requiring expert individuals on each project. Centralizing certain SCM responsibilities provides mechanisms for software reuse across projects and product lines and for transitioning lessons learned on individual projects into an integrated SCM system to improve practices across the organization. The organizational-level SCM group also performs SCM corrective actions and process improvements as needed.
Finally, an organizational-level SCM group provides a single conduit for management visibility and oversight of the organization’s SCM system. For example, the organizational-level SCM group acts as the review and approval authority as projects tailor the standardized SCM processes. This verifies that key elements are not tailored out or modified inappropriately.
Project-Level SCM Group Roles and Responsibilities
A project-level SCM group is responsible for planning, implementing, and controlling the project-specific SCM activities. Organizations that establish an organizational-level SCM function also need people at the project level who are responsible for project-specific SCM activities. This may be accomplished by having members of the organizational-level SCM group report on a dotted-line basis to the project or by having project-specific individuals assigned to SCM roles. For organizations that choose not to establish an organizational-level SCM function, the organizational-level responsibilities described previously become additional activities that are delegated to the project-level SCM group members as appropriate. However, this may increase the risk of inconsistent process execution and make people and other resources less interchangeable.
Each project-level SCM group performs SCM planning for their project by defining how that project intends to implement and tailor the organizational-level SCM policies, standards, processes, work instructions, and infrastructure to the needs of their specific project. Each project-level SCM group is responsible for making sure that planned SCM activities for their project are appropriately implemented and for tracking and controlling that implementation. These activities include:
In the agile context, the project-level SCM group should be “considered as a holistic part of the agile team.” The SCM activities listed above as well and the special SCM roles and responsibilities discussed below “are enacted by many on the team and not just one person” (based on Moreira 2010).
Special SCM Roles and Responsibilities
As part of, or in addition to, the organizational-level and project-level SCM groups, there may be individuals who perform special SCM roles. These roles include the SCM managers, SCM librarians, SCM toolsmiths, builders, release managers and software practitioners. Note that the roles and responsibilities of the configuration control board (CCB) are discussed in Chapter 26 , “Configuration Control and Status Accounting.”
SCM managers are responsible for managing the SCM groups at either the organizational or project level and for the overall success of the SCM program. This includes:
SCM librarians are responsible for establishing, coordinating, and verifying the integrity of the controlled and static libraries for each project and for coordinating the reuse of software components between projects. SCM librarian duties may include creating branches, performing merges, and establishing baselines (for example through labeling). SCM librarians may also be charged with performing backup and disaster recovery functions.
SCM toolsmiths, also called tool administrators, are responsible for the implementation and maintenance of the SCM tool set. These responsibilities include:
Builders are responsible for building source code modules into binary executables (or other constituent configuration items into composite configuration items, for example combining training chapters into completed training materials) and for verifying the reproducibility of those builds. This includes making sure that:
Release managers are responsible for packaging the software (or software intensive systems) into a releasable product set for deployment into the desired environment.
Software practitioners include requirements engineers/analysts, designers, programmers, testers, suppliers, and others who utilize the SCM processes as part of their responsibilities in creating, developing, and maintaining the software products. The SCM responsibilities of software practitioners include:
2. CONFIGURATION MANAGEMENT TOOLS
Describe configuration management tools as they are used for managing libraries, build systems, defect tracking systems. (Understand)
BODY OF KNOWLEDGE VII.A.2
Configuration management tools are used to automate the tedious and often error-prone work of manually performing the SCM activities, which include:
This automation can improve development efficiency, decrease cycle times, minimize human error, allow software work products and product information to be easily shared across large and geographically dispersed groups, and increase the integrity of product information. SCM tools are also extremely important in the agile context. A study by Moreira (2010), agile professional were asked, “how important are CM tools for agile projects?” Ninety-four percent of the respondents answered either “extremely important” (75 percent) or “very important” (19 percent).
SCM tools can influence how an organization works. Therefore, tools should be selected that match the organization’s SCM processes. An organization should not try to force-fit its processes to its SCM tools. If SCM process improvements are needed, they should be done in conjunction with selecting and/or upgrading the SCM tools that support those improvements. If the tool set is cumbersome or does not match the way software practitioners and others do their work, those individuals will often find ways to work around the tools or circumvent the controls provided by the tools. Other considerations when selecting a SCM tools include:
SCM Library and Version Control Tools
SCM library tools include the tools used to establish, maintain, and manage the various SCM libraries. These tools may range from simple scripts that are run to create static archives or nightly backups to sophisticated version control tools used to establish and manage the controlled libraries. Library tools may be separate tools or may be integrated with version control tools.
Version control tools handle the storage of multiple versions of individual configuration items. The tool assigns a unique identifier to each version of each configuration item so that it can be referenced and retrieved as needed. Typically, the versions are stored as either forward or backward deltas to conserve space. In a backward delta system, the latest version of the item is saved along with the deltas between it and the previous versions. A forward delta system saves the original version and deltas going forward. For example, if the fifth version of a source code module were retrieved in a forward delta system, the tool would take the original file and apply four deltas to it to create the fifth version.
For configuration items like requirements or test cases, requirements management tools or test management tools may provide the mechanisms needed for version control.
Version control tools typically have some kind of labeling mechanism that allows baselined versions of configuration items to be identified and related to other items in the same baseline. For example, when a new baseline is created, all of the work products included in that baseline are labeled with that baseline’s identifier. More sophisticated version control systems include automated promotion management as software development moves through the various life cycle phases.
Integrated version control tools work in conjunction with change management and build tools. These integrated tools allow change requests to be linked to the versions of the configuration items that incorporated the requested change and make certain that the correct versions of the appropriate configuration items are used when new builds are created.
Content management tools may be more appropriate than version control tools for web applications. Content management tools manage versions of the content as it evolves, including the ability to create, review/edit, publish, and view the content.
SCM Build Tools
A software build is the process of combining smaller software constituent configuration items into larger composite configuration items. Figure 24.1 illustrates the build process used to convert individual software source code module into one or more software executables that can be run on a computer. SCM build tools include :
Build tools capture the details of the build and build processes so that the build can be reproduced as needed. For example, details could include what version of each configuration item was used and what switches or options were used for the complier or linker.
SCM Change Management Tools
SCM change management tools automate the change control processes through which changes to the software are requested, impact analysis is performed, change requests are approved, deferred or disapproved, and approved change requests are tracked through implementation, verification, and closure. Change management applies to both reported problems (failures, potential defects) and enhancement requests (requirements changes). Some organizations use multiple defect tracking and/or enhancement request tools while other organizations use a single integrated change management tool to track both defects and enhancement requests. Depending on their sophistication, these change management tools can be used to:
Figure 24.1 Software build process.
Through integration with the version control tool, the change management tool can:
SCM Status Accounting Tools
SCM tools can automatically provide much of the information required for good status accounting and traceability that would otherwise require a monumental manual effort to document and maintain. SCM status accounting tools may be separate tools or they may be built into the other SCM tools as reporting mechanisms. SCM status accounting tools harvest data recorded in the other SCM tools (version control tools, build tools, change management tools) to provide information for both ad hoc queries and standardized reports. This data and information support management and engineering decision-making processes, including software metrics and measurement. Status accounting information also supports the ability to perform SCM audits.
Other SCM Tools
Other SCM tools include:
3. LIBRARY PROCESSES
Describe dynamic, static, and controlled library processes and related procedures, such as check-in/check-out, merge changes). (Understand)
BODY OF KNOWLEDGE VII.A.3
There is a dichotomy in SCM. On one side, individual developers need the flexibility necessary to do creative work, to modify code to try out what-if scenarios, and to make mistakes, learn from them, and evolve better software solutions. On the other side, teams need stability to allow code to be shared with confidence, to create builds and perform testing in a consistent environment, and to ship high-quality products with confidence. This requires an intricate balance to be maintained. One of the ways that SCM supports this need for both flexibility and stability is through the use of different SCM libraries. The number and kinds of libraries used in SCM will vary based on the size, criticality, and requirements of each project. The contents of each library will also vary based on the types and formats of the various work products. There are four kinds of SCM libraries:
For each library used by a project, SCM planning should identify the name and type of the library, the information retention method (for example, online or offline, media used, tool used), the control mechanisms, and the retention policies and procedures.
Dynamic Library
A dynamic library, also called a development, programmer’s, or working library, or sandbox, is used to hold products that are currently being worked on by the software practitioner (developers, testers, or other project personnel). Each practitioner typically has one or more dynamic libraries under his/her personal control that are used as personal work areas. The contents of a dynamic library are not considered to be under configuration control.
The dynamic library provides a mechanism for creating private working copies of new work products or obtaining copies of baselined work products approved for modification. Utilizing these copies, the developers can create new work products or make changes to existing products without affecting anyone else or impacting the integrity of the controlled copies. This gives the developer the flexibility needed to:
Another example of a dynamic library is the work area used by testers for test execution. This allows tests to be performed that might cause failures that corrupt the software or data without impacting the work of other software practitioners. This dynamic test library is part of the test bed and is under the control of the tester.
Controlled Library
A controlled library, also called a master or system library, is used for managing current controlled configuration items and baselines, and controlling changes to those items and baselines. The controlled library contains configuration items that have been acquired and placed under formal change control. The controlled library may be made up of one or more actual libraries, directories, or repositories depending on the needs of the project. Different libraries might be used to store different types of configuration items (source code, documentation, hardware, drawings). Controlled libraries may also be implemented as areas or codelines inside a tool, such as a version control tool.
The controlled library is used to share work products with other members of the project team or other stakeholders. Software practitioners can freely obtain “read-only” copies of the configuration items from the controlled library and move them into their dynamic libraries. However, the appropriate authority must authorize changes to work products in the controlled library. Work products from the controlled library are used to create official software builds from a “known” environment, such as builds used for testing and for release.
Static Library
A static library, also called a software repository, archive library or software product baseline library is used to archive important baselines, including those released into operations. Static libraries can also be used to archive (“freeze”) various intermediate baselines as appropriate during the development process. Items in the static libraries can be accessed through read-only mechanisms and are not modifiable.
Backup Library
A backup library contains duplicates of the versions of the software and associated components, data, and documentation at the time that the copies were made. Backups are performed on a periodic basis to make sure that the intellectual property of the organization is protected. Back-up versions can be retrieved if important files are accidentally deleted, a modified work product needs to be rolled back to a previous version, or if a hard disk crashes or other disasters occur.
SCM Library Process: Creating a New Software Work Product
A dynamic library is used when new software work products are created. For example, as illustrated in Figure 24.2 , the library process steps to create a new work product include:
Step 1: The author creates and saves a new software work product ABC in a dynamic library. Examples of work products include a source code module, a document (plan, user manual, and training manual), a test case or procedure, a data file, or a build script.
Figure 24.2 Creating a new software work product.
Step 2: The author reviews and/or tests the newly created work product ABC and makes whatever updates are necessary to correct any defects found. The review process might include static analysis, peer reviews and/or other types of reviews involving other software practitioners.
Step 3: When the author is satisfied that the work product is ready to share and the appropriate acquisition criteria has been met, the author checks work product ABC into the controlled library and a unique identifier is assigned to indicate the name of the work product and its version (for example, ABC 1.0).
Once a new work product has been checked into the controlled library, it is under formal change control and can be modified only through formal change control processes.
The check-in process includes the capturing of information about the work product, including:
SCM Library Process: Creating a Software Build
While software builds can be created in a dynamic library, official software builds are created from the configuration items in a controlled library. This is done so that the build is created from controlled items in a controlled environment where build information is captured to make sure that the build is reproducible. For example, as illustrated in Figure 24.3 , the library process steps to creating a software build include:
Step 1: The builder executes the build script using controlled constituent configuration items as inputs. The builder may be a person creating the build manually, or the build may be created automatically.
Automatic builds may be done on a periodic basis, for example, every hour. Special events may also be used to initiate an automatic build, for example, when a new version of any of a set of specified constituent configuration items is checked in to the controlled library.
Figure 24.3 Creating a software build.
Step 2: The output of this execution is the software build, which is typically stored as a controlled composite configuration item in the controlled library and assigned a unique identifier.
SCM Library Process: Testing a Software Build
Assuming that the tester has already created a set of test work products (test cases, procedures, scripts, and data) and checked them into the controlled library, the library process steps for testing a software build include:
Step 1: A tester checks out read-only copies of the build and necessary test work products from the controlled library into the dynamic library used for testing (test bed). If testing is automated as part of an integrated build script, the script would move the build and appropriate test work products to a specified dynamic library.
Step 2: The tester, or the automated script, executes one or more tests and the results are either observed or recorded. An evaluation is then performed to determine if the actual results of the test matched the expected results. If the test is performed automatically, any anomalies encountered are reported to the appropriate individual(s).
Step 3: For manual testing, the tester reports any problems encountered during testing, with either the build or the test work products, into the change request (problem reporting) database. For automated testing, the person receiving the anomaly report interprets that anomaly and documents any indentified problems into the change request database as appropriate.
Figure 24.4 illustrates this process for manual testing performed by a tester.
SCM Library Process: Modifying a Controlled Work Product
Once the appropriate level of authority approves a change request (problem report or enhancement request), one or more controlled work products are updated to incorporate that approved change. The library process steps to modify an existing controlled work product include:
Step 1: As illustrated in Figure 24.5 , the assigned author checks out a read/write copy of each work product that needs to be updated from the controlled library into a dynamic library based on the impact analysis of the approved change request. The controlled library locks each work product checked out for modification so that other team members know it is being updated. This allows other team members to retrieve read-only copies but does not allow them to be checked out for modification. Note that some tools do not use locking, as they are sophisticated enough to allow for concurrent development and will enable developer reconciliation of multiple changes as copies of updated work products are checked back into the controlled library.
Figure 24.4 Testing a software build.
Figure 24.5 Modifying a controlled work product—check out process.
Step 2: As illustrated in Figure 24.6 , the author then makes the required changes to the copy of the checked-out work product based on the approved change request. The author saves the corrected copy in the dynamic library. The author then reviews and/or tests the updated work product and makes whatever additional updates are necessary to correct any defects found.
Figure 24.6 Modifying a controlled work product—modification process.
Figure 24.7 Modifying a controlled work product—check in process.
Step 3: As illustrated in Figure 24.7 , when the author is satisfied that each changed work product is ready to share and the appropriate acquisition criteria has been met, the author checks each updated work product back into the controlled library, and an updated version number is assigned to each work product as appropriate. As it is checked in, the control library unlocks each work product so that both the previous and the new versions of those work products are available for future modification. The author updates the work product library information as each product is checked in and should also update the change request with new status information.
SCM Library Process: Branching
Consider the main codeline example in Figure 24.8 . Each label in this example represents the versions of a set of constituent configuration items that were used to create a build. Assume label 2 represents a build that has been released into operations and label 3 represents a build that is currently under test and that contains new functionality updates to configuration items CI #1 and CI #2. A problem report comes in from operations. The label 2 build is debugged and a defect is found in version 4 of configuration item CI #1. Version 4 can not just be fixed and checked back in as version 8 because that would lose the new functionality and/or corrections added in versions 5, 6, and 7. On the other hand, the defect can not just be fixed in version 7 to create a new build for operations (assuming that the defect even still exists in version 7 after the changes that have been made) for reasons that include the fact that the new functionality in version 7:
Figure 24.8 Main codeline—example.
Branching is the software process of creating a new codeline containing one or more configuration items that are duplicated from an existing codeline in a controlled library. Branching the codeline can provide the flexibility needed to support multiple versions of the product at the same time and solve problems like the one described above. As illustrated in Figure 24.9 , a new codeline can be created from all of the work products in label 2. For example, version 4 of configuration item CI #1 is copied into the branched codeline, becoming version 4.1, and version 1 of configuration item CI #2 becomes version 1.1, and so on. Version 4.1 of configuration item CI #1 can then be checked out and modified to correct the defect. The updated CI #1 is then checked back in as version 4.2 into the branched codeline. The corrective build label 2.1 can now be created and released into operations containing the fix to the reported problem. At the same time new development can continue on the main codeline.
Another example of where a branched codeline might be useful is to “freeze” a version of the product build for a testing cycle. Critical fixes that allow testing to continue can be done to the branched codeline, while new development continues on the main codeline. Branching may also be used to create customized versions of work products or for concurrent, parallel development that allows multiple people to work on the same files at the same time. Branches can be taken from the original codeline, or branches can be taken from other branches. However, caution should be used when branching is implemented. Branching is the most complex of the library processes. Without a strong and disciplined branching strategy, chaos can quickly take over with multiple copies of many configuration items needing to be supported. A well-structured branching approach that minimizes the number of active branches at any given time reduces complexity.
Figure 24.9 Branching—example.
One useful branching strategy is to make sure that new development is always done on the main codeline (or trunk). The advantage of this is that the branched product releases, or other branches off the main codeline, are relatively temporary in nature. Once testing is complete on a frozen branch or once a released version of the product is no longer supported in operations, its associated branch can be archived as necessary and removed in order to minimize the number of branches off the main codeline.
SCM Library Process: Merging
Consider the defect that was corrected in the operations release label 2.1 build discussed in the last section. The current operations problem was solved with this corrective release. If this defect also exists in configuration item CI #1 versions 5, 6, and 7 and it is not corrected, there is a risk that a future release of the product may bring back an old problem, resulting in very unhappy stakeholders. One answer to this is to check out version 7 of configuration item CI #1, edit the file to make the same correction a second time, and check it back in as version 8. Another answer is called merging, taking two or more versions of a work product and combining them into a single new version. In the example above, version 4.2 (with the correction) could be merged with version 7 (with the new functionality) to create a new version 8, as illustrated in Figure 24.10 . Of course, merging can be done in the opposite direction, with changes being merged from the main codeline into items on a branched codeline.
Merging can also be used to combine functionality added on several concurrent, parallel development branches back into the main codeline. However, if multiple developers changed the same work product, several variations can arise:
Figure 24.10 Merging—example.
In any case, once the merge is accomplished, the resulting new version should be tested to verify that the merge did not result in new defects that were not identified during the merge analysis process.