Compilación de una canalización de CI/CD para API Management

Publicado el 6 marzo, 2019

Senior Program Manager, Azure API Management

Las API se han vuelto cotidianas. Se han convertido de hecho en el estándar para conectar aplicaciones, datos y servicios. A grandes rasgos, las API impulsan la transformación digital en las organizaciones.

Con el valor estratégico de las API, una canalización de integración continua (CI) e implementación continua (CD) se ha convertido en un aspecto importante del desarrollo de la API. Permite a las organizaciones automatizar la implementación de cambios de API sin pasos manuales propensos a errores, detectar problemas antes y, en última instancia, entregar valor a los usuarios finales más rápido.

Este blog le guía a través de un marco conceptual para implementar una canalización de CI/CD para implementar a su vez cambios en las API publicadas con Azure API Management.

El problema

Actualmente, las organizaciones suelen tener varios entornos de implementación (p. ej., desarrollo, pruebas o producción) y usar instancias de API Management independientes para cada entorno. Varios equipos de desarrollo, que son responsables de diferentes API con ritmos de lanzamientos distintos, comparten algunas de estas instancias.

Como resultado, los clientes suelen acudir a nosotros con los siguientes desafíos:

  • ¿Cómo se puede automatizar la implementación de las API en API Management?
  • ¿Cómo se pueden migrar configuraciones de un entorno a otro?
  • ¿Cómo se pueden evitar las interferencias entre los diferentes equipos de desarrollo que comparten la misma instancia de API Management?

Creemos que el enfoque descrito a continuación abordará todos estos desafíos.

CI/CD con API Management

Gráfico de flujo de trabajo de CI-CD con API Management

El enfoque propuesto se muestra en la imagen anterior. En este ejemplo, hay dos entornos de implementación: desarrollo y producción. Cada uno tiene su propia instancia de API Management. Un equipo designado, llamado publicadores de la API, administra la instancia de producción. Los desarrolladores de la API solo tienen acceso a la instancia de desarrollo. 

La clave en este enfoque propuesto es guardar todas las configuraciones en plantillas de Azure Resource Manager. Estas plantillas deben guardarse en un sistema de control de código fuente. Usaremos Git como ejemplo. Tal como se muestra en la imagen, hay un repositorio del publicador que contiene todas las configuraciones de la instancia de API Management de producción en una colección de plantillas:

  • Plantilla de servicio: contiene todas las configuraciones de nivel de servicio (p. ej., plan de tarifa y dominios personalizados).
  • Plantillas compartidas: contiene recursos compartidos en toda una instancia de API Management (p. ej., grupos, productos y proveedores de identidades).
  • Plantillas de API: Incluye configuraciones de API y sus subrecursos (p. ej., operaciones y directivas).
  • Plantilla maestra: une todos los elementos vinculando a todas las plantillas.

Los desarrolladores de la API bifurcarán y clonarán el repositorio del publicador. En la mayoría de los casos, se centrarán en las plantillas de API para sus API y no deben cambiar las plantillas compartidas o de servicio.

Al trabajar con plantillas de Resource Manager, descubrimos que existen dos desafíos para los desarrolladores de API:

Una vez que los desarrolladores hayan terminado de desarrollar y probar una API, y hayan generado la plantilla de API, enviarán una solicitud de incorporación de cambios al repositorio del publicador. Los publicadores de la API pueden validar la solicitud de incorporación de cambios y asegurarse de que los cambios son seguros y compatibles. La mayoría de las validaciones se pueden automatizar como parte de la canalización de CI/CD. Cuando los cambios se aprueben y combinen correctamente, los publicadores de la API los implementarán en la instancia de producción. La implementación también puede automatizarse fácilmente con Azure Pipelines.

Con este enfoque, se puede automatizar la implementación de cambios de API en las instancias de API Management y resulta fácil promover cambios de un entorno a otro. Como los diferentes equipos de desarrollo de API trabajarán en diversos conjuntos de plantillas de API, también reduce las posibilidades de interferencias entre los distintos equipos.

Pasos siguientes

Encontrará la guía, ejemplos y herramientas en este repositorio de GitHub. Pruébelo y háganos llegar sus comentarios y dudas.

Sabemos que nuestros clientes traen una amplia variedad de referencias culturales de ingeniería y soluciones de automatización existentes. No se pretende que el enfoque y las herramientas que se proporcionan aquí sean una solución útil para todas las situaciones. Por eso publicamos y convertimos en código abierto todo en GitHub. Así podrá ampliar y personalizar la solución.