Skip to content
LyftData Docs

GitOps CLI Beta

GitOps is a CLI-first workflow for platform operators who want to manage LyftData deployment desired state from files reviewed in source control.

Supported scope

Use GitOps when you want to:

  • validate desired state from a manifest before applying it,
  • reconcile one tenant and one environment at a time,
  • promote a reviewed revision from a source environment such as dev to a target environment such as prod,
  • require explicit approval evidence for promotion and rollback,
  • list runs and inspect run events for audit trails,
  • compare environment status and drift from the Deployments UI.

The beta scope does not include in-server Git checkout, branch management, UI-based apply/promotion/rollback, or broad tenant-admin self-service across all Deployment Manager operations. Keep checkout, branch policy, pull requests, and CI approval gates in your normal source-control and release tooling.

Prerequisites

  • A licensed LyftData server with Deployments enabled.
  • The lyftdata CLI installed on the operator machine or CI runner.
  • A platform-admin account or API identity authorized to manage GitOps desired state.
  • Desired-state files stored in a Git repository or another reviewed change-control system.
  • Environment names such as dev and prod agreed by the platform team.

Authenticate the CLI before running GitOps commands:

Terminal window
lyftdata --url https://lyftdata.example.com/ login admin

If your server still uses a self-signed certificate during evaluation, add --tls-insecure or set LYFTDATA_TLS_INSECURE=true until you install a trusted certificate.

Manifest shape

A GitOps manifest points LyftData at the desired-state files for a tenant. Git metadata is recorded as provenance; LyftData does not pull from Git itself.

schema_version: v1
source:
  repo: git@example.com:acme/lyftdata-config.git
  ref: refs/heads/main
  commit_sha: 0000000000000000000000000000000000000000
  generated_by: ci
  ci_run_id: build-123
scope:
  tenant_id: default
includes:
  - kind: workflow
    paths:
      - workflows/telemetry-cost-control.workflow.yaml
  - kind: worker_group
    paths:
      - worker-groups/default-workers.yaml
  - kind: deployment
    paths:
      - deployments/telemetry-cost-control.deployment.yaml

Supported beta resources include workflows, library jobs, deployments, worker groups, worker settings, and contexts. Secrets should stay reference-only; do not commit raw secret values into GitOps manifests or included files.

Validate and plan

Run validation before producing a plan:

Terminal window
lyftdata git-ops validate \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment dev

Then generate a plan. The optional --out file is useful for review records in CI:

Terminal window
lyftdata git-ops plan \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment dev \
  --out artifacts/gitops-dev-plan.json

For a quick operator review, use diff:

Terminal window
lyftdata git-ops diff \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment dev

Apply to an environment

Apply only after validation and review pass:

Terminal window
lyftdata git-ops apply \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment dev

apply creates or updates managed artifacts for the selected tenant/environment. Deletions require --prune and are scoped to resources already owned by the same GitOps source identity. Taking over existing managed resources requires an explicit --adopt-managed decision.

Promote to production

Promotion reuses the reviewed desired-state source revision and records approval evidence. First plan the promotion:

Terminal window
lyftdata git-ops promote-plan \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --source-revision refs/heads/main \
  --source-environment dev \
  --target-environment prod

Then apply it with approval evidence:

Terminal window
lyftdata git-ops promote-apply \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --source-revision refs/heads/main \
  --source-environment dev \
  --target-environment prod \
  --approval ops-lead:change-123 \
  --min-approvals 1

Use repeated --approval APPROVER[:EVIDENCE] flags when your release policy requires more than one approval.

Inspect runs and events

List recent runs:

Terminal window
lyftdata git-ops runs \
  --tenant default \
  --environment prod \
  --limit 10

Inspect a run and include its events:

Terminal window
lyftdata git-ops run-status \
  --run-id <run-id> \
  --events

Record the run IDs, bundle hash, approvals, and final status in your change-management system.

Roll back

Rollback submits the desired-state bundle from a prior successful apply run back to the target environment.

Plan the rollback:

Terminal window
lyftdata git-ops rollback-plan \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment prod \
  --to-run-id <prior-successful-prod-run-id>

Apply it with approval evidence:

Terminal window
lyftdata git-ops rollback-apply \
  --manifest lyftdata-gitops.yaml \
  --tenant default \
  --environment prod \
  --to-run-id <prior-successful-prod-run-id> \
  --approval ops-lead:rollback-123 \
  --min-approvals 1

After rollback, inspect the rollback run, check the Deployments UI for environment status/drift, and confirm workloads converge.

CI checklist

  • Manifest and included desired-state files are reviewed in source control.
  • CI runs validate, plan, or diff for pull requests.
  • Apply to dev is recorded with run ID and bundle hash.
  • Promotion to prod requires approval evidence.
  • Rollback target run IDs are easy to find from release records.
  • Operators inspect run events and environment drift after apply, promotion, or rollback.