This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Project history

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:

    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.

    Phase 6 — EdgeConnect ecosystem expansion and platform hardening (2026)

    Focus:

    • Ship the first production-grade AI-native tooling layer for EdgeConnect (MCP Server).
    • Harden the EDP platform: security posture, platform upgrade, and operational reliability.
    • Complete the runner resource optimization PoC, giving teams data-driven right-sizing recommendations.
    • Deliver use-case examples that lower the onboarding barrier for EdgeConnect customers.
    • Continue upstream open-source contributions to Forgejo (ephemeral runners, webhook triggers).

    MCP Server for EdgeConnect (IPCEICIS-6969, IPCEICIS-7085)

    The Edge Connect MCP Server reached a production milestone in Q1 2026. It exposes all App and AppInstance CRUD operations through the Model Context Protocol, letting AI assistants such as Claude Desktop and Claude Code manage EdgeConnect resources through natural language.

    The Q1 delivery shipped:

    • Local stdio transport for desktop AI clients
    • Full App and AppInstance CRUD (create, list, show, update, delete, refresh)
    • OAuth 2.1 / JWT authentication for remote deployments
    • Rich HTML dashboards via MCP-UI alongside structured JSON responses
    • Installation and usage documentation at /docs/edgeconnect/edge-connect-mcp/

    Evidence:

    GARM provider for EdgeConnect (IPCEICIS-5752, IPCEICIS-5755)

    The GARM Edge Connect provider was completed, enabling ephemeral Forgejo Actions runners to be dynamically provisioned as Kubernetes pods on EdgeConnect cloudlets. This allows CI/CD capacity to scale elastically across edge locations with automatic resource cleanup after each job.

    Evidence:

    Forgejo 14 upgrade (IPCEICIS-7848)

    The EDP production instance at edp.buildth.ing was upgraded to Forgejo 14 in Q1 2026. This resolved outstanding version lag and enabled adoption of the latest upstream GARM integration features.

    Security hardening (IPCEICIS-8008, IPCEICIS-8009, IPCEICIS-8011, IPCEICIS-8012)

    A dedicated security hygiene epic was executed across Q1 2026, delivering:

    • Multi-Factor Authentication (MFA): MFA enabled and enforced for EDP platform users
    • Forgejo administration cleanup: Removal of redundant admin accounts and service accounts; access reviewed and tightened
    • Trivy scan automation: Automated container and dependency vulnerability scanning integrated into EDP pipelines via a Forgejo Action, with results uploaded to Dependency-Track

    Runner resource optimization PoC (IPCEICIS-6887, IPCEICIS-7421, IPCEICIS-7413)

    A proof-of-concept was completed that analyses historical CPU and memory utilization from CI/CD pipeline runs to recommend right-sized runner configurations. The smallest runner that covers the peak usage with a 20% safety margin is surfaced — without auto-enforcing changes.

    Alongside this, a runner sustainability dashboard was shipped into Forgejo’s runner settings page, showing which runners were used per job, historical usage trends, and current runner statuses for per-project sustainability tracking.

    Evidence:

    EdgeConnect use-case examples (IPCEICIS-7280, IPCEICIS-7281, IPCEICIS-7285)

    To accelerate customer onboarding, several use-case deliverables were produced:

    • An example application with database access was created and documented, demonstrating end-to-end deployment of a stateful application on EdgeConnect
    • API interaction overview materials (slides and documentation) were produced showing the full breadth of ways to interact with EdgeConnect — CLI, SDK, Terraform, Actions, MCP Server

    Evidence:

    Redis reliability fix (IPCEICIS-7398)

    Redis (the Distributed Cache Service used by Forgejo on OTC) regularly reached capacity under active crawling loads, causing 500 errors across Forgejo operations. A cloud function was created to automatically clear Redis when it approaches capacity, with an OTC Cloud Eye alarm and notification channel triggering it. This eliminates the need for manual intervention to restore Forgejo availability.

    Forgejo upstream contributions (IPCEICIS-6557)

    Open-source contributions to the upstream Forgejo project continued in 2026, including follow-up on previously merged PRs and tracking of new PRs:

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

    • 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. ↩︎