Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 5 de 5
CI/CD, service principals y approvals
Gestiona drift, ownership, rollback y la migración al motor de despliegue directo GA sin perder la identidad de recursos existentes.
17 min aprox.
05Decisión de diseñoCI/CD, service principals y approvals
Gestiona drift, ownership, rollback y la migración al motor de despliegue directo GA sin perder la identidad de recursos existentes.
+
CI/CD, service principals y approvals
Gestiona drift, ownership, rollback y la migración al motor de despliegue directo GA sin perder la identidad de recursos existentes.
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.
El motor directo está GA y los bundles nuevos con Databricks CLI 1.3 o superior lo usan por defecto. Un deployment antiguo conserva estado Terraform y no debe cambiarse a ciegas: completa primero un deploy con el motor actual, ejecuta `databricks bundle deployment migrate -t <target>` y detente si el plan muestra acciones. La migración convierte IDs al estado `resources.json`; no es un rollback de datos ni autoriza reemplazos. Conserva manifest, plan y smoke test por release.
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.
¿Qué precaución evita duplicar o reemplazar recursos al pasar un deployment antiguo al motor directo?
Profundiza
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.Resumen
Puntos clave
- Un recurso tiene una sola fuente de verdad y un único bundle propietario.
- El motor directo es GA; la migración del estado es una operación explícita.
- Rollback de configuración no revierte side effects de datos.
Evita
- Activar `engine: direct` sobre un deployment antiguo sin migrar y verificar su estado.
- Creer que desplegar la versión anterior revierte filas ya escritas.