Skip to content

Deployment Rule (Mandatory)

Standard ID: ES-DEPLOY Status: BINDING Date: 2026-07-21 Authority: Engineering Standard — Bluefly Agent Platform Scope: All deployments targeting the Oracle Runtime or any other production environment

Core Axiom

The runtime is disposable and immutable. Deployment is a reconciliation of Desired State via Release Bundles, not a manual execution of scripts.

Prohibited Actions

The following actions are STRICTLY PROHIBITED and represent a critical violation of the platform architecture:

  1. git pull on Production: The runtime MUST NEVER hold a Git checkout of application source code or raw Compose files.
  2. Manual Docker Compose: Executing docker compose up, down, or restart directly on the host to deploy or fix an application is banned.
  3. SSH Deployment: No CI pipeline, agent, or operator may use SSH to push deployments, execute scripts, or mutate state on Oracle.
  4. Mutable Production Configuration: Modifying configuration files directly on the runtime host is banned.
  5. Runtime-Owned Source Code: Oracle MUST NOT own, build, or compile source code.
  6. Manual Script Execution: One-off deployment scripts executed by humans or CI over SSH are prohibited.

Required Mechanisms

All deployments MUST utilize the following mechanisms:

  1. Infrastructure as Code (IaC): The baseline Oracle host is provisioned, bootstrapped, and configured exclusively via IaC (e.g., Terraform, cloud-init).
  2. Continuous Integration (CI): GitLab CI is the sole authority for building and testing code.
  3. Release Bundles: CI must package the infrastructure manifest, exact OCI image SHAs, packs, and SBOM into a versioned, immutable Release Bundle artifact.
  4. Desired State Governance: Bluefly (the Governance Plane) dictates the desired state by mapping a Release Bundle to an Environment.
  5. Autonomous Reconciliation: Gas City (the Execution Plane) is the sole entity authorized to reconcile Bluefly's desired state against the Oracle runtime.
  6. Immutable Artifacts: Only compiled, version-locked artifacts are deployed.

Release / Tag / Deploy Chain

This is the canonical document for the full chain from a feature change to a verified Oracle deployment; rules/deployment-contract.md and standards/core/deployment-standard.md cover the same immutable-deployment axiom and defer to this document for the chain below.

feature branch
    -> release branch (release/v0.N.x)
        -> tested pipeline at release-HEAD
            -> promotion MR (release -> main)
                -> main
                    -> version/tag
                        -> deploy (Release Bundle reconciliation, per above)
                            -> MAYOR-ORACLE verification on Oracle
  • What currently creates deployable state: a green pipeline at release-branch HEAD, per §"Continuous Integration" above.
  • What creates a tag, and who authorizes it: settled in git-standard.md. The human gate is the release/v0.N.x → main promotion MR (RELEASE_TO_MAIN_AUTO_MERGE=NO). After that MR merges, shared CI automatically stamps the next patch tag on the tested release SHA, publishes the stable package, and resets the development sequence to the next patch. Do not invent a minor bump. Do not require a second human click to tag.
  • What the deploy pipeline consumes: the tagged Release Bundle (§ above) — never a branch HEAD, never an untagged commit.
  • What verifies Oracle after deploy: MAYOR-ORACLE independently confirms the deployed state matches the Release Bundle's Desired State — see the Source/Runtime Convergence Formula's closing contract (standards/core/convergence-doctrine.md §10): a merged promotion MR or a green deploy pipeline is not itself deployment proof; only a runtime-owner verification on Oracle closes the loop.
artifact:
  owner:        BluCity-Docs
  consumer:     All engineers and agents deploying software
  purpose:      Eradicates SSH-based manual deployments in favor of immutable artifact reconciliation
  lifetime:     permanent
  authority:    BluCity-Docs
  replaces:     none
  enforcement:  ci-verified

Failure Contract

If any system or operator is found mutating the Runtime Plane directly (e.g., via SSH or manual script execution): - The mutation is considered a security and compliance violation. - The affected infrastructure node must be destroyed and reprovisioned from IaC. - The workflow must be corrected to use standard Release Bundles and the governed deploy pipeline.

See Also