CI/CD

Declarative Automation Bundles —antes Asset Bundles— describen jobs, pipelines, permisos, artefactos y configuración junto al código. `databricks.yml` identifica el bundle y puede incluir ficheros por dominio; `resources` usa el esquema de las APIs de Databricks, mientras `artifacts` construye wheels u otros entregables. `sync` controla qué fuentes se envían al workspace.

Un bundle no reemplaza Terraform para infraestructura de cuenta o nube. Su frontera natural son recursos del proyecto dentro de Databricks. Evita un YAML monolítico: separa `resources/jobs.yml`, `resources/pipelines.yml` y variables; valida que referencias como `${resources.jobs.orders.id}` se resuelven sin hardcodear IDs entre ambientes.

bundle:
  name: orders-platform

include:
  - resources/*.yml

artifacts:
  default:
    type: whl
    build: python -m build
    path: .

sync:
  include:
    - src/**
    - tests/**
  exclude:
    - .venv/**

Un target aplica variables, workspace, modo y overrides a la misma definición base. Development mode añade aislamiento apropiado al desarrollador y permite iteración; production mode aplica validaciones y nombres estables. Las variables cambian catálogo, esquema, policy o warehouse, pero no deben duplicar toda la definición del job.

Usa `${bundle.target}` y `${workspace.current_user.userName}` para rutas de desarrollo, y una identidad de despliegue estable en producción. Define `run_as` de forma explícita: quien despliega no tiene por qué ser quien ejecuta. Antes de promocionar, compara el plan para detectar eliminaciones o reemplazos inesperados.

variables:
  catalog:
    description: Catálogo de datos del target

targets:
  dev:
    mode: development
    default: true
    variables:
      catalog: dev
    workspace:
      root_path: /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}

  prod:
    mode: production
    variables:
      catalog: prod
    run_as:
      service_principal_name: ${var.prod_run_as}

`bundle validate` resuelve configuración y comprueba el esquema contra el target. `bundle plan` muestra acciones previstas sin aplicarlas. `bundle deploy` sincroniza artefactos y recursos, y `bundle run` ejecuta un recurso ya desplegado. Una pipeline segura captura el plan, requiere aprobación para cambios destructivos y despliega el mismo artefacto validado.

La validación no ejecuta SQL ni demuestra permisos de datos del `run_as`. Después del deploy, ejecuta un smoke test con parámetros y datos acotados, comprueba estado y contrato, y sólo entonces habilita triggers o tráfico productivo. Usa `bundle summary` y output estructurado para trazabilidad.

databricks bundle validate -t test
databricks bundle plan -t test
databricks bundle deploy -t test
databricks bundle run -t test orders_smoke -- --business_date 2026-07-20

# Tras aprobar evidencia y el plan de prod:
databricks bundle plan -t prod
databricks bundle deploy -t prod

CI debe usar workload identity federation o un service principal con OAuth y permisos limitados al workspace/recursos destino. Los secretos, hosts y client IDs viven en el sistema de CI o perfiles seguros. Un PAT personal tiene ciclo de vida humano, privilegios difíciles de justificar y riesgo de exposición; no es la identidad productiva adecuada.

Construye y prueba la wheel, publica un manifiesto de hash, despliega en test y promueve el mismo artefacto a prod. Protege el ambiente prod con aprobación y branch policy. Prohíbe ediciones manuales de recursos gestionados por bundle o documenta un proceso de importación del cambio, porque el siguiente deploy puede sobrescribir drift.

promotion:
  source_commit: 4f2c9ab
  artifact: orders_pipeline-1.4.0-py3-none-any.whl
  sha256: "<sha256-verificado-en-ci>"
  deploy_identity: sp-data-platform-cicd
  run_identity: sp-orders-prod
  gates:
    - bundle_plan_approved
    - integration_tests_passed
    - rollback_version_recorded

Un recurso creado manualmente puede incorporarse mediante generación o binding según soporte, pero primero hay que decidir quién será su fuente de verdad. Dos bundles no deben gestionar el mismo job. Usa permisos declarados, nombres estables y ownership operativo; revisa el plan cuando cambia la identidad o la ruta raíz porque puede aparentar un recurso nuevo.

Rollback normalmente despliega la última versión conocida del bundle y artefacto, no restaura datos automáticamente. Los cambios de esquema requieren una estrategia compatible hacia delante y hacia atrás. Conserva manifest, plan y resultados de smoke test por release; si un deploy falla a mitad, inspecciona el estado real antes de relanzar.

databricks bundle validate -t prod
databricks bundle plan -t prod
databricks bundle summary -t prod

# Si el job ya existe, documenta ownership y usa el flujo
# de generación/binding soportado en lugar de duplicarlo.