Skip to main content

¿Cómo automatizar el diseño e implementar CI/CD en entrega y distribución de tus API?

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (4 votos, promedio: 4,75 de 5)
Cargando…

En la distribución continua de API, tenemos que tener en cuenta que existen distintas fases: creación, diseño y publicación.

En este post, además de incluir la automatización de la creación de las API, incluimos como automatizar la fase de diseño haciendo uso de MAVEN, GitLab, Jenkins y un editor de desarrollo Swagger, sin olvidarnos del componente principal: “El API Manager”, donde publicaremos y promocionaremos nuestra API.

En la siguiente imagen se detallan los elementos, de los que haremos uso:

               

¿Cómo podemos implementar una solución?

A continuación, se detallaran los pasos a realizar para la distribución y entrega continua:

  1. Distribución

El flujo sería el siguiente:

  • Creación

 

Ejecutaremos un Jenkins que construya a través de Maven el arquetipo del proyecto, de esta manera tendremos el esqueleto para que el desarrollador pueda hacer el clone y empezar a trabajar.

Para la parte de creación de las API disponemos de un fichero Json dónde se especificarán los campos que requerimos.

A continuación un ejemplo:

Tras la construcción del fichero podríamos hacer un push de la solicitud a un repositorio GitLab, por ejemplo:

Configurando un webhook a Jenkins podríamos ejecutar el Job que previamente hayamos construido, en este caso API_Create, ejecuta un Python, que es capaz de interpretar el contenido del fichero y hacer una llamada a las API internas del API Manager de WSO2.

Desencadenando en Jenkins la llamada a un script que ejecuta un módulo en Python:

El resultado del Job seria:

Con la consiguiente creación de la API en el Publisher del API Manager obteniendo el siguiente resultado:

  • Diseño

Para la parte de diseño, podemos aprovechar el proyecto Swagger  y realizarlo desde el Editor. Recomendamos esta Devtool ya que está muy estandarizada y es Open Source; esta proporciona un editor con visor On-line para una mejor visión del diseño.

Como las librerías API internas del API Management aceptan JSON, necesitamos convertir el YAML del Swagger para podernos comunicar con WSO2, con una instrucción Python es fácil de conseguir.

Una vez obtenido la definición Swagger en formato JSON tendríamos que hacer una Update Definition desde Jenkins (podemos utilizar el mismo script y Job u otro), mediante una petición HTTP Rest, incluyendo en el campo APIDefinition el contenido mencionado anteriormente de la siguiente forma:

Hasta aquí ya tendríamos la construcción y el diseño de nuestra API, integrados con GitLab y Jenkins. Cualquier Push posterior en la rama podría hacer uso de otro Job que implementemos para actualizar la definición de nuestra API. 

 

  • Entrega continua

 

Esta fase cubre el escenario de promoción de API, entre entornos de nivel inferior con el extra de poder incluir pruebas adecuadas.

Una vez que las API se crean en el entorno de desarrollo, puede haber una tarea de automatización periódica o actividad de forma manual que lea los detalles de la API, los crea o actualice en el siguiente entorno y si se cree oportuno, ejecute pruebas de API en el entorno del nivel superior, para asegurarse de que el interfaz no se rompe por los cambios introducidos en la propagación.

El flujo sería el siguiente:

La lógica aquí es sencilla:

La lista de API se recupera de Desarrollo

Para cada API recuperada, la definición de la API también se recupera de Desarrollo

Para cada API, su existencia se verifica en el entorno de Testy, según el resultado se realiza una solicitud de CREAR o ACTUALIZAR el API en el nuevo entorno de Test.

En la siguiente imagen se muestra el entorno de Desarrollo con la API a promocionar:

Ejecutamos el Job de Jenkins para promocionar la API al entorno de Test:

En el Publisher vemos que el entorno está inicialmente vació.

Una vez ejecutado el Job, comprobamos la ejecución correcta en la consola del Jenkins.

Después de la ejecución comprobamos la publicación de nuestra API en el entorno de TEST

Y comprobamos que se ha publicado correctamente en el APIM Publisher de TEST

NOTA: Es importante tener en cuenta dos cosas, la obtención del token de acceso según scope (creación de API) y la obtención del ID de API tras la creación, para su posterior actualización con el diseño.

Conclusiones

Mediante la implementación de CI/CD contribuimos a minimizar errores en la creación y a simplificar las tareas de nuestro equipo de operaciones. Hay varios enfoques cuando se trata de adoptar CI/CD, hay numerosas variantes, incluso en el ejemplo podemos hacer la creación primero y posteriormente el diseño, o realizar ambas cosas en un único paso (Push). En este ejemplo mediante el uso de arquetipos Maven hemos creado la estructura de nuestros proyectos de API en el GitLab y mediante los Jobs creados en el Jenkins, hemos publicado y promocionado las API en nuestro WSO2 API Manager. Haciendo uso de los elementos que hemos utilizado se pueden construir distintas soluciones que más se adapten a las necesidades de tu organización.

 

Marcos Martinez Hernandez

Marcos Martinez Hernandez

Marcos Martinez Hernandez ha escrito 1 entradas


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.