[Roadmap] Progressive GitOps enablement with Atlantis

[accuser]

Context

The Atlantis module exists and the GitOps infrastructure is in place (#177, closed). This issue tracks the operational rollout strategy — progressively enabling Atlantis from read-only to full autonomous apply.

Current State

• Atlantis module implemented and deployable (var.enable_gitops)
• GitHub webhook integration built (Set up GitHub webhook integration for Atlantis #186, closed)
• CI validates Terraform on PRs (format, validate)
• Manual make apply is the current deployment method
• Secrets are in gitignored terraform.tfvars (Implement secret management for untracked configuration files #262, open)

Progressive Enablement Stages

Stage 1: Plan-only mode (low risk)

Atlantis comments tofu plan output on PRs but cannot apply.

Prerequisites:

• Deploy Atlantis with enable_gitops = true
• Configure GitHub webhook
• Set --disable-apply flag in Atlantis config

Value: Reviewers see plan output directly in PR without running locally.

Stage 2: Gated apply for non-destructive changes

Atlantis can apply changes that only create or update resources. Destructive changes (destroy, replace) require manual make apply.

Prerequisites:

• Secrets accessible to Atlantis (Implement secret management for untracked configuration files #262)
• Atlantis atlantis.yaml workflow with policy checks
• Conftest policies to block destructive plans (Conftest already included in Atlantis image)

Value: Routine changes (new services, config updates) flow through GitOps.

Stage 3: Full apply with post-apply verification

Atlantis can apply all changes, with automated verification gates.

Prerequisites:

• Post-apply verification gates implemented (Add post-apply verification gates for GitOps workflows #264)
• Comprehensive health checks (Add comprehensive health checks and alerting #225)
• State locking resolved (Implement state locking for S3 backend #223)
• Drift detection active (Implement automated drift detection #237)

Value: Full GitOps — merge to main triggers apply, verification confirms success.

Stage 4: Multi-environment promotion

Changes are applied to cluster01 first, verified, then promoted to iapetus (or vice versa).

Prerequisites:

• All Stage 3 prerequisites
• Atlantis multi-environment workflow configuration
• Environment-specific approval gates

Value: Blast radius limited by staged rollout.

Key Dependencies

#262 Secrets management ──────┐
#223 State locking ───────────┤
#237 Drift detection ─────────┼──► Stage 3: Full GitOps
#225 Health checks ───────────┤
#264 Post-apply verification ─┘

Acceptance Criteria

• Stage 1 operational (plan comments on PRs)
• Stage 2 operational (non-destructive auto-apply)
• Stage 3 operational (full apply with verification)
• Stage 4 operational (multi-environment promotion)

Priority

Medium — strategic goal, dependencies must be resolved first