┌─────────────────────────────────────────────────────────────┐
│                    FLUJO CI/CD TERRAFORM                    │
└─────────────────────────────────────────────────────────────┘

  Developer         GitHub/GitLab          CI System         AWS/Azure/GCP
     │                    │                    │                    │
     │── git push ──────> │                   │                    │
     │── Abre PR ───────> │                   │                    │
     │                    │── Trigger CI ───> │                    │
     │                    │                   │── terraform fmt    │
     │                    │                   │── terraform validate│
     │                    │                   │── terraform plan   │
     │                    │<── Comenta Plan ──│                    │
     │<── Notificación ───│                   │                    │
     │                    │                   │                    │
     │── Aprueba PR ────> │                   │                    │
     │── Merge a main ──> │                   │                    │
     │                    │── Trigger CI ───> │                    │
     │                    │                   │── terraform plan   │
     │                    │                   │── [Aprobación?]    │
     │                    │                   │── terraform apply  │
     │                    │                   │──────────────────> │
     │                    │                   │<── Resultado ──────│
     │<── Notificación ───│<── Resultado ─────│                    │

# MAL - Nunca hagas esto
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# BIEN - Usa secretos del CI que se inyectan como variables de entorno
# La variable $AWS_ACCESS_KEY_ID viene del sistema CI como secreto
terraform plan

# MAL - Esto puede exponer credenciales en logs
env | grep AWS
printenv

# BIEN - Solo ejecutar los comandos necesarios
terraform init
terraform plan -out=tfplan
terraform apply tfplan

# backend.tf - Configuración de estado remoto para CI/CD

# Ejemplo con S3 (AWS)
terraform {
  backend "s3" {
    bucket         = "mi-empresa-terraform-state"
    key            = "produccion/infraestructura/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"  # Para el bloqueo
  }
}

# Ejemplo con Azure Blob Storage
# terraform {
#   backend "azurerm" {
#     resource_group_name  = "rg-terraform-state"
#     storage_account_name = "terrastateempresa"
#     container_name       = "tfstate"
#     key                  = "produccion.terraform.tfstate"
#   }
# }

# Ejemplo con GCS (Google Cloud)
# terraform {
#   backend "gcs" {
#     bucket = "mi-empresa-terraform-state"
#     prefix = "produccion/infraestructura"
#   }
# }

# GitHub Actions - Usando environments con required reviewers
jobs:
  apply:
    environment: produccion  # Este environment requiere aprobación manual
    runs-on: ubuntu-latest
    steps:
      - name: Terraform Apply
        run: terraform apply -auto-approve

# El "environment" de GitHub Actions puede configurarse para requerir
# aprobación de revisores específicos antes de que el job continúe

// Jenkins - Usando el paso "input"
stage('Aprobación Manual') {
    steps {
        input message: '¿Aprobar terraform apply en producción?',
              ok: 'Aprobar',
              submitter: 'admin,tech-lead'
    }
}

# atlantis.yaml - Configuración de Atlantis
version: 3
projects:
  - name: produccion-vpc
    dir: environments/produccion/vpc
    workspace: default
    autoplan:
      when_modified:
        - "**/*.tf"
      enabled: true

  - name: staging-app
    dir: environments/staging/app
    workspace: default
    autoplan:
      when_modified:
        - "**/*.tf"
      enabled: true

# .github/workflows/digger.yml
name: Digger
on:
  pull_request:
    types: [opened, synchronize]
  issue_comment:
    types: [created]

jobs:
  digger:
    runs-on: ubuntu-latest
    steps:
      - uses: diggerhq/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

┌──────────────────────────────────────────────────────┐
│                  GITOPS CON TERRAFORM                │
└──────────────────────────────────────────────────────┘

  Git Repository          CI/CD System            Infraestructura
  (Fuente de Verdad)
       │                       │                        │
       │  Estado Deseado ────> │                        │
       │                       │── Compara con ──────> │
       │                       │<── Estado Actual ──────│
       │                       │                        │
       │                       │── Si hay diferencia:  │
       │                       │── terraform apply ──> │
       │                       │                        │
       │                       │   Infraestructura      │
       │                       │   converge al estado   │
       │                       │   deseado en Git       │

# pipeline-terraform-generico.yml
# Este es un pseudocódigo que ilustra las etapas
# La sintaxis real varía según el sistema CI/CD

pipeline:
  # ETAPA 1: Preparación del entorno
  setup:
    - checkout del repositorio
    - instalar Terraform versión X.Y.Z
    - configurar credenciales de nube (desde secretos del CI)
    - ejecutar: terraform init -backend-config="..."

  # ETAPA 2: Validación de código
  validate:
    - ejecutar: terraform fmt -check -recursive
      # Falla si el código no está formateado correctamente
    - ejecutar: terraform validate
      # Verifica la sintaxis y consistencia del código
    - ejecutar: tflint  (opcional)
      # Linter adicional para mejores prácticas
    - ejecutar: tfsec   (opcional)
      # Análisis de seguridad estático

  # ETAPA 3: Plan
  plan:
    - ejecutar: terraform plan -out=tfplan -no-color
    - guardar tfplan como artefacto
    - si es un PR: publicar el output del plan como comentario

  # ETAPA 4: Aprobación (solo en rama principal)
  approval:
    condicion: solo si es merge a main
    - esperar aprobación manual de persona autorizada
    timeout: 24 horas

  # ETAPA 5: Apply (solo en rama principal)
  apply:
    condicion: solo si es merge a main Y aprobación recibida
    - ejecutar: terraform apply tfplan
    - publicar resultado (éxito/fallo)
    - notificar al equipo

# Este ejemplo muestra la estructura con pasos más concretos

stages:
  - name: "Inicializar"
    commands:
      - |
        # Instalar Terraform si no está disponible
        terraform version || {
          wget https://releases.hashicorp.com/terraform/1.9.0/terraform_1.9.0_linux_amd64.zip
          unzip terraform_1.9.0_linux_amd64.zip
          mv terraform /usr/local/bin/
        }

      - |
        # Inicializar Terraform con backend remoto
        terraform init \
          -backend-config="bucket=${TF_STATE_BUCKET}" \
          -backend-config="key=${TF_STATE_KEY}" \
          -backend-config="region=${AWS_REGION}"

  - name: "Validar"
    commands:
      - terraform fmt -check -recursive
      - terraform validate

  - name: "Plan"
    commands:
      - |
        # Generar el plan y capturar el output
        terraform plan \
          -var-file="environments/${ENVIRONMENT}.tfvars" \
          -out=tfplan \
          -no-color 2>&1 | tee plan-output.txt

      - |
        # Publicar el plan como comentario en el PR
        # (Esto varía según la plataforma)
        post_pr_comment "$(cat plan-output.txt)"

  - name: "Apply"
    condicion: "rama == main"
    commands:
      - |
        # Aplicar el plan guardado
        terraform apply -auto-approve tfplan

      - |
        # Notificar resultado
        if [ $? -eq 0 ]; then
          notify_slack "✅ Terraform apply exitoso en ${ENVIRONMENT}"
        else
          notify_slack "❌ Terraform apply falló en ${ENVIRONMENT}"
          exit 1
        fi

# Solución: Liberar el lock manualmente (con cuidado)
terraform force-unlock LOCK_ID

# Verificar el estado del lock en DynamoDB (AWS)
aws dynamodb get-item \
  --table-name terraform-state-lock \
  --key '{"LockID": {"S": "mi-empresa-terraform-state/produccion/terraform.tfstate"}}'

# Para debugging (temporal, nunca en producción)
aws sts get-caller-identity
# Muestra qué identidad está usando Terraform

# versions.tf
terraform {
  required_version = "= 1.9.0"  # Versión exacta, no rango

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "= 5.50.0"
    }
  }
}

# En el pipeline, instalar la versión exacta
tfenv install 1.9.0
tfenv use 1.9.0

# MAL - La variable no se pasa a Terraform
export DB_PASSWORD="secreto"
terraform apply

# BIEN - Usar el prefijo TF_VAR_ para variables de Terraform
export TF_VAR_db_password="secreto"
terraform apply
# Ahora Terraform puede usar la variable "db_password"

# MAL - Puede aplicar cambios diferentes a los planeados
terraform apply -auto-approve

# BIEN - Siempre usar el plan guardado
terraform plan -out=tfplan
terraform apply tfplan
# Esto garantiza que se aplica exactamente lo que se revisó

┌────────────────────────────────────────────────────────────────┐
│              DIAGRAMA DE FLUJO DEL PIPELINE                    │
└────────────────────────────────────────────────────────────────┘

Pull Request abierto/actualizado:
  ┌──────────────────────────────────────────────┐
  │  1. Checkout del código                      │
  │  2. Setup Terraform 1.9.0                    │
  │  3. terraform init (backend staging)         │
  │  4. terraform fmt -check                     │
  │  5. terraform validate                       │
  │  6. terraform plan -var-file=staging.tfvars  │
  │  7. Comentar plan en el PR                   │
  └──────────────────────────────────────────────┘

Merge a main:
  ┌──────────────────────────────────────────────┐
  │  1. Checkout del código                      │
  │  2. Setup Terraform 1.9.0                    │
  │  3. terraform init (backend staging)         │
  │  4. terraform plan -var-file=staging.tfvars  │
  │  5. terraform apply (staging)                │
  └──────────────────────────────────────────────┘

Push de tag v*.*.*:
  ┌──────────────────────────────────────────────┐
  │  1. Checkout del código                      │
  │  2. Setup Terraform 1.9.0                    │
  │  3. terraform init (backend produccion)      │
  │  4. terraform plan -var-file=prod.tfvars     │
  │  5. ⏸ ESPERAR APROBACIÓN MANUAL (24h)       │
  │  6. terraform apply (produccion)             │
  └──────────────────────────────────────────────┘

# Configuración del pipeline (pseudocódigo estructurado)

secretos_requeridos:
  - AWS_ACCESS_KEY_ID_STAGING
  - AWS_SECRET_ACCESS_KEY_STAGING
  - AWS_ACCESS_KEY_ID_PRODUCCION
  - AWS_SECRET_ACCESS_KEY_PRODUCCION
  - TF_STATE_BUCKET  # Bucket S3 para el estado
  - SLACK_WEBHOOK    # Para notificaciones

variables_globales:
  TF_VERSION: "1.9.0"
  AWS_REGION: "us-east-1"
  DYNAMODB_TABLE: "terraform-locks"

jobs:

  # Job 1: Validación y plan para PRs
  pr-check:
    trigger: pull_request
    ambiente: staging
    pasos:
      - checkout
      - setup terraform ${TF_VERSION}
      - configurar credenciales AWS staging
      - terraform init -backend-config="key=staging/terraform.tfstate"
      - terraform fmt -check
      - terraform validate
      - terraform plan -var-file=environments/staging.tfvars -out=tfplan
      - publicar output del plan como comentario en PR

  # Job 2: Apply automático en staging
  staging-apply:
    trigger: push a main
    ambiente: staging
    pasos:
      - checkout
      - setup terraform ${TF_VERSION}
      - configurar credenciales AWS staging
      - terraform init -backend-config="key=staging/terraform.tfstate"
      - terraform plan -var-file=environments/staging.tfvars -out=tfplan
      - terraform apply tfplan
      - notificar en Slack resultado

  # Job 3: Plan y apply en producción con aprobación
  produccion-plan:
    trigger: push de tag v*.*.*
    ambiente: produccion
    pasos:
      - checkout
      - setup terraform ${TF_VERSION}
      - configurar credenciales AWS produccion
      - terraform init -backend-config="key=produccion/terraform.tfstate"
      - terraform plan -var-file=environments/produccion.tfvars -out=tfplan
      - guardar tfplan como artefacto
      - notificar en Slack: "Plan listo, pendiente aprobación"

  produccion-apply:
    trigger: aprobación manual después de produccion-plan
    depende_de: produccion-plan
    ambiente: produccion
    timeout_aprobacion: 24 horas
    aprobadores: ["tech-lead", "devops-manager"]
    pasos:
      - descargar tfplan del artefacto
      - terraform apply tfplan
      - notificar en Slack resultado

# Estructura de archivos del proyecto
estructura_proyecto:
  ├── main.tf
  ├── variables.tf
  ├── outputs.tf
  ├── versions.tf
  ├── backend.tf
  └── environments/
      ├── staging.tfvars
      └── produccion.tfvars

# environments/staging.tfvars
environment    = "staging"
instance_type  = "t3.micro"
replica_count  = 1
min_capacity   = 1
max_capacity   = 3

# environments/produccion.tfvars
environment    = "produccion"
instance_type  = "t3.large"
replica_count  = 3
min_capacity   = 3
max_capacity   = 10