Hoy nos complace anunciar que Orchestra ya está totalmente integrado con Azure DevOps («ADO»).
Esto significa que las empresas que están aprovechando Azure ahora pueden construir flujos de trabajo CI/CD totalmente integrados para sus pipelines Orchestra, respaldando su código en ADO.
Combinado con los entornos de despliegue en la nube de Orchestra, líderes en el mercado, esto representa una mejora significativa en la experiencia de los desarrolladores para los flujos de trabajo.
- Los ingenieros pueden gestionar fácilmente múltiples entornos en Orchestra sin tener que pagar por instancias ADF adicionales o gestionar clústeres Airflow adicionales.
- CI / CD para flujos de trabajo de datos se simplifica en gran medida frente a git-acciones a mano entre ADO y Azure Orchestration servicios como ADF o Synapse Analytics Pipelines
- Las empresas obtienen acceso a una pista de auditoría completa a través del historial de confirmaciones a nivel de usuario, que es crucial para satisfacer los requisitos de gobernanza.
Orchestra ya está mejorando drásticamente la productividad de los Data Teams en Azure. Powell Industries ha reducido los tiempos de ciclo en un 50% y, al añadir git-control en Azure, estamos encantados de seguir lanzando funciones que sigan ayudando a los ingenieros a desarrollar más rápido.
Echa un vistazo a los recursos a continuación para obtener más información.
📚 Documentación sobre Azure DevOps
💡 CI/CD con entornos de despliegue en la nube
🛠️ Prueba Orchestra aquí
Si solo dispones de cinco minutos, ¿por qué no comprueba cómo los entornos de despliegue en la nube de Orchestra pueden ahorrarle tiempo y esfuerzo en la gestión de infraestructuras duplicadas?
Tabla de contenidos
¿Qué es Azure DevOps y por qué lo hemos integrado?
Elegimos seguir rápidamente nuestra integración entre Github y Orchestra con Azure DevOps por la única razón de que es un titán en el espacio DevOps.
- El servidor Microsoft Azure DevOps cuenta actualmente con 7469 clientes.
- Microsoft Azure DevOps ha alcanzado los 1000 millones de usuarios en todo el mundo.
- Microsoft Azure es utilizado por el 85% de las empresas Fortune 500.
- Los principales sectores que utilizan Microsoft Azure son el de IT y el minorista.
Aunque gran parte de la nueva funcionalidad con Azure se dirige a Github (como Github Copilot), ADO seguirá siendo utilizado por empresas de todo el mundo y contará con el apoyo de Microsoft.
Azure DevOps se diseñó para ser el conjunto integral de herramientas de desarrollo de Microsoft diseñadas para agilizar la entrega de software, automatizar los flujos de trabajo y mejorar la colaboración entre los equipos de desarrollo.
Aunque se utiliza ampliamente en ingeniería de software, los ingenieros de datos han adoptado cada vez más Azure DevOps para gestionar canalizaciones de datos, controlar versiones de código de transformación de datos y orquestar procesos de integración continua/despliegue continuo (CI/CD) para soluciones de datos.
Para obtener más información sobre cómo los ingenieros utilizan ADO, consulta este hilo de Reddit.
Por qué los ingenieros de datos eligen Azure DevOps
Para los profesionales de datos que trabajan con herramientas como Azure Data Factory (ADF), Synapse Analytics, Databricks y bases de datos SQL, Azure DevOps ofrece una forma estructurada de crear, probar y desplegar canalizaciones de datos al tiempo que garantiza la coherencia, la gobernanza y la colaboración entre equipos. He aquí por qué destaca:
- Control de versiones para canalizaciones de datos: A diferencia de GitHub, que es conocido principalmente por su enfoque de código primero, Azure DevOps se integra perfectamente con Azure Repos, un potente sistema de control de versiones basado en Git. Esto es crucial para el seguimiento de los cambios en las canalizaciones ADF, los scripts SQL y los flujos de trabajo ETL.
- CI/CD para canalizaciones de datos: Azure DevOps permite el despliegue automatizado de pipelines ADF, cuadernos Synapse y actualizaciones de esquemas de bases de datos utilizando Azure Pipelines. Esto significa que los ingenieros de datos pueden trasladar los cambios del desarrollo a la producción de forma fiable, reduciendo los errores manuales.
- Planificación de elementos de trabajo y sprints: La gestión de proyectos de ingeniería de datos a menudo involucra a varios equipos, desde científicos de datos hasta ingenieros de análisis. Con Azure Boards, los equipos de datos pueden organizar los elementos pendientes, realizar un seguimiento del progreso y aplicar las metodologías Agile o Scrum.
- Infraestructura como código (IaC) para servicios de datos: Los equipos de datos que utilizan plantillas Terraform, Bicep o ARM pueden aprovechar las canalizaciones DevOps de Azure para aprovisionar y gestionar la infraestructura de datos basada en la nube de forma repetible y automatizada.
- Seguridad y gobernanza: Para las soluciones de datos empresariales, el control de acceso, la aplicación de políticas y la auditoría son fundamentales. Azure DevOps proporciona control de acceso basado en roles (RBAC) e integración con Azure Active Directory, garantizando el cumplimiento de las mejores prácticas de seguridad.
¿Cómo se compara Azure DevOps con GitHub para la ingeniería de datos?
Aunque tanto Azure DevOps como GitHub soportan repositorios basados en Git y automatización CI/CD, Azure DevOps es generalmente más adecuado para los ingenieros de datos que trabajan dentro del ecosistema de Microsoft.
¿Cuáles son las principales limitaciones de Azure DevOps para las herramientas de datos?
Azure DevOps es una potente plataforma para gestionar proyectos de ingeniería de software y datos, pero cuando se utiliza junto con herramientas de datos modernas como Microsoft Fabric, dbt, Azure Data Factory (ADF) y otros servicios de datos, los usuarios a menudo se encuentran con limitaciones. Estos retos surgen normalmente de las diferencias en cómo se aplican las prácticas DevOps al desarrollo de software frente a la ingeniería de datos.
Limitaciones de Azure DevOps para Microsoft Fabric
- Falta de integración nativa: Fabric todavía está evolucionando, y su integración con Azure DevOps (especialmente para CI/CD) no está tan madura como otros servicios de Azure. Muchos artefactos de Fabric, como Dataflows y Notebooks, aún no tienen soporte de primera clase en Azure Pipelines.
- Soporte limitado de Git: Si bien Fabric admite la integración de Git, la automatización del despliegue a través de Azure DevOps sigue siendo un desafío, especialmente para Lakehouses, bases de datos KQL y pipeline Fabric. A menudo se necesitan soluciones manuales o scripts de terceros.
- Complejidades de seguridad y RBAC: La gestión de permisos y el control de acceso a través de los espacios de trabajo de Fabric pueden ser engorrosos en comparación con las estructuras RBAC tradicionales de Azure DevOps.
Limitaciones de Azure DevOps para dbt
- La integración de pipeline requiere un esfuerzo adicional: A diferencia de dbt Cloud, que tiene funciones de CI/CD integradas, la ejecución de modelos dbt en Azure DevOps requiere secuencias de comandos personalizadas utilizando dbt CLI dentro de Azure Pipelines.
- Desafíos en la gestión del estado: dbt depende en gran medida de artefactos como el archivo manifest.json para realizar un seguimiento de los cambios de estado, pero la gestión de la persistencia del estado en Azure DevOps puede ser compleja, especialmente cuando se ejecutan pipelines en diferentes entornos.
- Limitaciones de orquestación: Azure DevOps Pipelines funcionan bien para CI/CD pero carecen de disparadores basados en eventos que permitirían orquestar modelos dbt de manera eficiente junto con otros pipelines de datos. Muchos equipos acaban utilizando Airflow, Azure Data Factory o Fabric Pipelines en su lugar.
Limitaciones de Azure DevOps para Azure Data Factory (ADF)
- Complejidad del código basado en JSON: Los pipelines de ADF se almacenan como archivos JSON, lo que hace que el control de versiones sea engorroso en comparación con los repositorios de código tradicionales. Fusionar y revisar cambios JSON en pull requests es difícil, ya que carece de legibilidad.
- Sin cambio de rama nativo: ADF tiene integración con Git, pero el cambio de rama puede ser lento y propenso a errores, y a menudo requiere pasos de sincronización manuales.
- Automatización CI/CD limitada: El despliegue de pipelines ADF a través de Azure DevOps requiere plantillas ARM personalizadas o scripts PowerShell, mientras que herramientas como dbt o Synapse proporcionan opciones de despliegue más ágiles.
Retos generales de las herramientas de datos
- Gestión de grandes conjuntos de datos en CI/CD: A diferencia del código de software, los modelos de datos implican grandes volúmenes de datos. Los procesos CI/CD en Azure DevOps no están optimizados para probar o revertir cambios en los datos, lo que dificulta las migraciones de esquemas y el versionado de conjuntos de datos.
- Falta de visibilidad del linaje de datos: A diferencia de herramientas como Unity Catalog, dbt o Purview, Azure DevOps no proporciona un seguimiento integrado del linaje de datos, lo que dificulta el seguimiento del impacto de los cambios de código en los conjuntos de datos.
- Gestión manual de dependencias: Muchos equipos de datos trabajan con SQL, Python, PySpark y Terraform, pero la gestión de dependencias en Azure DevOps no es tan fluida como en los cuadernos Databricks, dbt o Airflow DAGs.
Soluciones y alternativas
Para mitigar estas limitaciones, muchos equipos adoptan enfoques híbridos, como:
- Utilizando GitHub Actions para una mejor automatización CI/CD con dbt, Fabric o ADF.
- Aprovechar Azure Data Factory Triggers o Apache Airflow para una orquestación más flexible.
- Uso de dbt Cloud en lugar de Azure Pipelines para despliegues de modelos dbt.
- Gestionar el linaje de datos y la gobernanza por separado en Microsoft Purview en lugar de Azure DevOps.
Reflexiones finales
Aunque Azure DevOps sigue siendo una herramienta sólida para el control de versiones de nivel empresarial y CI/CD, su soporte nativo para los flujos de trabajo de ingeniería de datos modernos todavía tiene lagunas.
A medida que Microsoft Fabric madura y Azure Data Factory evoluciona, pueden surgir mejores integraciones de DevOps, pero por ahora, muchos equipos de datos dependen de scripts personalizados, orquestadores de terceros como Orchestra y flujos de trabajo alternativos basados en Git para cubrir estas lagunas.