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
|
||||
- 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