Files
demo-epb/docs/plans-md/CM-Plan.md
T
Stefan Lohmaier ba7a3ebd27
Validate / build-test (macos-latest) (push) Failing after 3s
Validate / build-test (ubuntu-latest) (push) Successful in 16s
Validate / build-test (windows-latest) (push) Failing after 17s
Validate / reports (push) Successful in 53s
refactor(i18n): rename docs/plaene/ -> docs/plans/
Last German folder name in demo-epb. Pairs cleanly with docs/plans-md/
(markdown source) following the project convention. All references
in landing page generator, CI workflows, and cross-doc links updated.
2026-05-12 12:08:33 -07:00

147 lines
6.4 KiB
Markdown

---
doc-id: SLM-EPB-CM-001
version: 1.0
status: Released
date: 2026-05-12
---
# Configuration Management Plan (CM Plan)
| Field | Value |
|---------------|----------------------------------------|
| Project | demo-epb |
| Document ID | SLM-EPB-CM-001 |
| Version | 1.0 |
| Status | Released |
| Date | 2026-05-12 |
| Standard | ASPICE SUP.8 + ISO 26262-8 §7 |
---
## 1. Purpose
Describes how configuration items are identified, versioned, released, and controlled-change managed.
## 2. Configuration Items (CIs)
The following artefacts are under configuration control:
| Type | Path | Versioning |
|-------------------------|----------------------------------------|------------------------------|
| Source code | `src/**/*.{c,h}` | Git |
| Tests | `tests/**` | Git |
| Requirements | `reqs/{sys,swe}/*.md` | Git + Doorstop item hash |
| Architecture | `arch/{sys,swe}/*.md` | Git + Doorstop item hash |
| Safety Goals | `safety/sg/*.md` | Git |
| Plans (Word) | `docs/plans/*.docx` | Git + document version block |
| Safety docs (Word) | `docs/safety/*.docx` | Git |
| Manuals (Word) | `docs/manuals/*.docx` | Git |
| Reviews + NCs | `docs/reviews/`, `docs/non-conformities/` | Git |
| MISRA records | `misra/records/*.docx` | Git |
| CI configuration | `.gitea/workflows/*.yml` | Git |
| Build definition | `Makefile`, `Doxyfile` | Git |
| Tools | `tools/*.py` | Git |
## 3. Repository structure
- **Remote:** https://gitea.slohmaier.com/slohmaier/demo-epb
- **Branch `main`:** stable, always released state
- **Branch `develop`:** current development state
- **Feature branches:** `feature/SWE-XXX-...`
- **Bugfix branches:** `bugfix/<issue>-...`
- **Release branches:** `release/vX.Y` (real projects only; demo: from main directly)
## 4. Baselines
A baseline is a frozen, released state. Baselines are set via git tags.
| Baseline type | Tag scheme | When |
|---------------------------|-------------------|----------------------------------------|
| Requirements baseline | `req-vX.Y` | After requirements release |
| Architecture baseline | `arch-vX.Y` | After architecture review |
| Release baseline | `vX.Y.Z` | On productive release |
| Internal snapshot | `snap-YYYY-MM-DD` | On significant intermediate states |
Every tag (specifically `vX.Y.Z`) triggers the release workflow, which produces a bundle.
## 5. Versioning scheme
| Artefact | Scheme |
|-----------------------|------------------------------------------|
| Software release | Semantic Versioning `MAJOR.MINOR.PATCH` |
| Requirements | Doorstop level `X.Y` + date |
| Architecture | Doorstop level `X.Y` + date |
| Word documents | `MAJOR.MINOR` in document header |
## 6. Change control
Changes to configuration items occur via:
1. **Trivial change** (typos, comments): directly on the branch, PR with 1 approval
2. **Normal change** (feature, bug fix): feature branch, PR with reviews per ASIL
3. **Major change** (architecture, safety concept): change request + reviewer quorum
| ASIL | Minimum reviewer count |
|---------|---------------------------------------|
| QM | 1 |
| ASIL-A/B| 1 |
| ASIL-C | 2 (at least 1 technical reviewer) |
| ASIL-D | 2 technical reviewers + Safety Manager |
Reviews are documented in `docs/reviews/REV-XXX.docx`.
## 7. Release process
```
1. All PRs merged into main
2. Branch protected, all CI checks green
3. Release notes drafted in the PR
4. Set tag: git tag -a vX.Y.Z -m "..."
5. Push: git push origin vX.Y.Z
6. Release workflow runs (.gitea/workflows/release.yml):
- Build + tests + coverage
- Traceability + diagrams + API doc
- Bundle Word documents
- Pack source + artefact archives
- Create Gitea release
7. Review release manually (download bundle, inspect)
8. Mark release as "stable"
```
## 8. Retention
| Artefact | Retention |
|--------------------------|----------------------------------------|
| Git repository | Indefinite (Gitea + backup) |
| Release bundles | 10 years after product EOL |
| Reviews + NCs | 10 years after product EOL |
| MISRA records | 10 years after product EOL |
| CI artefacts (short-lived)| 90 days (in Gitea artifacts) |
ISO 26262 requires 10 years after end-of-production-life (assumption).
## 9. Verification
All pull requests pass through:
- Doorstop-equivalent traceability check (`tools/traceability.py check`)
- Build + unit tests
- Static analysis + MISRA check
- Coverage measurement
Only after approval and green CI may a merge into `main` occur.
## 10. Responsibilities
| Role | Task |
|------------------|---------------------------------------------------|
| Configuration Mgr| Maintain this CM Plan, repo hygiene, baselines |
| Developer | Correct branching, meaningful commit messages |
| Reviewer | Review before merge, audit trail |
| Project Owner | Release approval |
## 11. Revision history
| Version | Date | Change | Author |
|---------|-------------|---------------------|------------|
| 1.0 | 2026-05-12 | First release | S. Lohmaier|