Subpractice 2: Obtain appropriate authorization before changed configuration items are entered into the configuration management system. For example, authorization may come from the CCB, the project manager, or the customer.
Subpractice 3: Check in and check out configuration items from the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of the configuration items. Examples of check-in and check-out steps include the following: Confirming that the revisions are authorized Updating the configuration items Archiving the replaced baseline and retrieving the new baseline Subpractice 4: Perform reviews to ensure that changes have not caused unintended effects on the baselines e.
Subpractice 5: Record changes to configuration items and the reasons for the changes as appropriate. If a proposed change to the work product is accepted, a schedule is identified for incorporating the change into the work product and other affected areas.
Configuration control mechanisms can be tailored to categories of changes. For example, the approval considerations could be less stringent for component changes that do not affect other components. Changed configuration items are released after review and approval of configuration changes. Changes are not official until they are released. SG 3 Establish Integrity Integrity of baselines is established and maintained.
The integrity of the baselines, established by processes associated with the Establish Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is provided by the specific practices under this specific goal.
Typical Work Products Revision history of configuration items Change log Copy of the change requests Status of configuration items Differences between baselines Subpractice 1: Record configuration management actions in sufficient detail so the content and status of each configuration item is known and previous versions can be recovered.
Subpractice 2: Ensure that relevant stakeholders have access to and knowledge of the configuration status of the configuration items.
Examples of activities for communicating configuration status include the following: Providing access permissions to authorized end users Making baseline copies readily available to authorized end users Subpractice 3: Specify the latest version of the baselines.
Subpractice 4: Identify the version of configuration items that constitute a particular baseline. Subpractice 5: Describe the differences between successive baselines. Subpractice 6: Revise the status and history i. Configuration audits confirm that the resulting baselines and documentation conform to a specified standard or requirement.
Audit results should be recorded as appropriate. See the glossary for a definition of configuration audit. Examples of audit types include the following: Functional Configuration Audits FCA Audits conducted to verify that the as-tested functional characteristics of a configuration item have achieved the requirements specified in its functional baseline documentation and that the operational and support documentation is complete and satisfactory.
Physical Configuration Audit PCA Audits conducted to verify that the as-built configuration item conforms to the technical documentation that defines it. Configuration management audits Audits conducted to confirm that configuration management records and configuration items are complete, consistent, and accurate.
Subpractice 2: Confirm that the configuration management records correctly identify the configuration items. Subpractice 3: Review the structure and integrity of the items in the configuration management system.
Subpractice 4: Confirm the completeness and correctness of the items in the configuration management system. Completeness and correctness of the content is based on the requirements as stated in the plan and the disposition of approved change requests. Subpractice 5: Confirm compliance with applicable configuration management standards and procedures. Subpractice 6: Track action items from the audit to closure. Generic Practices by Goal GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products.
Elaboration: This policy establishes organizational expectations for establishing and maintaining baselines, tracking and controlling changes to the work products under configuration management , and establishing and maintaining integrity of the baselines. Elaboration: This plan for performing the configuration management process can be included in or referenced by the project plan, which is described in the Project Planning process area.
Elaboration: Examples of resources provided include the following tools: Configuration management tools Data management tools Archiving and reproduction tools Database programs GP 2. Builds A build is the business of constructing usable software from original source files. The only ingredients in a build should be source files and the tools to which they are input. Memorized procedures and yellow stickies have no place in this equation.
Given the same source files and build tools, the resulting product should always be the same. If you have rote setup procedures, automate them in scripts. If you have manual setup steps, document them in build instructions.
And document all tool specifications, including OS, compilers, include files, link libraries, make programs, and executable paths. Frequently overlooked ingredients are makefiles, setup scripts, build scripts, build instructions, and tool specifications. All of these are the source you build with. Organize your builds so that the directories containing original source files are not polluted by built objects.
Built objects are all the files that get created during your build process, including generated source files. Built objects should not go into your source code directories. Instead, build them into a directory tree of their own. This segregation allows you to limit the scope of SCM-managed directories to those that contain only source. Developers, test engineers, and release engineers should all use the same build tools.
Much time is wasted when a developer cannot reproduce a problem found in testing, or when the released product varies from what was tested. Every codeline branch should be subject to regular, frequent, and complete builds and regression testing, even when product release is in the distant future.
For any built object you produce, you should be able to look up the exact operations e. Archive build outputs and logs, including source file versions e. As large software projects evolve, components are handed off from one group to another, and the receiving group may not be in a position to begin builds of new components immediately.
When they do begin to build new components, they will need access to previous build logs in order to diagnose the integration problems they encounter. Process It would take an entire paper, or several papers, to explore the full scope of SCM process design and implementation, and many such papers have already been written. Furthermore, your shop has specific objectives and requirements that will be reflected in the process you implement, and we do not presume to know what those are.
Even though each file in a codeline has its revision history, each revision in its history is only useful in the context of a set of related files. Change packages, not individual file changes, are the visible manifestation of software development.
One clear benefit of tracking change packages is that it becomes very easy propagate logical changes e. When troubleshooting, you can compare the current running configuration to previous working versions to help understand if configuration is linked to the problem in any way.
We recommend maintaining three to five previous working versions of the configuration. When these services are enabled on Cisco network devices, the userid and timestamp is added to the configuration file at the time the configuration change is made. This stamp is then copied with the configuration file to the configuration version control system.
TACACS can then act as a deterrent for unmanaged change and provide a mechanism to properly audit changes that occur. Topology documentation aids in the understanding and support of the network. You can use it to validate design guidelines and to better understand the network for future design, change, or troubleshooting. Topology documentation should include both logical and physical documentation, including connectivity, addressing, media types, devices, rack layouts, card assignments, cable routing, cable identification, termination points, power information, and circuit identification information.
Maintaining topology documentation is the key to successful configuration management. To create an environment where topology documentation maintenance can occur, the importance of the documentation must be stressed and the information must be available for updates.
We strongly recommend updating topology documentation whenever network change occurs. Network topology documentation is typically maintained using a graphics application like Microsoft Visio. Other products like Visionael provide superior capabilities for managing topology information.
Configuration management performance indicators provide a mechanism to validate and audit network configuration standards and critical success factors. By implementing a process improvement program for configuration management, you can use the performance indicators to identify consistency issues and improve overall configuration management.
We recommend creating a cross-functional team to measure configuration management success and improve configuration management processes. The first objective of the team is to implement configuration management performance indicators in order to identify configuration management issues.
We'll discuss the following configuration management performance indicators in detail:. After evaluating the results from these audits, initiate a project to fix inconsistencies and then determine the initial cause of the problem.
Potential causes include a lack of standards documentation or a lack of a consistent process. You can improve standards documentation, implement training, or improve processes to prevent further configuration inconsistency. We recommend monthly audits, or possibly quarterly if only validation is needed. Review past audits to confirm that past problems are resolved.
Look for overall improvements and goals to demonstrate progress and value. Create metrics to show the quantity of high-risk, medium-risk, and low-risk network configuration inconsistencies. The configuration integrity check should evaluate the overall configuration of the network, its complexity and consistency, and potential issues. For Cisco networks, we recommend using the Netsys configuration validation tool.
This tool inputs all device configurations and creates a configuration report that identifies current problems such as duplicate IP addresses, protocol mismatches, and inconsistency. The tool reports any connectivity or protocol issues, but does not input standard configurations for evaluation on each device. You can manually review configuration standards or create a script that reports standard configuration differences.
Technically, every team employs some form of SCM, whether they intend to or not. The aim of this article, however, it to define effective SCM and discuss how to accomplish it. The goal of SCM is to improve the speed of and quality of software development by catching errors early and enabling quick fixes when they occur.
Each pattern represents a step where code is either written, tested, or integrated into another pattern and eventually released as a new version of the software. Steve Berczuk is an engineer at FitBit who literally wrote the book on software configuration management patterns. He outlines 16 different patterns that work together to help agile teams manage their software configurations.
Below is a visualization of the patterns laid out by Berczuk. There are 3 categories of patterns according to Berczuk: core patterns, workspace patterns, and codeline patterns. Core patterns define the current state of the software. All changes by developers are eventually funneled into this single stream of code. But what would happen is multiple developers were trying to make changes to the main line at the same time?
This is where SCM starts to play a role. In effective SCM, there are other patterns that ensure the main line does not break. The active development line is the working draft of the main line. It is a crucial component of agile development because it allows teams to develop and release changes more frequently with reduced risk of breaking the main line.
Workspace patterns are where actual development occurs. These patterns feed into the active development line and eventually the main line. Other patterns then feed into the private workspace and enable developers to build, integrate, and test along the way.
These patterns include:. Each pattern requires a set of rules and guidelines in order to remain effective. These are called codeline policies. The codeline policies also dictate what tests and integrations need to occur before code is released upstream.
0コメント