Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Variables, substitutions y targets
Usa `validate`, `plan`, `deploy` y `run` como puertas distintas; no conviertas un deploy correcto en prueba suficiente del workload.
- Duración
- 17 min aprox.
- Objetivo
- Usa `validate`, `plan`, `deploy` y `run` como puertas distintas; no conviertas un deploy correcto en prueba suficiente del workload.
- 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.
- Estructurar un bundle completo
- Validar y desplegar con CLI
- Integrar identidad de servicio y pipeline Git
03OperaciónVariables, substitutions y targets
Usa `validate`, `plan`, `deploy` y `run` como puertas distintas; no conviertas un deploy correcto en prueba suficiente del workload.
+
Variables, substitutions y targets
Usa `validate`, `plan`, `deploy` y `run` como puertas distintas; no conviertas un deploy correcto en prueba suficiente del workload.
`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.
Modelo mental
Validate, plan, deploy y run responden preguntas diferentes. Validate comprueba que la configuración compone y referencia elementos válidos; plan muestra el cambio esperado sin aplicarlo; deploy materializa recursos y artefactos; run ejecuta un recurso ya desplegado. Ninguna etapa implica automáticamente la siguiente. Un YAML válido puede describir un cambio destructivo, un despliegue correcto puede contener código defectuoso y un run exitoso puede publicar datos semánticamente erróneos. La entrega robusta coloca evidencia entre transiciones: revisión del plan, aprobación según ambiente, smoke y validación de datos. En el blueprint anterior, estas operaciones aparecen bajo Asset Bundles; en la CLI actual pertenecen a Declarative Automation Bundles y conservan el mismo razonamiento.
Comprobación estática de estructura, tipos, referencias y configuración resuelta para un target antes de modificar recursos remotos.
Detecta errores baratos temprano, aunque no garantiza seguridad del cambio ni corrección del código ejecutado.Representación previa de las acciones que alinearían los recursos reales con la configuración declarada del bundle.
Permite revisar actualizaciones o eliminaciones inesperadas antes de que afecten un ambiente compartido o productivo.Ejecución pequeña posterior al despliegue que confirma arranque, identidad, dependencias y un recorrido crítico del recurso.
Cubre la brecha entre recursos creados correctamente y un workload realmente capaz de operar en ese ambiente.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 prodNo uses `--force` para saltar validaciones de rama como comportamiento normal de CI.
Puntos clave
- Validate comprueba configuración; plan anticipa cambios; deploy aplica; run verifica ejecución.
- Revisa manualmente cambios destructivos antes de desplegar.
- Añade smoke test post-deploy antes de activar producción.
Evita
- Desplegar directamente en prod sin leer un plan que elimina o reemplaza recursos.
- Confundir bundle validado con job funcional sobre datos y permisos reales.
Recuerdo activo