|
| 1 | +.. |
| 2 | + # ******************************************************************************* |
| 3 | + # Copyright (c) 2025 Contributors to the Eclipse Foundation |
| 4 | + # |
| 5 | + # See the NOTICE file(s) distributed with this work for additional |
| 6 | + # information regarding copyright ownership. |
| 7 | + # |
| 8 | + # This program and the accompanying materials are made available under the |
| 9 | + # terms of the Apache License Version 2.0 which is available at |
| 10 | + # https://www.apache.org/licenses/LICENSE-2.0 |
| 11 | + # |
| 12 | + # SPDX-License-Identifier: Apache-2.0 |
| 13 | + # ******************************************************************************* |
| 14 | +
|
| 15 | +.. _configuration_templates: |
| 16 | + |
| 17 | +Template Configuration Management Plan |
| 18 | +====================================== |
| 19 | + |
| 20 | +.. gd_temp:: Configuration Management Plan Template |
| 21 | + :id: gd_temp__config_mgt_plan |
| 22 | + :status: valid |
| 23 | + :complies: std_req__iso26262__support_741, std_req__iso26262__support_742, std_req__iso26262__support_743, std_req__iso26262__support_744, std_req__iso26262__support_745, std_req__aspice_40__SUP-8-BP1, std_req__aspice_40__SUP-8-BP2, std_req__aspice_40__SUP-8-BP3, std_req__aspice_40__SUP-8-BP4, std_req__aspice_40__SUP-8-BP5, std_req__aspice_40__SUP-8-BP8 |
| 24 | + |
| 25 | +Purpose |
| 26 | ++++++++ |
| 27 | + |
| 28 | +The Configuration Management Plan defines how the integrity of all work products |
| 29 | +and other project relevant artefacts can be reached and maintained. |
| 30 | + |
| 31 | + |
| 32 | +Objectives and scope |
| 33 | +++++++++++++++++++++ |
| 34 | + |
| 35 | +Goal of this plan is to describe |
| 36 | + |
| 37 | +* how all configuration items in the project are identified |
| 38 | +* the infrastructure to store the configuration items |
| 39 | +* how to make all configuration items available to all concerned parties |
| 40 | +* where to find which configuration item |
| 41 | +* how to retrieve specific versions of a configuration item |
| 42 | +* how to modify a configuration item and how to control this |
| 43 | +* how to create and store versions of configuration items |
| 44 | +* how to manage baselines |
| 45 | +* how to backup and recover (including long term storage) |
| 46 | +* how to report the configuration status |
| 47 | + |
| 48 | +note: for definition of "configuration items" check :need:`doc_concept__configuration__process` |
| 49 | + |
| 50 | + |
| 51 | +Approach |
| 52 | +++++++++ |
| 53 | + |
| 54 | +.. gd_guidl:: Configuration Guideline |
| 55 | + :id: gd_guidl__configuration |
| 56 | + :status: valid |
| 57 | + :complies: std_req__iso26262__support_741, std_req__iso26262__support_742, std_req__iso26262__support_743, std_req__iso26262__support_744, std_req__iso26262__support_745, std_req__aspice_40__SUP-8-BP1, std_req__aspice_40__SUP-8-BP2, std_req__aspice_40__SUP-8-BP3, std_req__aspice_40__SUP-8-BP4, std_req__aspice_40__SUP-8-BP5, std_req__aspice_40__SUP-8-BP8 |
| 58 | + |
| 59 | + The steps below describe how configuration identification, retrieval, modification, branches and baselines, backup and recovery are organized. |
| 60 | + |
| 61 | +Lifecycle |
| 62 | +^^^^^^^^^ |
| 63 | + |
| 64 | +The configuration management of the S-CORE project is in place during the complete development lifecycle as described in :ref:`general_concepts_lifecycle`. |
| 65 | +I.e. in Concept Phase, Development Phase and Maintenance. |
| 66 | + |
| 67 | +Identification and Properties |
| 68 | +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 69 | + |
| 70 | +This should cover std_req__aspice_40__SUP-8-BP1 and std_req__aspice_40__SUP-8-BP2. |
| 71 | + |
| 72 | +Each work product is identified by its "structured text" Id, this includes documents identified as such (see project documents list in <link to doc__documentation_mgt_plan>). |
| 73 | +Ids are checked for uniqueness, see :need:`gd_req__configuration_uid`. |
| 74 | +"Structured text" is also used to document the work products properties/attributes defined in the process area descriptions. |
| 75 | +The work products are stored in text or code files (these are identified by their filenames) within the selected version management tool. |
| 76 | + |
| 77 | +For other artefacts these are either |
| 78 | + |
| 79 | +- files - are identified by their path/filename |
| 80 | +- precompiled tools/binaries - CI build configuration identifies those by their hash. |
| 81 | +- (external) tools/binaries to be built in S-CORE CI - CI build configuration identifies those by their version. |
| 82 | + |
| 83 | + |
| 84 | +Retrieval |
| 85 | +^^^^^^^^^ |
| 86 | + |
| 87 | +<Describe how work products and files can be retrieved from versioning tooling.> |
| 88 | +Their content is defined in the process/workproducts and process_area/<area_name>/workproducts files. |
| 89 | +To find the location of the work products, the project's folder structure definition <add link> can be used. |
| 90 | +<Describe how certain versions (also the ones for a certain baseline) of the work products and the change history can be displayed by the version management tool.> |
| 91 | + |
| 92 | +For other artefacts: these are pulled into S-CORE integration repository by forking to be handled as above. |
| 93 | + |
| 94 | + |
| 95 | +Control and Modification |
| 96 | +^^^^^^^^^^^^^^^^^^^^^^^^ |
| 97 | + |
| 98 | +This should cover std_req__aspice_40__SUP-8-BP3 and std_req__aspice_40__SUP-8-BP4 |
| 99 | + |
| 100 | +Files or new work products contained in these files are created in local branches by the :need:`Contributor <rl__contributor>` |
| 101 | +and shared for review and incorporation into a main branch, which are after their acceptance merged by the :need:`Committer <rl__committer>` |
| 102 | +(this should be supported by version management/review tooling). |
| 103 | +The same applies for changes in existing configuration items. |
| 104 | +All modifications (differences between before and after) are documented in the pull-requests and are the main input to the pull-request reviews. |
| 105 | +See also <link doc__platform_change_management_plan>. |
| 106 | + |
| 107 | +For other artefacts modifications are controlled by the CI build files which are also under configuration control. |
| 108 | + |
| 109 | + |
| 110 | +Branches and Baselines |
| 111 | +^^^^^^^^^^^^^^^^^^^^^^ |
| 112 | + |
| 113 | +This should cover std_req__aspice_40__SUP-8-BP5 |
| 114 | + |
| 115 | +Branches are used as a means of parallel development. In the S-CORE project the following types of branches will be used: |
| 116 | + |
| 117 | +* local branches - created from "remote" branches, in these the development of the contributors takes place, no restriction on naming. |
| 118 | +* main branch - a "remote" branch (named "main") which contains all the latest file versions checked by CI, reviewed, accepted and merged. |
| 119 | +* release branch - a "remote" branch derived from main branch which is used to prepare a release, |
| 120 | + no functional code changes are allowed, only bug fixes and verification based improvements. |
| 121 | + Only the technical lead is allowed to approve a merge into a release branch. The branch name is "release-<MAJOR_version>.<MINOR_version> |
| 122 | + |
| 123 | +The "remote" branch is not "local" to the developer but resides on the "remote" version management server. |
| 124 | + |
| 125 | +In S-CORE all configuration items are kept in the version management tool, this means that there only needs to be one baseline for these |
| 126 | +(and not multiple ones for each of the work products which are maintained in seperate tools). |
| 127 | +<Describe how baselines are created by using the version management tool.> |
| 128 | +See also <link to doc__platform_release_management_plan>. |
| 129 | + |
| 130 | +Every change in the release repository is also taken over into the main branch. The module development team |
| 131 | +can decide how to ensure this (e.g. by development in main and cherrypick to release branch). |
| 132 | + |
| 133 | + |
| 134 | +Backup and Recovery |
| 135 | +^^^^^^^^^^^^^^^^^^^ |
| 136 | + |
| 137 | +This should cover std_req__aspice_40__SUP-8-BP8. |
| 138 | + |
| 139 | +<Describe how backup and recovery are covered in the project.> |
| 140 | +For the long term storage, additional measures should be taken, see :need:`gd_req__workproducts_storage` |
| 141 | + |
| 142 | +Status and Reporting |
| 143 | +^^^^^^^^^^^^^^^^^^^^ |
| 144 | + |
| 145 | +This should cover std_req__aspice_40__SUP-8-BP6 and std_req__aspice_40__SUP-8-BP7. |
| 146 | + |
| 147 | +Every work product defined in our proceses has a "status" attribute. These are used to communicate to all the stakeholders. |
| 148 | +The main communication means is a document list containing all documents and workproducts including their status. |
| 149 | +This list is typically part of the Documentation Management Plan <link doc__documentation_mgt_plan> as part of the Platform Management Plan, |
| 150 | +as defined in :need:`gd_guidl__documentation`. |
| 151 | +Completeness of the configuration items (within a baseline) is checked at least for every release |
| 152 | +against the list of planned documents and workproducts, which is also part of the Documentation Management Plan. |
| 153 | + |
| 154 | +Configuration Management Tooling |
| 155 | +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 156 | + |
| 157 | +Almost all requirements of the standards towards configuration management can be covered by |
| 158 | +standard versioning tooling of the Eclipse Foundation and of the S-CORE project |
| 159 | +("structured text" identification of work products). |
| 160 | +The respective tools used in the project are: |
| 161 | + |
| 162 | +* versioning: <tool name> |
| 163 | +* structured text: <tool name> |
| 164 | +* CI build: <tool name> |
0 commit comments