Delivery Pipelines

BtSavvy's posture on delivery pipelines

Delivery pipelines are interchangeable in a way clouds and model providers are not. GitHub Actions, Azure DevOps, GitLab CI, Jenkins, CircleCI, Buildkite: each has its own configuration grammar, hosted-runner economics, and integration surface. None of them, on its own, makes a pipeline production-grade. What makes a pipeline production-grade is what runs inside it: the tests, the quality gates, the named-engineer sign-offs, the artefact attestations, the policy-as-code checks. The tool is the substrate; the discipline is what produces the signed evidence.

BtSavvy's posture on pipeline tooling is therefore tool-aware and tool-agnostic on outcome. The firm builds pipelines on whichever tool the client's environment prescribes, and applies the same FORGE pipeline-vending discipline regardless. The deliverable is the same shape on GitHub Actions as on Azure DevOps as on GitLab CI: a self-service pipeline-vending capability the client's engineering teams can extend without re-engaging the firm.

Which services carry pipeline tooling

DevSecOps. The firm's pipeline-vending capability: self-service templates that emit production-grade pipelines for the client's chosen tool, with FORGE quality gates, gate-log emission, and policy-as-code integration built in.

Build. Application engineering depends on the pipeline; the Build service treats pipeline configuration as code that ships with the application rather than as infrastructure managed separately.

Cloud. Pipeline-vending is a Cloud platform-engineering discipline at the organisation level: landing-zone-grade pipeline templates every team pulls from rather than authoring fresh.

FORGE on delivery pipelines

Factory. The customised builder produces pipelines as artefacts. Pipeline-as-code lives in the same repository as the application code; pipeline templates are themselves accelerators in the firm's accelerator library.

Observability. Pipeline runs emit structured telemetry: duration, gate outcomes, named-engineer attribution, artefact attestations. Pipeline observability is a first-class surface, not a side concern.

Review. The signed gate log is partly a pipeline artefact. Every gate the pipeline enforces (test pass, security scan, policy-as-code pass, peer review, named promotion approval) emits a record into the gate log with the accountable engineer's attribution.

Governance and Trust. Policy-as-code runs as a pipeline gate. EU AI Act conformance checks, ISO/IEC 42001 control evidence, and NIST AI RMF mappings are emitted by the pipeline at promotion time and recorded against the deployment.

Expert Intelligence. Model-promotion pipelines specifically (frontier-model fine-tunes, custom-model evaluations, retrieval-architecture refreshes) are pipelined under the same discipline as application code. A model is not promoted into production until the pipeline says it is.

Engagement-pattern sketches

Representative patterns FORGE is built to deliver across pipeline tools:

A GitHub Actions pipeline-vending capability for an organisation of many teams. Self-service templates emit production-grade GitHub Actions workflows with FORGE gates pre-configured. Teams can extend; the templates are versioned and governed.

An Azure DevOps to GitHub Actions migration with FORGE discipline preserved. Migrating a large estate while preserving (and tightening) the signed-gate-log discipline. The migration is itself signed at every gate.

A GitLab CI pipeline for a frontier-model fine-tune workflow. A model-promotion pipeline that runs evaluation, calibration-skew checks, retrieval-quality regression, and policy-as-code conformance in sequence, with an accountable engineer approving the model into production at the final gate.