website-and-documentation/content/en/docs/governance/project-history/_index.md

title	linkTitle	weight	description
Project history	History	10	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

Phases and milestones

The following phase model is derived from the documented primary sources referenced in this chapter (Confluence and the referenced repositories). The phrasing focuses on “what changed and why”; it is not a release plan.

Terminology: 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.
• “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

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
• Repository (this repo): docs-old PoC structure summary: PoC Structure

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, 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 (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: Scrum working agreement.
• Collaborative delivery techniques (mob / ensemble programming) appear as an explicit practice, including in incident documentation (“Team: Mob”) and internal guidance on sustainable mobbing models.

Team enablement and skill development (PII-free synthesis)

This section summarizes team enablement and skill development, based on the project’s documented sources, and is presented without personal data¹:

• Baseline skill assumptions: Kubernetes and GitOps are foundational. The platform architecture explicitly uses Kubernetes and a CNOE-derived stacks concept (see Platform Orchestration).
• Enablement/training happened as part of delivery (not a separate “academy”): retrospectives and planning explicitly track knowledge-sharing sessions and training topics (internal only, see References).
• Kubernetes enablement: a Kubernetes introduction training was planned as part of team onboarding/enablement activities (internal only; see References).
• Go as a relevant skill: multiple components are implemented in Golang (e.g., EdgeConnect tooling, Forgejo). Internal material discusses Golang developer skill profiles; this docs repo does not contain a single, explicit record of a dedicated “Go training” event.
• Skill leveling via collaboration: Mob Programming is used as a deliberate practice for knowledge sharing and onboarding less experienced developers (see Forgejo docs entry).

See also: the central References index.

---

1. PII = “personally identifiable information”. “PII-free synthesis” means summarizing patterns and practices without including names, participant lists, or direct quotes that could identify individuals. ↩︎