En este momento estás viendo SAP DevOps PPNT: Parte 2 – Gestión del código

SAP DevOps PPNT: Parte 2 – Gestión del código

Volvemos a ver el tema de DevOps para personas no técnicas. Esta vez, vamos a ver la gestión del código con Git y sus versiones.

En el desarrollo tradicional de SAP (que todavía sigue existiendo y le quedan unos años aún), cualquier nuevo programa o modificación hecha por el desarrollador va dentro de una orden de transporte. Ese programa puede recibir varias modificaciones de diferentes programadores. Seguramente (lo he visto varias veces), los programadores utilizan el mismo usuario desarrollador, con lo que detectar uno de los cambios puede ser complejo (si utilizan comentarios para marcar el cambio y el uso de nombres o iniciales, puede hacerlo más fácil). El problema del sistema tradicional, es que podemos pasar cambios no aprobados/testeados a producción sin darnos cuenta y todos sabemos que pasa en ese momento… (empiezan los estados de nervios). Es aquí donde percibimos que necesitamos poder gestionar los cambios.

Con la aparición de SAP Fiori, SAP Cloud Platform, etc… nos llega la gestión del código integrada en SAP Web IDE. Ahora podemos crear proyectos de SAPUI5 y conectarlos a un repositorio Git.

¿Qué es Git?

Pues como dice la wikipedia, Git es un software para gestionar las versiones de diferentes archivos (al final, nuestro código va en diferentes tipos de archivos, por ejemplo json, js, xml, html, etc…) y así poder tener el mantenimiento de nuestro programas con versiones de una forma integra.

Con Git, podemos tener diferentes ramas donde gestionar el código. En cada rama podemos tener una versión del código e ir haciendo evolucionar nuestros programas según las necesidades. Por ejemplo, podemos tener (es una estructura básica para empezar con Git):

  • Rama de desarrollo: En esta rama es donde principalmente podemos tener el código para evolucionarlo.
  • Rama hotfix: Aquí podemos tener el mismo código que en producción y nos sirve para solventar diferentes issues que aparezcan. Luego estas modificaciones se deben añadir en la rama de desarrollo (hacer un merge del código) para tenerlos presentes en el deploy del nuevo código.
  • Rama master: Esta rama es la que debe contener el código que va a producción. Aquí se irá haciendo merge de todas las nuevas funcionalidades estables que se vayan desarrollando.

Pero las ramas no sólo nos indican el «entorno». Podemos utilizar las ramas de Git también por programador y que cada programador evolucione su funcionalidad hasta unirla con la rama de desarrollo. Como veis, la forma de estructurar las ramas depende de las necesidades de cada proyecto/usuario.

Git nos permite una gran flexibilidad para poder evolucionar nuestro código y que el día a día sea más sencillo. Más adelante veremos porque es importante la utilización de Git para procesos de continuous integration y continuous delivery.

Git se integra en muchos entornos de programación, entre ellos nuestro queridísimo SAP Web IDE. Si todavía seguís en el abap tradicional y no habéis dado el paso a probar las funcionalidades web, podéis instalar en SAP el ABAPGit que permite integrar Git en el ERP.

¡Y hasta aquí el post de hoy de la serie DevOps PPNT! Recuerda que cualquier duda, ¡me puedes contactar!

Deja una respuesta