Saltar al contenido

CI/CD

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 2 de 5

Resources: jobs y pipelines

Define targets dev, test y prod con overrides mínimos, rutas aisladas y modos que expresen claramente la intención de cada ambiente.

17 min aprox.

Detalles

Declarative Automation Bundles y CI/CD

Define recursos como código y promociona el mismo artefacto validado entre targets.

Reto observable

Promociona el mismo artefacto mediante un bundle, conserva plan y hash, y demuestra smoke test, identidad de ejecución y rollback documentado.

Al terminar podrás
  • Estructurar un bundle completo
  • Validar y desplegar con CLI
  • Integrar identidad de servicio y pipeline Git
Prerrequisitos
m28
Última revisión
25 ago 2026
Nivel
Professional
Ruta relacionada
delivery
Dominios blueprint
Deploying CI/CD · Databricks CLI
Estado
Revisión editorial interna
Fuentes principales
What are Declarative Automation Bundles? · Bundle command group
Reportar un error
02
Implementación

Resources: jobs y pipelines

Define targets dev, test y prod con overrides mínimos, rutas aisladas y modos que expresen claramente la intención de cada ambiente.

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.

YAMLTargets con variables y modos
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}

Declara `prod_run_as` por un canal seguro de configuración; no pegues credenciales ni un ID de usuario personal.

¿Por qué `run_as` debe separarse del usuario que ejecuta `bundle deploy`?

Profundiza

Un target no es una copia completa del proyecto, sino una transformación controlada de una base común. La configuración compartida expresa lo que debe permanecer idéntico; los overrides declaran sólo diferencias legítimas como workspace, identidad, catálogo, schedule o escala. Los modos development y production añaden comportamientos convencionales y guardrails, pero no reemplazan una revisión explícita de cada diferencia. El aislamiento usa root paths, schemas y nombres que impiden colisión entre desarrolladores o ambientes. Si cada target contiene una segunda definición completa, el drift queda incorporado al diseño. Si no hay ninguna diferencia, producción puede heredar rutas o permisos de desarrollo. La meta es minimizar variación sin fingir que seguridad y capacidad son iguales.

Target

Configuración nombrada que selecciona workspace, modo, variables y overrides para desplegar el mismo proyecto en un ambiente concreto.

Permite promoción repetible sin mantener copias divergentes de código y recursos para desarrollo, test y producción.
Override mínimo

Diferencia explícita limitada a aquello que realmente cambia entre ambientes, heredando el resto desde una base compartida.

Reduce drift y hace visible qué propiedades productivas no fueron ejercitadas de forma equivalente en test.
Root path

Ruta de workspace usada por el bundle para almacenar archivos y estado desplegados bajo una identidad y target.

Un diseño único por ambiente o desarrollador evita colisiones, sobrescrituras y ownership ambiguo entre despliegues.
Resumen

Puntos clave

  • Una base común reduce drift; targets sólo expresan diferencias reales.
  • Aísla rutas y nombres de desarrollo por usuario/target.
  • Separa deployment identity de `run_as` del workload.

Evita

  • Copiar el job entero dentro de cada target y permitir que sus DAG diverjan.
  • Ejecutar producción como el desarrollador que lanzó el deploy.

Fuente revisada · vista externa

bundle-examples

bundle-examples · commit c1db792

default_python/src/sample_notebook.ipynb

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Databricks
Licencia
Databricks License
Formato
bundle
Ver notebook en GitHub ↗

Módulo 29

Contenido del módulo