Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
Unit, integration y smoke tests
Convierte calidad en una puerta de promoción: formato, tipos, unit tests, integración, seguridad y contrato del artefacto.
- Duración
- 17 min aprox.
- Objetivo
- Convierte calidad en una puerta de promoción: formato, tipos, unit tests, integración, seguridad y contrato del artefacto.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
Proyectos Python, dependencias y pruebas
Convierte notebooks en un paquete comprobable con límites claros y entornos reproducibles.
- Diseñar un paquete Python modular
- Gestionar wheels y dependencias
- Probar DataFrames y contratos
05Decisión de diseñoUnit, integration y smoke tests
Convierte calidad en una puerta de promoción: formato, tipos, unit tests, integración, seguridad y contrato del artefacto.
+
Unit, integration y smoke tests
Convierte calidad en una puerta de promoción: formato, tipos, unit tests, integración, seguridad y contrato del artefacto.
Una pipeline CI debe fallar pronto: lint y type check, tests unitarios, build de wheel, escaneo y validación del bundle. La integración se ejecuta con una identidad no humana y permisos mínimos en un target efímero o compartimentado. Conserva reporte de tests, hash del artefacto y commit para reconstruir la decisión de despliegue.
Los secretos pertenecen al proveedor de identidad o al gestor de secretos del CI; prefiere OAuth workload identity/service principal a PAT de usuario. La promoción a producción requiere que el mismo artefacto superado sea referenciado por la configuración prod. Añade rollback a la versión anterior y una comprobación post-deploy antes de dirigir triggers reales.
Modelo mental
Una puerta de promoción es una política de riesgo automatizada. No intenta demostrar que el software es perfecto; exige evidencia proporcional antes de permitir que el mismo artefacto avance. El orden suele ir de barato a costoso: formato y lint, tipos y seguridad, unit tests, build, contract tests e integración. Fallar pronto ahorra capacidad y ofrece feedback concreto. La puerta también valida el artefacto y la configuración que se desplegarán, no sólo el branch. Cobertura porcentual no sustituye casos relevantes y un scan sin política de severidad genera ruido. Las excepciones son decisiones explícitas, con responsable y caducidad, nunca un clic sin registro para saltar una señal incómoda. En automatización Databricks, el nombre vigente es Declarative Automation Bundles; Asset Bundles es el alias que todavía aparece en el blueprint Professional de 2025.
Condición automatizada y auditable que exige evidencia definida antes de mover un artefacto al siguiente ambiente de entrega.
Convierte estándares en comportamiento consistente y evita que presión temporal elimine silenciosamente pruebas críticas.Resultados, hashes, reportes y metadatos que vinculan un commit con el artefacto exacto y las verificaciones ejecutadas.
Permite demostrar qué se probó y evita promover bytes distintos de los que recibieron aprobación.Ruta excepcional y controlada para omitir temporalmente una barrera bajo autorización, registro y seguimiento obligatorios.
Permite responder a emergencias sin convertir la excepción en un bypass cotidiano invisible y permanente.quality_gates:
- name: unit
command: pytest -m "not integration"
- name: build
command: python -m build
- name: bundle_validate
command: databricks bundle validate -t test
- name: integration
command: pytest -m integration
- name: artifact_manifest
command: sha256sum dist/*.whlAdapta el sintaxis al CI elegido; el principio importante es que prod use el hash que superó estas puertas.
Puntos clave
- Falla rápido antes de consumir compute remoto.
- CI usa identidad no humana y mínimo privilegio.
- Firma la promoción con commit y hash del artefacto.
Evita
- Usar el PAT personal de un desarrollador y perder el pipeline cuando cambia de equipo.
- Desplegar desde la rama local después de que CI probó otro commit.
Recuerdo activo