DevOps serie CI/CD en SAP BTP (Parte 9)

Esta es una serie de entradas para configurar y deployar de manera eficiente mediante SAP BTP nuestras aplicaciones.

Llegamos al final de esta serie, espero que os haya interesado. Ya para finalizar y después de todo lo visto esta entrada es una pequeña propuesta de como organizar los transportes. Esto lo podéis tomar como un template si no sabéis por donde empezar. Claro esta que esto cambia en función de las aprobaciones que se requieran o el nivel de confianza que se tenga.

Y ahora… ¿como lo organizamos bien?

Pues llegamos al final de esta serie, ya hemos aprendido a crear y sincronizar nuestro Git, añadir testing a nuestras aplicaciones, crear los MTAR de una manera rápida, ágil y con un versionado y mover el software a los distintos entornos.

Para los que tengáis mas años, llega el momento de hacer nuestro símil entre la SE01 y la STMS y nuestro sistema de despliegue e integración de código.

Git flow

Empezamos en como tenemos que organizar nuestro repositorio. Aquí la respuesta es Git Flow, una propuesta de organización de Git que pertenece inalterable des de hace mas de 10 años.

Antes de seguir, hay que avisar que cada proyecto Git debe ser una sola aplicación y que no es nada recomendable utilizar carpetas para poner distintos proyectos en el mismo repositorio.

Os presento un dibujo de como tiene que ser la organización de las ramas:

Podríamos definirlo por niveles, de menos alterable a mas:

• La rama master, que ahora en GitHub pasa a llamarse rama main, es la mas parecida al código de productivo ya que no es modificable directamente y solo recibe actualizaciones de errores (bugs) y releases (conjunto de desarrollos probados y que están pendientes de subir a productivo)
• En el siguiente nivel tenemos las ramas de hotfixes y release.
  • La primera, hotfixes se crea y se destruye en cada error, es una rama que creamos de la rama master y una vez solucionados los errores la sincronizamos con las ramas de desarrollo y master y la destruimos.
  • La rama de release agrupa todas esas mejoras de que se pactan para antes de la subida a desarrollo. Sobre esta branca podríamos discutir si tiene sentido en un marco de gitops (Si otro nombre para acelerar mas lo que ya hemos acelerado 🙂 ) pero esta rama puede recibir releases cada día si hace falta. En este punto se realizarían las pruebas integradas.
• Seguimos con la rama develop, aquí es donde se van consolidando los distintos códigos del desarrollo y donde se integran para poder realizar las primeras pruebas unitarias.
• Las últimas ramas son las de cada cambio concreto que se defina, las feature branches. Estas ramas se pueden partir a la vez en una rama para cada desarrollador y luego consolidar los distintos cambios en de esa feature concreta.

Y ¿Como vamos de una rama a otra? Pues la respuesta es utilizar pull request en todas las ramas a excepción de desarrollo y features. Esto nos permite tener cierto control para que un revisor sea el encargado de aceptar os cambios de código.

Espero que os haya quedado un poco mas claro, pero ¿por qué se hace todo esto? pues la razón es que necesitamos controlar como y quien va moviendo el software. Así pues, un pull request de la rama release a main solo se podrá aceptar con unas UAT pasadas, mientras que una feature finalizada se podrá pasar a develop por el desarrollador una vez las UT estén finalizadas.

Y ¿Qué hago con SAP Continuous Integration and Delivery y SAP Transport management?

Hemos visto que el servicio de SAP Continuous Integration and Delivery nos permite hacer deploy directamente contra la subcuenta o mandarlo a SAP transport manager.

Aunque podemos jugar como queramos, ya que cada organización es un mundo, mi consejo es utilizar un job para hacer deploy des de la rama develop hacia la subcuenta de desarrollo. Esto evitara tener que dar permisos para desplegar a muchos usuarios, que a la vez implica tener que habilitar los permisos de desarrollo del space, por lo que podemos tener problemas de borrado de instancias por error o despliegue de «porqueria» para pocs.

Una vez tenemos este Job a punto, el siguiente job sera el de transporte a integración. Este lo conectaría a la rama release y su deploy se enviaría al nodo de UAT de nuestro servicio de SAP Tranport management. Ya que así requiere del despliegue mediante aprobación de cola.

Para productivo jugaríamos con dos escenarios:

• El transporte de las releases, que como hemos visto, definiríamos un path de transporte de UAT a Productivo. Una vez pasadas las ultimas pruebas se podría mover todo el software a producción mediante cola.
• El segundo escenario es el de error, este es delicado, porque si se activa es que algo esta mal en productivo. Para este, tendríamos un job dedicado a la rama hotfixes y conectado para hacer el deploy des de SAP Continuous Integration and Delivery hacia nuestra cuenta de desarrollo. Luego para UAT como en el caso anterior pero con paso extra un path dev a uat y de uat a productivo.

Este seria el esquema aplicando GitHub y los dos servicios SAP Continuous Integration and Delivery y SAP Transport management:

Transporte / Entorno	Dev	Uat	Prod
Rama	develop	hotfixes / release	N/A
Transporte	CI/CD deploy directo	CI/CD deploy directo – cierre de release al Nodo UAT	Transporte del Nodo UAT a Prod mediante transport path

---

Y hasta aquí la serie de Devops centrada en CI/CD, si os ha gustado preparé una nueva serie de la parte de monitoring una vez nuestras aplicaciones ya están deployadas.

Como veis, la configuración es relativamente sencilla de montar, y aunque requiere de una pensada inicial y algo de mantenimiento, nos permite controlar accesos, realizar pruebas rápidas y realizar los transportes de una manera controlada.

Tambien he dejado algunos cabos sueltos al mas puro estilo Netflix… como por ejemplo, como transportamos el launchpad en bloque, pero en el momento de escribir esta entrada, el transporte del launchpad en la cuenta trial no esta activo.

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.