The site that you are currently viewing is a static version of the Software Factory documentation delivered with the

version v7.2.
For up-to-date documentation, see the latest version.

ADR

Architecture decision record

  7 minute read  

You find here the detailed architecture decision record that references in the TASD .

For information part of theses decision are logged in Lewis Craftsmanship archi decisions list .

ADR001: From services to product to deploy services

Status: Accepted in September 2022

Context

  • Software Factory services available on TDP C2, TDP C3, RTDP.
  • Code for TDP C2 & TDP C3 + platform is similar (pipeline, terraform for IaaS, helm + kubectl for Kubernetes) but not in only one code base.
  • Need to merge our different repos.
  • Need to deploy a Software Factory on CASTLE.
  • Plan to deploy Country Eyes Only Software Factories.

Decision

  • New deliverable: a product.
  • Deploy and update CASTLE with the product (1rst deployment in March 2023).
  • In the mid/long term, platform TDP C2 & C3 will migrate to the product delivery.
  • Keep in mind that RTDP is currently directly deployed on a VM and will not be compatible with the product.

Consequences

  • Put in place Smart Delivery team that will manage the product.

ADR002: Deploy using Flux

Status: Accepted in January 2023

Context

  • Software Factory product launch.
  • Deploying SF on TDP C2 & TDP C3-CA with pipelines & runners.
  • DevOps mode.
  • Analysis on different deployment mode (DevOps with pipeline, GitOps with Flux / with ArgoCD) + POC.
  • Pipeline require credential to be external of the Kubernetes Cluster.
  • Flux deploy and update using one source of trust, and store internally secrets.
  • GitLab choose Flux.

Decision

  • Use Flux.

Consequences

  • Refactor POC to become the product.

ADR003: Add components Black Duck and Synopsys Alert

Status: Accepted in June 2024

SWaaP in EA

Context

  • Software Factory product v0.x with GitLab, Artifactory and Xray
  • SWaaP v0.x is deployed on CASTLE.
  • Still deploying SF on TDP C2 & TDP C3-CA with pipelines & runners.

Decision

Consequences

  • Update documents: TASD
  • Add COTS and associated LLD

ADR004: Add components Xray, Orchestrator, Code companion and SF Documentation

as bundle and Add Boarding & Offer Management as add-on

Status: Accepted in September 2024

Context

  • SWaaP v1.4 is delivered

Decision

Consequences

  • Update documents: TASD
  • Add COTS and associated LLD

ADR005: Remove Boarding & Offer Management; Add component Coverity

Status: Accepted in April 2025

Context

  • SWaaP v3.0 is delivered.
  • Coverity introduction was partially done but not officially added to SWaaP.

Decision

Consequences

ADR006: Switch to a fork to build containers with Kaniko

Status: Accepted in September 2025

Context

  • Risk DVa-13 No more acceptable to build container on Software Factory with Kaniko because OSS project is archived.

Decision

Consequences

ADR007: Add Diagram as code with Kroki component as bundle

Status: Accepted in September 2025

Context

  • SWaaP v4.1 is delivered

Decision

Consequences

ADR008: Move from nginx Ingress to Gateway API

Status: Accepted in June 2026

Context

Introduction

The Kubernetes SIG Network and Security Committees announced recently the depreciation and retirement of Ingress-nginx in March 2026.

Ingress-nginx is the most popular implementation of the Ingress API and so is a critical component to be able to deploy and use the Software Factory. Indeed, all HTTP requests are managed and routed by the Ingress Controller.

SWaaP only support (see prerequisites and TASD PRE_05 ) one Ingress Controller: the Ingress-nginx Controller developed by the Kubernetes community.

Note

All development and integration environments use the Ingress-nginx Controller.

Besides, the default provided SWaaP configuration relies on custom nginx annotations to configure the Ingresses that expose the services (for example: WAF configuration).

We also depend on what is made available by the different editors we integrate.

Ingress API status

It’s fundamental to dissociate the Ingress API defined by Kubernetes from its implementation. Various editors provide controllers that implement that specification.

The only thing that is retired is one implementation from the Kubernetes community based on nginx (called Ingress-nginx Controller).

Regarding the API, the official documentation clearly states that:

  • The Ingress API is generally available
  • The Ingress API is subject to the stability guarantees for GA APIs
  • The Kubernetes project has no plans to remove Ingress from Kubernetes

But it also states that:

  • The Ingress API has been frozen
  • The Ingress API is no longer being developed, and will have no further changes or updates made to it.

And so, The Kubernetes project recommends using Gateway (Gateway SIGS ) instead of Ingress .

SWaaP status

Platfrom status

  • TDP:
    • Not using the product
    • KaaS is supporting GW-API. On integration platform, need KaaS upgrade.
  • RTDP:
    • Already using GW-API with Istio x envoy - Developed on their side
    • May use product as soon as delivery is ready, but as already implemented locally no hurry/dependency.
  • TP-S3NS
    • Already using GW-API with Google - Developed on their side
    • Will use our delivery as soon as published, but as already implemented locally no hurry/dependency.
  • CASTLE:
    • Support GW-API Istio Reference
    • Plan to be decommissioned after TP-S3NS migration, so may no have plan to migrate.
  • R-Castle
    • GW-API not supported. In their roadmap.
  • CEO:
    • TNL: Use VMware AVI Load Balancer (Tanzu)
    • TAU: Use VMware AVI Load Balancer (Tanzu)
    • TUK: Use nginx for now. Traefik is candidate
    • So no plan regarding GW-APIs
  • Air Gap

Others

In consequence, we will have every scenario from users that will stay on nginx and others ready to ship.

Currently some components of SWaaP integrate WAF. These annotations will be move to envoy.

DevEnv is required for testing both ingress & Gateway API.

Integration platform currently uses nginx ingress. A KaaS ‘upgrade’ (migration to a fresh new cluster) is planed between SWaaP 7.0 & SWaaP 7.1 delivery.

On components part:

Decision

  • Move to Gateway API with Istyo implementation
  • For DevEnv, support both nginx ingress and Gateway API
  • Transition strategy:
    • nginx recommended SWaaP <= 8.0.
    • Gateway API recommended SWaaP >= 8.1 and nginx deprecated
    • but nginx still supported until SWaaP 10.0.
  • Integration platform will test Gateway API configuration inline with release description.
  • WAF migartion with Istio envoy implementation

Consequences

Don’t support for Kroki

Risk open & accepted to no more testing nginx Ingress on integration platform.

Communicate in release 7.2 on that plan.

Last modified 18.06.2026: review for decision meeting. (a70ed01)