Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 4 de 5
validate, deploy y run
Autentica CI con OAuth y aplica promoción por ambientes sin tokens personales, rebuilds ni edición manual del workspace.
- Duración
- 17 min aprox.
- Objetivo
- Autentica CI con OAuth y aplica promoción por ambientes sin tokens personales, rebuilds ni edición manual del workspace.
- 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
04Diagnósticovalidate, deploy y run
Autentica CI con OAuth y aplica promoción por ambientes sin tokens personales, rebuilds ni edición manual del workspace.
+
validate, deploy y run
Autentica CI con OAuth y aplica promoción por ambientes sin tokens personales, rebuilds ni edición manual del workspace.
CI debe usar workload identity federation o un service principal con OAuth y permisos limitados al workspace/recursos destino. Los secretos, hosts y client IDs viven en el sistema de CI o perfiles seguros. Un PAT personal tiene ciclo de vida humano, privilegios difíciles de justificar y riesgo de exposición; no es la identidad productiva adecuada.
Construye y prueba la wheel, publica un manifiesto de hash, despliega en test y promueve el mismo artefacto a prod. Protege el ambiente prod con aprobación y branch policy. Prohíbe ediciones manuales de recursos gestionados por bundle o documenta un proceso de importación del cambio, porque el siguiente deploy puede sobrescribir drift.
Modelo mental
CI es un actor de producción y debe tener identidad propia. OAuth para un service principal entrega credenciales renovables o de corta duración y separa claramente automatización de una persona; un personal access token ata continuidad, auditoría y revocación al usuario que lo creó. La promoción no significa reconstruir: CI toma el artefacto cuyo hash superó pruebas, autentica contra el target y aplica sólo permisos de despliegue y ejecución requeridos. Separar identidades por ambiente limita blast radius, aunque una organización puede optar por un principal común con acceso explícito cuando su modelo lo justifica. En ambos casos, los secretos viven en el proveedor de CI y nunca en databricks.yml, logs o wheel.
Flujo de autorización máquina a máquina mediante el cual un service principal obtiene tokens sin depender de una sesión humana.
Mejora rotación, continuidad y atribución de CI frente a credenciales personales de larga duración.Identidad no humana gobernada que representa una aplicación o automatización y recibe permisos explícitos en cada workspace.
Separa responsabilidad del pipeline respecto a usuarios y permite mínimo privilegio, auditoría y revocación independientes.Movimiento del mismo artefacto probado entre ambientes sin reconstruir ni modificar sus bytes durante el proceso.
Garantiza que la evidencia de test corresponde exactamente al código que finalmente alcanza producción.promotion:
source_commit: 4f2c9ab
artifact: orders_pipeline-1.4.0-py3-none-any.whl
sha256: "<sha256-verificado-en-ci>"
deploy_identity: sp-data-platform-cicd
run_identity: sp-orders-prod
gates:
- bundle_plan_approved
- integration_tests_passed
- rollback_version_recordedEl fichero ilustra evidencia; las credenciales se obtienen por OAuth y nunca se escriben en el manifiesto.
Puntos clave
- CI usa OAuth y service principal de mínimo privilegio.
- El mismo hash atraviesa test y producción.
- Los recursos declarativos no se editan manualmente sin reconciliar código.
Evita
- Reutilizar un PAT de administrador para todos los workspaces.
- Volver a construir el paquete en cada ambiente y perder identidad del artefacto.
Recuerdo activo