Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 29 · Lección

Resources: jobs y pipelines

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu 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.

Duración
17 min aprox.
Objetivo
Define targets dev, test y prod con overrides mínimos, rutas aisladas y modos que expresen claramente la intención de cada ambiente.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Declarative Automation Bundles y CI/CD

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

Al terminar podrás
  • Estructurar un bundle completo
  • Validar y desplegar con CLI
  • Integrar identidad de servicio y pipeline Git
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 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.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m28
Reportar un error en esta lección

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.

Modelo mental

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.
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.

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.

Recuerdo activo

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

Borrador privado · solo en este navegador
5 lecciones pendientes

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