Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
CI/CD, service principals y approvals
Gestiona drift, ownership, permisos y rollback como parte del bundle para que un despliegue sea reversible y auditable.
- Duración
- 17 min aprox.
- Objetivo
- Gestiona drift, ownership, permisos y rollback como parte del bundle para que un despliegue sea reversible y auditable.
- Siguiente paso
- Continuar con el laboratorio
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
05Decisión de diseñoCI/CD, service principals y approvals
Gestiona drift, ownership, permisos y rollback como parte del bundle para que un despliegue sea reversible y auditable.
+
CI/CD, service principals y approvals
Gestiona drift, ownership, permisos y rollback como parte del bundle para que un despliegue sea reversible y auditable.
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.
Modelo mental
El estado declarado, el estado desplegado y el estado que realmente ejecuta producción pueden divergir. Drift aparece cuando alguien edita un recurso fuera del bundle, otra automatización comparte ownership o una referencia externa cambia. El bundle necesita una frontera de propietario: un recurso tiene una fuente de verdad y una identidad autorizada a modificarlo. Permissions también son configuración y deben evitar que el deploy se quite a sí mismo acceso o conceda control excesivo. Rollback no siempre es aplicar el commit anterior: código, schema y datos pueden haber evolucionado. Una estrategia reversible conserva artefactos, planes, compatibilidad hacia atrás y procedimientos para detener, redeployar o avanzar con una corrección.
Diferencia entre la configuración versionada que se considera deseada y el estado real modificado por personas o automatizaciones externas.
Hace que despliegues sean impredecibles y puede reintroducir cambios manuales, permisos incorrectos o recursos huérfanos.Regla que asigna una única fuente de verdad y responsables autorizados para gestionar cada recurso desplegado.
Evita que dos sistemas compitan por el mismo objeto y sobrescriban mutuamente su configuración.Estrategia de cambio que añade primero compatibilidad nueva, migra consumidores y retira después la forma anterior.
Mantiene una ventana donde versiones adyacentes funcionan y hace viable rollback sin revertir datos destructivamente.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.No ejecutes binding a ciegas: confirma que ningún otro bundle o proceso gestiona ese recurso.
Puntos clave
- Un recurso tiene una sola fuente de verdad y un único bundle propietario.
- Rollback de configuración no revierte side effects de datos.
- Revisa plan y estado real antes de reparar un deploy parcial.
Evita
- Crear un job duplicado porque cambió `root_path` o la identidad del bundle.
- Creer que desplegar la versión anterior revierte filas ya escritas.
Recuerdo activo