feat(governance): refactored into sections, added more content to external stakeholder workshops
This commit is contained in:
parent
145705edf7
commit
cfbf23c8a5
5 changed files with 298 additions and 239 deletions
|
|
@ -19,242 +19,3 @@ Primary intended audience:
|
||||||
- Project leads of other IPCEI-CIS sub-projects
|
- Project leads of other IPCEI-CIS sub-projects
|
||||||
- IPCEI-CIS central architecture
|
- IPCEI-CIS central architecture
|
||||||
|
|
||||||
## Project History
|
|
||||||
|
|
||||||
### Mandate and product vision
|
|
||||||
|
|
||||||
Within the IPCEI-CIS work package for an Edge Developer Framework, the goal of the Developer Framework / EDP effort is to provide services that enable teams to develop, validate, roll out and operate applications efficiently across the edge cloud continuum.
|
|
||||||
|
|
||||||
The initial product framing emphasized:
|
|
||||||
|
|
||||||
- A coherent developer experience spanning development, testing, validation, rollout, monitoring and (eventually) billing.
|
|
||||||
- Reuse through templates and "golden paths".
|
|
||||||
- A portal-centric interaction model where developers consume platform capabilities via stable APIs and UI, not ad-hoc cluster access.
|
|
||||||
|
|
||||||
Primary source (internal only): [Confluence: Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework)
|
|
||||||
|
|
||||||
### Phases and milestones
|
|
||||||
|
|
||||||
The following phase model is based on the project artifacts currently present in Confluence and this repository. It is intentionally phrased as “what changed and why”, rather than as a release plan.
|
|
||||||
|
|
||||||
Terminology note: In this chapter, “Repository” refers to concrete Git repositories used as evidence sources. Unless stated otherwise:
|
|
||||||
|
|
||||||
- “Repository (this docs repo)” means this documentation repository (“website-and-documentation”), including `content/en/docs-old/`.
|
|
||||||
- “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc).
|
|
||||||
- “Confluence” refers to the IPCEI-CIS Confluence space on `confluence.telekom-mms.com` (internal only).
|
|
||||||
|
|
||||||
It does not refer to the wider set of platform/service code repositories unless explicitly stated.
|
|
||||||
|
|
||||||
#### Phase 1 — Discovery & system design (2024)
|
|
||||||
|
|
||||||
Focus:
|
|
||||||
|
|
||||||
- Establish a reference architecture for an Internal Developer Platform (IDP) style solution.
|
|
||||||
- Evaluate IDP foundations (explicitly referencing CNOE as a favored baseline), using a “planes” model as conceptual structure.
|
|
||||||
- Early emphasis on becoming self-hosting quickly (“eat your own dogfood”) and validating end-to-end paths.
|
|
||||||
|
|
||||||
Primary source (internal only): [Confluence: System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design)
|
|
||||||
|
|
||||||
#### Phase 2 — Proof of Concept (PoC) definition and scope (2024)
|
|
||||||
|
|
||||||
Focus:
|
|
||||||
|
|
||||||
- Align on a shared understanding of the product “Developer Platform” (technical and business framing) and what is feasible within 2024.
|
|
||||||
- Define PoC goals and acceptance criteria, including an end-to-end story centered on:
|
|
||||||
- an IDP builder/orchestrator running in the target environment (OSC),
|
|
||||||
- a developer portal (Backstage) for the user experience,
|
|
||||||
- a “golden path” flow from source → CI/CD → deployment.
|
|
||||||
|
|
||||||
Primary sources:
|
|
||||||
|
|
||||||
- Confluence (internal only): [Confluence: Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024)
|
|
||||||
- Repository (this repo): docs-old PoC structure summary: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/)
|
|
||||||
|
|
||||||
#### Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
|
|
||||||
|
|
||||||
Focus:
|
|
||||||
|
|
||||||
- Package outputs produced since mid-2024 into a demonstrable PoC product.
|
|
||||||
- Make “traces” explicit from backlog items to concrete outputs (repos, docs, capabilities), to support governance and auditability.
|
|
||||||
- Establish working agreements for branching, PR-based review, and Definition of Done.
|
|
||||||
|
|
||||||
Primary source: repository document [Team and Work Structure](../../docs-old/v1/project/team-process/) (docs-old, in this repo).
|
|
||||||
|
|
||||||
#### Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
|
|
||||||
|
|
||||||
Focus:
|
|
||||||
|
|
||||||
- Expand from “PoC capabilities” toward a service milestone around Forgejo, including supporting services (persistence, backups, caching, indexing, SSO, runners, observability).
|
|
||||||
- Provision Foundry/EDP resources via Infrastructure-as-Code, initially in OTC.
|
|
||||||
- Address reliability and migration risks while moving from earlier instances to production endpoints.
|
|
||||||
|
|
||||||
Evidence:
|
|
||||||
|
|
||||||
- Confluence (internal only): [Confluence: Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) (service decomposition and operational concerns)
|
|
||||||
- ADR: “Add Scaleway as Cloud resource Provider” explicitly places Foundry/EDP IaC provisioning in mid-April 2025 and captures platform issues and mitigation.
|
|
||||||
- Postmortem (2025-07-14) documents downtime rooted in an incomplete Foundry migration and the need for explicit migration plans.
|
|
||||||
|
|
||||||
#### Phase 5 — EdgeConnect integration: deployment target + SDK/tooling (ongoing)
|
|
||||||
|
|
||||||
Focus:
|
|
||||||
|
|
||||||
- Treat EdgeConnect as a sovereign deployment target operated outside EDP, and provide consumable tooling to integrate it into delivery workflows.
|
|
||||||
- Provide reusable automation components (SDK, CLI client, Terraform provider, Forgejo Actions) so that EdgeConnect is used consistently through stable entry points.
|
|
||||||
- Use EdgeConnect for deploying project artifacts (including this documentation website) to edge cloudlets.
|
|
||||||
|
|
||||||
Evidence:
|
|
||||||
|
|
||||||
- Repository (this repo): EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
|
|
||||||
- Repository (this repo): docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
|
|
||||||
|
|
||||||
### Development and delivery process evolution
|
|
||||||
|
|
||||||
Across the phases above, delivery methods and team process evolved in response to scaling and operational needs:
|
|
||||||
|
|
||||||
- Scrum ceremonies and working agreements are documented in Confluence (internal only): [Confluence: How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM).
|
|
||||||
- Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.
|
|
||||||
|
|
||||||
### Deliverables mapping
|
|
||||||
|
|
||||||
This section captures the traceability model and evidence-backed anchors that connect capabilities/phases to concrete outputs (repositories, documentation pages, deployed services). It does not yet claim a complete IPCEI deliverable-ID → epic → artifact mapping.
|
|
||||||
|
|
||||||
#### Traceability model (used for audit)
|
|
||||||
|
|
||||||
The working model (used throughout the PoC) is:
|
|
||||||
|
|
||||||
- Deliverable / capability definition (often in Confluence) →
|
|
||||||
- Ticket(s) in Jira / Forgejo →
|
|
||||||
- Implementation via commits + pull requests →
|
|
||||||
- Concrete output (repo, docs page, automation component, deployed service) →
|
|
||||||
- Evidence (ADR / postmortem / runbook / deployment config) showing real operation.
|
|
||||||
|
|
||||||
Primary sources for the traceability intent:
|
|
||||||
|
|
||||||
- Repository (edp-doc): PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
|
|
||||||
- Repository (edp-doc): team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
|
|
||||||
|
|
||||||
#### Matrix (evidence-backed overview)
|
|
||||||
|
|
||||||
This matrix is intended to be directly consumable: it summarizes what can already be evidenced from the current sources. It is an overview across phases/capabilities; it is not the full IPCEI deliverable-ID mapping.
|
|
||||||
|
|
||||||
| Phase | What is delivered / proven | Concrete outputs (where) | Evidence / trace hooks |
|
|
||||||
| --- | --- | --- | --- |
|
|
||||||
| Phase 1 — Discovery & system design | Reference architecture framing and decision drivers | Confluence (internal only): [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) (planes model, CNOE baseline preference, dogfooding) | Architecture notes are the earliest “why” evidence for later component choices |
|
|
||||||
| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository (this docs repo): PoC structure page (docs-old) and Repository (edp-doc): PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
|
|
||||||
| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository (this repo): PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
|
|
||||||
| Phase 4 — Forgejo-as-a-Service + Foundry provisioning | A service milestone with operational concerns (persistence, backups, SSO, runners) and IaC provisioning | ADR (Scaleway as additional install channel) + postmortem (Foundry migration downtime) | Concrete operational evidence that architecture and migration risks were handled as governance work |
|
|
||||||
| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository (this repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
|
|
||||||
|
|
||||||
#### Ticket anchors (PoC)
|
|
||||||
|
|
||||||
The PoC design README explicitly provides Jira anchors that can be used to build a full traceability matrix:
|
|
||||||
|
|
||||||
- Part 1 (User documentation): [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368)
|
|
||||||
- Part 2.1 (Local IdP creation): [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765)
|
|
||||||
- Part 2.2 (OSC IdP creation): [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766)
|
|
||||||
- Part 2.x.1 (Golden Path template): [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514)
|
|
||||||
- Part 2.x.2 (Fibonacci example app): [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759)
|
|
||||||
- Part 2.x.3 (Forgejo Actions CI/CD): [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760)
|
|
||||||
- Part 2.x.4 (Telemetry): [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761)
|
|
||||||
- Part 2.x.5 (OSC infrastructure): [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762)
|
|
||||||
- Part 2.x.6 (Additional items): [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763)
|
|
||||||
- Part 2.3 (Extended local orchestration): [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767)
|
|
||||||
- Part 3 (User documentation): [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768)
|
|
||||||
|
|
||||||
## Compliance & Audit
|
|
||||||
|
|
||||||
### Technology Choices
|
|
||||||
|
|
||||||
Documentation of technology evaluation and selection process for key components (e.g., VictoriaMetrics, GARM, Terraform, ArgoCD).
|
|
||||||
|
|
||||||
#### Forgejo
|
|
||||||
|
|
||||||
The internal service is officially designated as the [Edge Developer Platform (EDP)](../components/forgejo/_index.md). It is hosted at **[edp.buildth.ing](https://edp.buildth.ing)**. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
|
|
||||||
|
|
||||||
**Solution selection:**
|
|
||||||
|
|
||||||
The decision to utilize **[Forgejo](https://forgejo.org/)** as the core self-hosted Git service was driven by specific strategic requirements:
|
|
||||||
|
|
||||||
- **EU-Based Stewardship:** Forgejo is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
|
|
||||||
- **License Protection (GPL v3+):** Unlike "Open Core" models, Forgejo uses a copyleft license. This legally protects our custom extensions (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
|
|
||||||
- **Open Source Strategy:** The platform aligns with the "Public Money, Public Code" philosophy, mandating that funded developments are returned to the community.
|
|
||||||
|
|
||||||
**Access Model:**
|
|
||||||
|
|
||||||
The platform operates on a hybrid visibility model:
|
|
||||||
|
|
||||||
- **Public Access:** The [`DEVFW-CICD`](https://edp.buildth.ing/DevFW-CICD) organization is publicly accessible, fostering transparency.
|
|
||||||
- **Private Access:** Sensitive development occurs in restricted organizations (e.g., [`DEVFW`](https://edp.buildth.ing/DevFW)).
|
|
||||||
- **User Base:** Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
|
|
||||||
|
|
||||||
### Security Controls
|
|
||||||
|
|
||||||
Overview of implemented security controls and compliance measures.
|
|
||||||
|
|
||||||
### Ticket References
|
|
||||||
|
|
||||||
Cross-references to Jira tickets, epics, and project tracking for audit trails.
|
|
||||||
|
|
||||||
Current, evidence-backed anchors:
|
|
||||||
|
|
||||||
- PoC “parts” and hands-on scope are anchored in Jira and listed explicitly in the PoC design README (see Ticket anchors above).
|
|
||||||
- PoC consolidation and governance intent (“traces from tickets to outputs”) is described in the team-process documentation.
|
|
||||||
- The Forgejo ProjectMgmt prototype documents how tickets, milestones, and boards were structured in Forgejo to run demo slices and work packages.
|
|
||||||
|
|
||||||
## Community & External Relations
|
|
||||||
|
|
||||||
### Open Source Contributions
|
|
||||||
|
|
||||||
Contributions to the Forgejo community and other open-source projects.
|
|
||||||
|
|
||||||
#### Forgejo
|
|
||||||
|
|
||||||
We actively contributed our extensions back to the upstream Forgejo project on **[Codeberg.org](https://codeberg.org/)**.
|
|
||||||
|
|
||||||
**Key Pull Requests:**
|
|
||||||
|
|
||||||
- **API Compatibility:** Added GitHub-compatible endpoints for runner registration.
|
|
||||||
- [PR #9409: Feat: Add endpoints for GARM](https://codeberg.org/forgejo/forgejo/pulls/9409)
|
|
||||||
- **Webhook Support:** Implemented webhook triggers for workflow events.
|
|
||||||
- [PR #9803: Feat: Add webhook support for workflow events](https://codeberg.org/forgejo/forgejo/pulls/9803)
|
|
||||||
- **Ephemeral Runners:** Added support for runners that terminate after a single job.
|
|
||||||
- [PR #9962: Feat: Support for ephemeral runners](https://codeberg.org/forgejo/forgejo/pulls/9962)
|
|
||||||
|
|
||||||
### External Stakeholders
|
|
||||||
|
|
||||||
User experience research and feedback integration.
|
|
||||||
|
|
||||||
## References
|
|
||||||
|
|
||||||
This list is an index of all links referenced on this page, plus the intended meaning (“semantics”) of each link.
|
|
||||||
|
|
||||||
- (internal only) Confluence: [Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework) — mandate, quick links, and high-level framing.
|
|
||||||
- (internal only) Confluence: [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) — architecture framing (planes model, baseline preferences, early decision drivers).
|
|
||||||
- (internal only) Confluence: [Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024) — PoC scope, goals, and evaluation/acceptance framing.
|
|
||||||
- (internal only) Confluence: [Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) — service decomposition and operational concerns used as evidence for Phase 4.
|
|
||||||
- (internal only) Confluence: [How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM) — delivery process reference.
|
|
||||||
- (internal only) Jira: [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368) — PoC part 1 traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765) — PoC part 2.1 traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766) — PoC part 2.2 traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514) — PoC golden path template traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759) — PoC example app traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760) — PoC CI/CD traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761) — PoC telemetry traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762) — PoC infrastructure traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763) — PoC additional items traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767) — PoC orchestration extension traceability anchor.
|
|
||||||
- (internal only) Jira: [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768) — PoC part 3 (user documentation) traceability anchor.
|
|
||||||
- Documentation site: [PoC Structure](../../docs-old/v1/project/plan-in-2024/poc/) — published docs-old summary of the PoC structure.
|
|
||||||
- Documentation site: [Team and Work Structure](../../docs-old/v1/project/team-process/) — published docs-old description of process and traceability intent.
|
|
||||||
- Documentation site: [Forgejo component page](../components/forgejo/_index.md) — internal documentation entry point for the Forgejo/EDP component.
|
|
||||||
- Service entry point: [edp.buildth.ing](https://edp.buildth.ing) — EDP Forgejo instance.
|
|
||||||
- Service org: [edp.buildth.ing/DevFW-CICD](https://edp.buildth.ing/DevFW-CICD) — public organization referenced for transparency.
|
|
||||||
- Service org: [edp.buildth.ing/DevFW](https://edp.buildth.ing/DevFW) — private organization reference.
|
|
||||||
- (internal only) Repository (edp-doc): [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc) — EDP technical documentation repository (ADRs, postmortems, PoC process), used as evidence sources in this chapter.
|
|
||||||
- Upstream project: [forgejo.org](https://forgejo.org/) — Forgejo project homepage.
|
|
||||||
- Upstream governance: [Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/) — referenced as steward/governance body.
|
|
||||||
- Upstream contribution: [PR #9409](https://codeberg.org/forgejo/forgejo/pulls/9409) — GARM endpoints contribution.
|
|
||||||
- Upstream contribution: [PR #9803](https://codeberg.org/forgejo/forgejo/pulls/9803) — webhook workflow events contribution.
|
|
||||||
- Upstream contribution: [PR #9962](https://codeberg.org/forgejo/forgejo/pulls/9962) — ephemeral runners contribution.
|
|
||||||
- Upstream hosting: [Codeberg.org](https://codeberg.org/) — hosting platform used for upstream Forgejo contributions.
|
|
||||||
|
|
||||||
|
|
|
||||||
88
content/en/docs/governance/compliance-audit/_index.md
Normal file
88
content/en/docs/governance/compliance-audit/_index.md
Normal file
|
|
@ -0,0 +1,88 @@
|
||||||
|
---
|
||||||
|
title: "Compliance & audit"
|
||||||
|
linkTitle: "Compliance"
|
||||||
|
weight: 30
|
||||||
|
description: >
|
||||||
|
Technology choices, auditability, and external relations.
|
||||||
|
---
|
||||||
|
|
||||||
|
## Technology Choices
|
||||||
|
|
||||||
|
Documentation of technology evaluation and selection process for key components (e.g., VictoriaMetrics, GARM, Terraform, ArgoCD).
|
||||||
|
|
||||||
|
### Forgejo
|
||||||
|
|
||||||
|
The internal service is officially designated as the [Edge Developer Platform (EDP)](/docs/edp/forgejo/). It is hosted at **[edp.buildth.ing](https://edp.buildth.ing)**. The domain selection followed a democratic team process to establish a unique identity distinct from standard corporate naming conventions.
|
||||||
|
|
||||||
|
**Solution selection:**
|
||||||
|
|
||||||
|
The decision to utilize **[Forgejo](https://forgejo.org/)** as the core self-hosted Git service was driven by specific strategic requirements:
|
||||||
|
|
||||||
|
- **EU-Based Stewardship:** Forgejo is stewarded by **[Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/)**, a non-profit organization based in Berlin, Germany. This alignment ensures compliance with GDPR and data sovereignty requirements, placing governance under EU jurisdiction rather than US tech entities.
|
||||||
|
- **License Protection (GPL v3+):** Unlike "Open Core" models, Forgejo uses a copyleft license. This legally protects our custom extensions (such as GARM support) from being appropriated into proprietary software, ensuring the ecosystem remains open.
|
||||||
|
- **Open Source Strategy:** The platform aligns with the "Public Money, Public Code" philosophy, mandating that funded developments are returned to the community.
|
||||||
|
|
||||||
|
**Access Model:**
|
||||||
|
|
||||||
|
The platform operates on a hybrid visibility model:
|
||||||
|
|
||||||
|
- **Public Access:** The [`DEVFW-CICD`](https://edp.buildth.ing/DevFW-CICD) organization is publicly accessible, fostering transparency.
|
||||||
|
- **Private Access:** Sensitive development occurs in restricted organizations (e.g., [`DEVFW`](https://edp.buildth.ing/DevFW)).
|
||||||
|
- **User Base:** Primary users include the internal development team, with friendly user access granted to the IPCEI team and MMS BT.
|
||||||
|
|
||||||
|
## Ticket References
|
||||||
|
|
||||||
|
Cross-references to Jira tickets, epics, and project tracking for audit trails.
|
||||||
|
|
||||||
|
Current, evidence-backed anchors:
|
||||||
|
|
||||||
|
- PoC “parts” and hands-on scope are anchored in Jira and listed explicitly in the PoC design README (see Traceability / Ticket anchors).
|
||||||
|
- PoC consolidation and governance intent (“traces from tickets to outputs”) is described in the team-process documentation.
|
||||||
|
- The Forgejo ProjectMgmt prototype documents how tickets, milestones, and boards were structured in Forgejo to run demo slices and work packages.
|
||||||
|
|
||||||
|
## Open Source Contributions
|
||||||
|
|
||||||
|
Contributions to the Forgejo community and other open-source projects.
|
||||||
|
|
||||||
|
### Forgejo
|
||||||
|
|
||||||
|
We actively contributed our extensions back to the upstream Forgejo project on **[Codeberg.org](https://codeberg.org/)**.
|
||||||
|
|
||||||
|
**Key Pull Requests:**
|
||||||
|
|
||||||
|
- **API Compatibility:** Added GitHub-compatible endpoints for runner registration.
|
||||||
|
- [PR #9409: Feat: Add endpoints for GARM](https://codeberg.org/forgejo/forgejo/pulls/9409)
|
||||||
|
- **Webhook Support:** Implemented webhook triggers for workflow events.
|
||||||
|
- [PR #9803: Feat: Add webhook support for workflow events](https://codeberg.org/forgejo/forgejo/pulls/9803)
|
||||||
|
- **Ephemeral Runners:** Added support for runners that terminate after a single job.
|
||||||
|
- [PR #9962: Feat: Support for ephemeral runners](https://codeberg.org/forgejo/forgejo/pulls/9962)
|
||||||
|
|
||||||
|
## External Stakeholders
|
||||||
|
|
||||||
|
From the beginning, the project used structured stakeholder formats to collect requirements, validate assumptions, and strengthen a product-development mindset beyond “pure delivery”.
|
||||||
|
|
||||||
|
Evidence (internal only):
|
||||||
|
|
||||||
|
- Stakeholder workshop planning and target groups are captured in Confluence: [eDF Stakeholder Workshops](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902567168/eDF+Stakeholder+Workshops) (internal/external workshops, goals, and intended outcomes).
|
||||||
|
- A concrete external workshop session is documented in Confluence: [external stakeholder workshop](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/936478033/external+stakeholder+workshop) (incl. agenda attachment). Note: the page explicitly contains AI-generated content and should be verified.
|
||||||
|
- An internal workshop session with detailed agenda and feedback is documented in Confluence: [internal stakeholder workshop 7.11.](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/915155061/internal+stakeholder+workshop+7.11.) (also includes AI-generated summary blocks).
|
||||||
|
|
||||||
|
### What we learned / decided (PII-free synthesis)
|
||||||
|
|
||||||
|
The workshop and research artifacts consistently point to a few pragmatic decisions and product learnings (summarized here without personal data[^pii-free]):
|
||||||
|
|
||||||
|
- **Onboarding is a primary adoption gate:** prioritize low cognitive load, clear guidance, and a “cold start” path that works without prior context (captured in the Customer Engagement plan and related onboarding-focused activities).
|
||||||
|
- **Treat navigation and information architecture as product work:** “too many clicks”, missing global orientation cues, and inconsistent navigation were recurring friction points; prioritization leaned towards making “projects / work” more discoverable and first-class (see UX insights log for navigation/IA patterns).
|
||||||
|
- **Forgejo PM & Docs need either redesign or deliberate scope boundaries:** modern PM/docs workflows and stakeholder reporting expectations were a known gap; this informed decisions about prototyping and scoping improvements vs. relying on integrations.
|
||||||
|
- **Expect a tension between autonomy and guardrails:** research highlights that developer autonomy is valued while guardrails increase trust and repeatability; positioning matters because “platform” concepts can be perceived as top-down control if not framed carefully.
|
||||||
|
- **Institutionalize UX feedback loops:** beyond ad-hoc workshops, the work moved towards a repeatable research cadence (panel/community, surveys, and insight logging) to reduce “one-off feedback” risk.
|
||||||
|
- **Automated UX testing was formalized as a concrete use case:** a dedicated “use case identification” artifact structures automated UX testing around functional correctness, visual consistency/accessibility, and task-based end-to-end “happy path” flow checks (used as input for the later UX work package stream).
|
||||||
|
|
||||||
|
[^pii-free]: PII = “personally identifiable information”. “PII-free synthesis” means we summarize patterns, decisions, and learnings without including names, participant lists, direct quotes, or other details that could identify individuals.
|
||||||
|
|
||||||
|
Later, a dedicated “user experience” focus was strengthened and formalized via a dedicated work package / deliverable stream that explicitly frames UX validation as an activity with objectives, KPIs, and user validation:
|
||||||
|
|
||||||
|
- Work package definition and objectives: [Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704046/Workpackage+e.3+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
|
||||||
|
- Deliverable (incl. PoC results summary around autonomous UI/UX testing and “happy path” user flows): [Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704082/Deliverable+D66+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers)
|
||||||
|
|
||||||
|
See also: the central [References](/docs/governance/references/) index.
|
||||||
102
content/en/docs/governance/project-history/_index.md
Normal file
102
content/en/docs/governance/project-history/_index.md
Normal file
|
|
@ -0,0 +1,102 @@
|
||||||
|
---
|
||||||
|
title: "Project history"
|
||||||
|
linkTitle: "History"
|
||||||
|
weight: 10
|
||||||
|
description: >
|
||||||
|
Mandate, phases, milestones, and process evolution.
|
||||||
|
---
|
||||||
|
|
||||||
|
## Mandate and product vision
|
||||||
|
|
||||||
|
Within the IPCEI-CIS work package for an Edge Developer Framework, the goal of the Developer Framework / EDP effort is to provide services that enable teams to develop, validate, roll out and operate applications efficiently across the edge cloud continuum.
|
||||||
|
|
||||||
|
The initial product framing emphasized:
|
||||||
|
|
||||||
|
- A coherent developer experience spanning development, testing, validation, rollout, monitoring and (eventually) billing.
|
||||||
|
- Reuse through templates and "golden paths".
|
||||||
|
- A portal-centric interaction model where developers consume platform capabilities via stable APIs and UI, not ad-hoc cluster access.
|
||||||
|
|
||||||
|
Primary source (internal only): [Confluence: Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework)
|
||||||
|
|
||||||
|
## Phases and milestones
|
||||||
|
|
||||||
|
The following phase model is based on the project artifacts currently present in Confluence and this repository. It is intentionally phrased as “what changed and why”, rather than as a release plan.
|
||||||
|
|
||||||
|
Terminology note: In this chapter, “Repository” refers to concrete Git repositories used as evidence sources. Unless stated otherwise:
|
||||||
|
|
||||||
|
- “Repository (this docs repo)” means this documentation repository (“website-and-documentation”), including `/docs-old/`.
|
||||||
|
- “Repository (edp-doc)” means the EDP technical documentation repository at (internal only) [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc).
|
||||||
|
- “Confluence” refers to the IPCEI-CIS Confluence space on `confluence.telekom-mms.com` (internal only).
|
||||||
|
|
||||||
|
It does not refer to the wider set of platform/service code repositories unless explicitly stated.
|
||||||
|
|
||||||
|
### Phase 1 — Discovery & system design (2024)
|
||||||
|
|
||||||
|
Focus:
|
||||||
|
|
||||||
|
- Establish a reference architecture for an Internal Developer Platform (IDP) style solution.
|
||||||
|
- Evaluate IDP foundations (explicitly referencing CNOE as a favored baseline), using a “planes” model as conceptual structure.
|
||||||
|
- Early emphasis on becoming self-hosting quickly (“eat your own dogfood”) and validating end-to-end paths.
|
||||||
|
|
||||||
|
Primary source (internal only): [Confluence: System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design)
|
||||||
|
|
||||||
|
### Phase 2 — Proof of Concept (PoC) definition and scope (2024)
|
||||||
|
|
||||||
|
Focus:
|
||||||
|
|
||||||
|
- Align on a shared understanding of the product “Developer Platform” (technical and business framing) and what is feasible within 2024.
|
||||||
|
- Define PoC goals and acceptance criteria, including an end-to-end story centered on:
|
||||||
|
- an IDP builder/orchestrator running in the target environment (OSC),
|
||||||
|
- a developer portal (Backstage) for the user experience,
|
||||||
|
- a “golden path” flow from source → CI/CD → deployment.
|
||||||
|
|
||||||
|
Primary sources:
|
||||||
|
|
||||||
|
- Confluence (internal only): [Confluence: Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024)
|
||||||
|
- Repository (this repo): docs-old PoC structure summary: [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/)
|
||||||
|
|
||||||
|
### Phase 3 — PoC consolidation: deliverables, repository structure, traceability (late 2024)
|
||||||
|
|
||||||
|
Focus:
|
||||||
|
|
||||||
|
- Package outputs produced since mid-2024 into a demonstrable PoC product.
|
||||||
|
- Make “traces” explicit from backlog items to concrete outputs (repos, docs, capabilities), to support governance and auditability.
|
||||||
|
- Establish working agreements for branching, PR-based review, and Definition of Done.
|
||||||
|
|
||||||
|
Primary source: repository document [Team and Work Structure](/docs-old/v1/project/team-process/) (docs-old, in this repo).
|
||||||
|
|
||||||
|
### Phase 4 — “Forgejo as a Service” and Foundry-based provisioning (2025)
|
||||||
|
|
||||||
|
Focus:
|
||||||
|
|
||||||
|
- Expand from “PoC capabilities” toward a service milestone around Forgejo, including supporting services (persistence, backups, caching, indexing, SSO, runners, observability).
|
||||||
|
- Provision Foundry/EDP resources via Infrastructure-as-Code, initially in OTC.
|
||||||
|
- Address reliability and migration risks while moving from earlier instances to production endpoints.
|
||||||
|
|
||||||
|
Evidence:
|
||||||
|
|
||||||
|
- Confluence (internal only): [Confluence: Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) (service decomposition and operational concerns)
|
||||||
|
- ADR: “Add Scaleway as Cloud resource Provider” explicitly places Foundry/EDP IaC provisioning in mid-April 2025 and captures platform issues and mitigation.
|
||||||
|
- Postmortem (2025-07-14) documents downtime rooted in an incomplete Foundry migration and the need for explicit migration plans.
|
||||||
|
|
||||||
|
### Phase 5 — EdgeConnect integration: deployment target + SDK/tooling (ongoing)
|
||||||
|
|
||||||
|
Focus:
|
||||||
|
|
||||||
|
- Treat EdgeConnect as a sovereign deployment target operated outside EDP, and provide consumable tooling to integrate it into delivery workflows.
|
||||||
|
- Provide reusable automation components (SDK, CLI client, Terraform provider, Forgejo Actions) so that EdgeConnect is used consistently through stable entry points.
|
||||||
|
- Use EdgeConnect for deploying project artifacts (including this documentation website) to edge cloudlets.
|
||||||
|
|
||||||
|
Evidence:
|
||||||
|
|
||||||
|
- Repository (this repo): EdgeConnect documentation under `/docs/edgeconnect/` (SDK/client/actions).
|
||||||
|
- Repository (this repo): docs-old “Publishing to Edge” describes the documentation deployment via `edgeconnectdeployment.yaml`.
|
||||||
|
|
||||||
|
## Development and delivery process evolution
|
||||||
|
|
||||||
|
Across the phases above, delivery methods and team process evolved in response to scaling and operational needs:
|
||||||
|
|
||||||
|
- Scrum ceremonies and working agreements are documented in Confluence (internal only): [Confluence: How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM).
|
||||||
|
- Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.
|
||||||
|
|
||||||
|
See also: the central [References](/docs/governance/references/) index.
|
||||||
47
content/en/docs/governance/references/_index.md
Normal file
47
content/en/docs/governance/references/_index.md
Normal file
|
|
@ -0,0 +1,47 @@
|
||||||
|
---
|
||||||
|
title: "References"
|
||||||
|
linkTitle: "References"
|
||||||
|
weight: 40
|
||||||
|
description: >
|
||||||
|
Index of primary sources and evidence links used across the Governance chapter.
|
||||||
|
---
|
||||||
|
|
||||||
|
This list is an index of links referenced across the Governance chapter, plus the intended meaning (“semantics”) of each link.
|
||||||
|
|
||||||
|
- (internal only) Confluence: [Sub Project Developer Framework](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788263/Sub+Project+Developer+Framework) — mandate, quick links, and high-level framing.
|
||||||
|
- (internal only) Confluence: [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) — architecture framing (planes model, baseline preferences, early decision drivers).
|
||||||
|
- (internal only) Confluence: [Proof of Concept 2024](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902010138/Proof+of+Concept+2024) — PoC scope, goals, and evaluation/acceptance framing.
|
||||||
|
- (internal only) Confluence: [Forgejo as a service](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/999903971/Forgejo+as+a+service) — service decomposition and operational concerns used as evidence for Phase 4.
|
||||||
|
- (internal only) Confluence: [How we SCRUM](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/977833214/How+we+SCRUM) — delivery process reference.
|
||||||
|
- (internal only) Confluence: [eDF Stakeholder Workshops](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/902567168/eDF+Stakeholder+Workshops) — plan for internal/external stakeholder workshops, target groups, and intended outcomes.
|
||||||
|
- (internal only) Confluence: [internal stakeholder workshop 7.11.](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/915155061/internal+stakeholder+workshop+7.11.) — internal stakeholder session agenda and captured feedback (contains AI-generated summary blocks).
|
||||||
|
- (internal only) Confluence: [external stakeholder workshop](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/936478033/external+stakeholder+workshop) — external stakeholder session notes (contains agenda attachment and AI-generated summary blocks).
|
||||||
|
- (internal only) Confluence: [Workpackage e.3 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704046/Workpackage+e.3+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers) — UX-focused workpackage with objectives, KPIs, and “validation with users” framing.
|
||||||
|
- (internal only) Confluence: [Deliverable D66 - Sustainable-edge-management-optimized user interface for edge developers](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1165704082/Deliverable+D66+-+Sustainable-edge-management-optimized+user+interface+for+edge+developers) — deliverable page including PoC results summary for autonomous UI/UX testing.
|
||||||
|
- (internal only) Confluence: [Customer Engagement](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1040844220/Customer+Engagement) — research planning cadence (who/why/when), plus synthesized insights/assumptions used to justify PII-free “what we learned” summaries.
|
||||||
|
- (internal only) Confluence: [UX Insights and Learnings](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1033832272/UX+Insights+and+Learnings) — running log of UX observations and recommended improvements (useful for evidence-backed, non-PII synthesis of recurring friction patterns).
|
||||||
|
- (internal only) Confluence: [[IPCEICIS-3703] Use Case identification for automated UX testing](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/1055949846/IPCEICIS-3703+Use+Case+identification+for+automated+UX+testing) — structured prioritization of automated UX testing scenarios (happy-path smoke flows, functional correctness, visual/accessibility checks). Note: treat as internal working material; do not replicate embedded credentials/content.
|
||||||
|
- (internal only) Jira: [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368) — PoC part 1 traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765) — PoC part 2.1 traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766) — PoC part 2.2 traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514) — PoC golden path template traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759) — PoC example app traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760) — PoC CI/CD traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761) — PoC telemetry traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762) — PoC infrastructure traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763) — PoC additional items traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767) — PoC orchestration extension traceability anchor.
|
||||||
|
- (internal only) Jira: [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768) — PoC part 3 (user documentation) traceability anchor.
|
||||||
|
- Documentation site: [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/) — published docs-old summary of the PoC structure.
|
||||||
|
- Documentation site: [Team and Work Structure](/docs-old/v1/project/team-process/) — published docs-old description of process and traceability intent.
|
||||||
|
- Documentation site: [Forgejo docs entry](/docs/edp/forgejo/) — documentation entry point for the Forgejo/EDP component.
|
||||||
|
- Service entry point: [edp.buildth.ing](https://edp.buildth.ing) — EDP Forgejo instance.
|
||||||
|
- Service org: [edp.buildth.ing/DevFW-CICD](https://edp.buildth.ing/DevFW-CICD) — public organization referenced for transparency.
|
||||||
|
- Service org: [edp.buildth.ing/DevFW](https://edp.buildth.ing/DevFW) — private organization reference.
|
||||||
|
- (internal only) Repository (edp-doc): [edp.buildth.ing/DevFW/edp-doc](https://edp.buildth.ing/DevFW/edp-doc) — EDP technical documentation repository (ADRs, postmortems, PoC process), used as evidence sources in this chapter.
|
||||||
|
- Upstream project: [forgejo.org](https://forgejo.org/) — Forgejo project homepage.
|
||||||
|
- Upstream governance: [Codeberg e.V.](https://docs.codeberg.org/getting-started/what-is-codeberg/) — referenced as steward/governance body.
|
||||||
|
- Upstream contribution: [PR #9409](https://codeberg.org/forgejo/forgejo/pulls/9409) — GARM endpoints contribution.
|
||||||
|
- Upstream contribution: [PR #9803](https://codeberg.org/forgejo/forgejo/pulls/9803) — webhook workflow events contribution.
|
||||||
|
- Upstream contribution: [PR #9962](https://codeberg.org/forgejo/forgejo/pulls/9962) — ephemeral runners contribution.
|
||||||
|
- Upstream hosting: [Codeberg.org](https://codeberg.org/) — hosting platform used for upstream Forgejo contributions.
|
||||||
61
content/en/docs/governance/traceability/_index.md
Normal file
61
content/en/docs/governance/traceability/_index.md
Normal file
|
|
@ -0,0 +1,61 @@
|
||||||
|
---
|
||||||
|
title: "Traceability"
|
||||||
|
linkTitle: "Traceability"
|
||||||
|
weight: 20
|
||||||
|
description: >
|
||||||
|
Deliverables mapping, evidence model, matrix overview, and ticket anchors.
|
||||||
|
---
|
||||||
|
|
||||||
|
## Deliverables mapping
|
||||||
|
|
||||||
|
This section captures the traceability model and evidence-backed anchors that connect capabilities/phases to concrete outputs (repositories, documentation pages, deployed services). It does not yet claim a complete IPCEI deliverable-ID → epic → artifact mapping.
|
||||||
|
|
||||||
|
## Traceability model (used for audit)
|
||||||
|
|
||||||
|
The working model (used throughout the PoC) is:
|
||||||
|
|
||||||
|
- Deliverable / capability definition (often in Confluence) →
|
||||||
|
- Ticket(s) in Jira / Forgejo →
|
||||||
|
- Implementation via commits + pull requests →
|
||||||
|
- Concrete output (repo, docs page, automation component, deployed service) →
|
||||||
|
- Evidence (ADR / postmortem / runbook / deployment config) showing real operation.
|
||||||
|
|
||||||
|
Primary sources for the traceability intent:
|
||||||
|
|
||||||
|
- Repository (edp-doc): PoC design README lists Jira parts and calls for a mapping table from “parts” to upstream references.
|
||||||
|
- Repository (edp-doc): team-process documents emphasize “traces from tickets to outputs” and an outcome summary in the ticket as part of Definition of Done.
|
||||||
|
|
||||||
|
## Matrix (evidence-backed overview)
|
||||||
|
|
||||||
|
This matrix is intended to be directly consumable: it summarizes what can already be evidenced from the current sources. It is an overview across phases/capabilities; it is not the full IPCEI deliverable-ID mapping.
|
||||||
|
|
||||||
|
| Phase | What is delivered / proven | Concrete outputs (where) | Evidence / trace hooks |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Phase 1 — Discovery & system design | Reference architecture framing and decision drivers | Confluence (internal only): [System Design](https://confluence.telekom-mms.com/spaces/IPCEICIS/pages/856788272/System+Design) (planes model, CNOE baseline preference, dogfooding) | Architecture notes are the earliest “why” evidence for later component choices |
|
||||||
|
| Phase 2 — PoC definition | PoC scope, acceptance criteria, end-to-end “golden path” story | Repository (this docs repo): PoC structure page (docs-old) and Repository (edp-doc): PoC design README | Jira parts exist for user docs + hands-on building blocks (see “Ticket anchors” below) |
|
||||||
|
| Phase 3 — PoC consolidation & traceability | A packaged PoC with explicit traceability from backlog to outputs | Repository (this docs repo): PoC team-process guidance (Definition of Done, PR review, “traces”) | “Outcome” is expected to be summarized in the ticket with links to PR/commit artifacts |
|
||||||
|
| Phase 4 — Forgejo-as-a-Service + Foundry provisioning | A service milestone with operational concerns (persistence, backups, SSO, runners) and IaC provisioning | ADR (Scaleway as additional install channel) + postmortem (Foundry migration downtime) | Concrete operational evidence that architecture and migration risks were handled as governance work |
|
||||||
|
| Phase 5 — EdgeConnect integration | EdgeConnect as delivery target and integration tooling | Repository (this docs repo): EdgeConnect docs section + docs-old “Publishing to Edge” (deployment yaml) | Deployment configuration and workflow description provide concrete “proof of use” |
|
||||||
|
|
||||||
|
## Ticket anchors (PoC)
|
||||||
|
|
||||||
|
The PoC design README explicitly provides Jira anchors that can be used to build a full traceability matrix:
|
||||||
|
|
||||||
|
- Part 1 (User documentation): [IPCEICIS-368](https://jira.telekom-mms.com/browse/IPCEICIS-368)
|
||||||
|
- Part 2.1 (Local IdP creation): [IPCEICIS-765](https://jira.telekom-mms.com/browse/IPCEICIS-765)
|
||||||
|
- Part 2.2 (OSC IdP creation): [IPCEICIS-766](https://jira.telekom-mms.com/browse/IPCEICIS-766)
|
||||||
|
- Part 2.x.1 (Golden Path template): [IPCEICIS-514](https://jira.telekom-mms.com/browse/IPCEICIS-514)
|
||||||
|
- Part 2.x.2 (Fibonacci example app): [IPCEICIS-759](https://jira.telekom-mms.com/browse/IPCEICIS-759)
|
||||||
|
- Part 2.x.3 (Forgejo Actions CI/CD): [IPCEICIS-760](https://jira.telekom-mms.com/browse/IPCEICIS-760)
|
||||||
|
- Part 2.x.4 (Telemetry): [IPCEICIS-761](https://jira.telekom-mms.com/browse/IPCEICIS-761)
|
||||||
|
- Part 2.x.5 (OSC infrastructure): [IPCEICIS-762](https://jira.telekom-mms.com/browse/IPCEICIS-762)
|
||||||
|
- Part 2.x.6 (Additional items): [IPCEICIS-763](https://jira.telekom-mms.com/browse/IPCEICIS-763)
|
||||||
|
- Part 2.3 (Extended local orchestration): [IPCEICIS-767](https://jira.telekom-mms.com/browse/IPCEICIS-767)
|
||||||
|
- Part 3 (User documentation): [IPCEICIS-768](https://jira.telekom-mms.com/browse/IPCEICIS-768)
|
||||||
|
|
||||||
|
Related docs-old pages referenced by the history and matrix:
|
||||||
|
|
||||||
|
- [PoC Structure](/docs-old/v1/project/plan-in-2024/poc/)
|
||||||
|
- [Team and Work Structure](/docs-old/v1/project/team-process/)
|
||||||
|
|
||||||
|
See also: the central [References](/docs/governance/references/) index.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue