Roles: Configuration-Manager

"Area Path" and "Iteration Path" are standard fields in Azure DevOps (ADO), and they are used to organize work items by product classification, team, and time period.

Definition

For an introduction to the concept of baselining, see the Highlevel baseline guide.

This guide describes the recommended branching strategy to manage code repositories.

Code signing is a crucial process in software development that ensures the integrity and authenticity of software code. It involves applying a digital signature to software programs, scripts, or drivers.

This conceptual guide explains the purpose of configuration audits and presents the main parts of a configuration audit and the highlevel approach adopted in PCP.

Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items. [IEEEStandard7291983].

The configuration manager has the overall responsibility for the strategy, process, and implementation of the configuration management (CM) system.

This is the overall description of how to handle configuration release management within ABB PCP.

In the example below is a description of needed access rights for a user (or AD group) to be able to use OpsHub to replicate work items between collections/organizations.

The term Document Management includes both Office files and wiki pages. While the general processes are the same – such as version control, review, and approval – the specific procedures for each type of document differ and are described in the relevant guides.

This guideline outlines how to organize and manage product and project documents during development and maintenance. It applies only to internal R&D documents at the product and project level, not for publication through the ABB Library or other channels.

An existing Azure DevOps (ADO) project onpremises or in the cloud may differ from the current standard PCP work item templates due to historical reasons or tailoring. This guide lists the steps and tools to adopt standard work item templates in an existing ADO project with existing data.

This guide focuses on describing the practical change of the work item, starting from a process change request received, to the completion of a pull request updating the template.

Introduction

A bug can exist in multiple releases, and such bugs can be challenging to track and fix. This guide describes how to manage them.

During the development of a release, if a bug is found but the CCB decides to fix it in a later version, the bug is deferred. After the official release, it will then be a known bug in the product or system.

A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.

When starting a new project there are several tasks to be performed to ensure that tools and systems are well set up when M0/G0, M1/G1, and M2/G2 are reached.

Dashboard creation can be repetitive and time consuming. This guide describes how to manage dashboards automatically.

Query creation can be repetitive and time consuming. This guide describes how to manage queries automatically.

The purpose of configuration auditing is to objectively assess the integrity of a product, both from a functional and physical perspective.

Defining a team in Azure DevOps (ADO) allows the use of planning and visualization features, for example, the team backlog, sprints, capacity planning, boards, and team dashboard.

A Product lifecycle management (PLM) system enables collaboration between different functions by gathering all productrelevant data in one place. For hardware development, the choice is in Windchill. This page intends to be a goto page for how to find information regarding Windchill.

What is a pull request?

This page contains a list of Azure DevOps extensions that are preapproved for use in PCP.

Each feed created in an organization is highly recommended to use the below settings. Below recommended settings are based on the need for development and cost estimate for ABB.

A regression bug is a bug that causes a completed feature that worked correctly to stop working after updates (e.g., system upgrade, system patching, or bug fixes). This definition applies both before and after releasing the feature to customers.

This guideline describes the custom standard fields used in bug templates. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the Document Update work item type and the custom standard fields used in its template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Epic template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Feature template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the fields used in the system epic template.

This guideline describes the custom standard fields used in the Test Case template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the User Story template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

Overview

This page contains support contacts for commonly used DevOps tools.
Although the Configuration Manager (CM) often plays a major role to integrate these tools in pipelines, the CM is not responsible to support in case of issues with the tool, like tool bugs, upgrades, service unavailability. In most cases, these tools are managed and supported by IS. IS will take care of tickets in ServiceNow and will open requests to the vendor if required.

The traceability of the work items shows the relationship between them in Azure DevOps (ADO).

This guide describes traceability between work products that are not in Azure DevOps (ADO).