16. Sincronizar con APISync y GIT
En esta clase vamos a aprender cómo sincronizar con APISync y GIT nuestra API Specification en local y en la nube. En la clase Fusionar API Spec y Mule App en Anypoint Studio aprendimos a importar la API Specification de AnyPoint Platform a AnyPoint Studio, pero ahora, es necesario saber gestionar las modificaciones realizadas en local para poder publicarlas en el Exchange.
Imaginad que estáis realizando vuestra Mule Application en local, y os dais cuenta de que es necesario aplicar cambios en el RAML que define la API Specification… pues justamente es lo que ha sucedido y en esta clase se explica cómo poder gestionar y aplicar los cambios de forma apropiada.
¿Cómo es posible?
Esto es posible gracias a APISync y GIT, que se encargan de realizar las siguientes acciones:
- PULL: Extraer la API Specification de AnyPoint Platform a AnyPoint Studio, de la nube de Mulesoft a nuestra máquina local.
- EDIT: Permitir la edición de los archivos RAML que contiene la API Specification, pero para ello, se crea una versión local con el mismo nombre y añadiendo al final «master».
- COMMIT: Aplicar los cambios realizados en la API Specification local.
- COMMIT + PUSH: Aplicar los cambios realizados en la API Specification local y en la nube, concretamente en el Design Center.
- PUBLISH: Publicar los cambios realizados en la API Specification local directamente en el Exchange, sin modificar el RAML del Design Center. Siempre se recomienda realizar previamente el paso anterior y probar la API Specification en la nube antes de publicar directamente los cambios.
A continuación, os muestro un diagrama donde podéis observar el orden correcto y cómo funciona la arquitectura de sincronización de versiones.
Quién realiza las acciones es APISync, pero quien las controla es GIT o GIT Staging, un sistema de control de versiones para editar la API Specification en local y enviar los cambios al Design Center (nube), concretamente, el revisor de las acciones COMMIT y PUSH. Por ejemplo, si alguien está modificando una versión en el Design Center y al mismo tiempo alguien lo está haciendo en local, si el segundo quiere subir los cambios, se disparará un mensaje indicando que hay un conflicto entre versiones y se tendrá que llegar a un acuerdo para aplicar uno u otra.
En definitiva, es necesario documentar y versionar todos los cambios que se aplican en una API Specification con tal de seguir una metodología de buenas prácticas en el ciclo de vida del desarrollo de una API. La finalidad es comentar ese código que siempre se deja por comentar y tener ordenada nuestra casa (API).
Si queréis saber más o necesitáis soluciones a medida, podéis suscribiros a mis servicios desde
➡️ AQUÍ ⬅️
Sin más, ¡dentro vídeo!
Clases del curso
- 1. Preparar el entorno de Mulesoft (5:59)
- 2. Portal de APIs Exchange (9:04)
- 3. Importar una API en Anypoint Studio (7:33)
- 4. Importar una API en Anypoint Platform (11:32)
- Punto de Control 1
- 5. Crear Mule Application en Anypoint Platform (10:36)
- 6. Transformando datos en una Mule Application (17:44)
- Punto de Control 2
- 7. Crear una API Specification en Anypoint Platform (11:03)
- 8. Configurar métodos GET y POST de una API Specification (19:22)
- 9. Publicar una API en Anypoint Platform (13:32)
- Punto de Control 3
- 10. Crear una Mule Application en Anypoint Studio con MySQL (14:46)
- 11. Transformar de MySQL a JSON en Anypoint Studio(16:13)
- 12. Crear métodos GET ID y POST en Anypoint Studio (11:02)
- 13. Fusionar API Specification y Mule App en Anypoint Studio (15:30)
- 14. Insertar datos en MySQL con POST en Anypoint Studio (17:00)
- 15. Enrutar Flows entre Mule App y API Spec en Anypoint Studio (5:19)
- 16. Sincronizar con APISync y GIT (7:55)
- Punto de Control 4