Con la última versión de su software de gestión de cambios para IBM i, Midrange Dynamics ha abordado un problema complejo que afecta al uso de Git en grandes entornos IBM i.
El uso de Git para gestionar el código fuente casi se ha duplicado en la comunidad IBM i en los últimos cinco años, según estudios independientes, alcanzando hasta el 30 %. Esto indica un fuerte impulso para adoptar tecnologías y técnicas DevOps, lo cual es positivo para la comunidad en su conjunto.
Sin embargo (siempre hay un pero), hay algunas cosas en Git que no funcionan igual que en un desarrollo tradicional para IBM i. En cierto modo, las cosas funcionan peor en Git. Pero las ventajas de Git compensan con creces las desventajas, por lo que las empresas que utilizan IBM i deben encontrar la manera de gestionar las diferencias.
Eso es lo que MD está haciendo con MDChange, el software de gestión de cambios para IBM i. El problema radica en el comportamiento de Git en entornos de desarrollo muy grandes, algo habitual en entornos empresariales de IBM i.
Git funciona correctamente con unos pocos cientos de elementos en un repositorio de código individual que se ejecuta en IBM i. El repositorio clonado en IBM i puede comunicarse con el repositorio principal de Git que se ejecuta en una máquina Windows o Linux de forma oportuna. En entornos de programación más pequeños, grupos de desarrolladores pueden extraer fragmentos de código, realizar actualizaciones y confirmar los cambios sin ralentizaciones notables.
Sin embargo, la velocidad empieza a disminuir a medida que aumenta el número de elementos. Para cuando se tienen 50.000 fuentes en el repositorio, este se ralentiza. Según Michael Morgan, director ejecutivo de Midrange Dynamics, no es raro que un programador de IBM i espere hasta ocho minutos para registrar o retirar un elemento de un repositorio local cuando trabaja en estos grandes entornos.
Una forma de adaptarse a esta situación, que no es exclusiva de los entornos de desarrollo de IBM i, es migrar el código de un único repositorio Git monolítico a un mayor número de repositorios más pequeños. Sin embargo, tener el código disperso en varios repositorios puede generar otros desafíos de gestión del código.
La última actualización de MDChange puede ayudar a las empresas con IBM i en cualquier caso, asegurando que el software pueda ayudarles independientemente de la decisión que tomen.
«Si las empresas de IBM i desean mantener un repositorio monolítico, MDChange genera automáticamente varios clones de ese repositorio directamente en la partición de desarrollo del IBM i. Luego, utiliza el balanceo de carga entre múltiples trabajos del servicio MDChange para garantizar que los tiempos de espera de las transacciones se minimicen, especialmente cuando se trabaja en varias ramas de código simultáneamente” , explicó Morgan.
En esta situación, MDChange buscará automáticamente qué rama de Git tiene la cola más corta y le asignará transacciones, garantizando que los desarrolladores obtengan una respuesta mucho más rápida, independientemente del tamaño de los repositorios.
MDChange también puede ayudar a los clientes que desean dividir sus grandes repositorios en una gran cantidad de repositorios más pequeños. El software rastreará automáticamente las dependencias existentes en estos repositorios, lo que permite al cliente continuar desarrollando código sin preocuparse por lo que sucede en segundo plano.
“MDChange realiza automáticamente esa orquestación”, afirmó Morgan. Sabe qué dependencias hay en cada repositorio. Si creas una rama en uno y tienes dependencias en otro, puede crear las ramas automáticamente en los diferentes repositorios, tanto en el servidor remoto, como el servidor de GitHub, como localmente en IBM i, y garantizar que todos los artefactos se extraigan para su implementación en el orden correcto.
Si los clientes optan por dividir lógicamente su código en repositorios más pequeños, MDChange proporcionará balanceo de carga para que todo funcione correctamente. Si sabe que tiene que extraer el código fuente de cinco repositorios diferentes para una función determinada, entonces tendrá cinco tareas de cliente diferentes ejecutándose en segundo plano, realizándolas en paralelo para acelerar el proceso.
Con todo este procesamiento en paralelo, ya sea con repositorios grandes o con muchos repositorios pequeños, se puede trabajar mucho más rápido que con cualquier otro cliente Git desarrollado internamente en i o con productos de otros proveedores, siendo muchísimo más rápido.
Como se mencionó anteriormente, este fenómeno no se limita a Git en IBM i. Cualquier entorno de programación lo suficientemente grande se enfrentará al mismo problema. Git no fue desarrollado para IBM i; es una plataforma universal, y su naturaleza distribuida presenta ciertas diferencias de rendimiento en comparación con los patrones de desarrollo nativos ultrarrápidos y con gran capacidad de respuesta a los que están acostumbrados los programadores de RPG y COBOL en IBM i.
El problema de los archivos grandes ya era ampliamente conocido, pero MDChange no lo había abordado hasta ahora. Esto se debe al creciente interés en el desarrollo basado en Git que está ocurriendo en el ecosistema de IBM i.
«Casi todos los clientes con los que hablamos ahora están considerando al menos cambiar a Git para estandarizar», afirmó Morgan. «Es lo que los desarrolladores conocen al salir de la universidad. Es lo que usan el resto de las divisiones de sus departamentos de TI. Al encontrarnos con esto, y estoy seguro de que es una sorpresa para algunas organizaciones, cuando intentan hacerlo todo a través de Git. Y nosotros lo defendemos. Pero es necesario contar con las herramientas adecuadas para evitar que se convierta simplemente en un punto de apoyo para el equipo de desarrollo».
La otra mejora que MDChange está aportando a las empresas de IBM i que adoptan el entorno Git se refiere al manejo de definiciones personalizadas.
Los entornos de desarrollo de IBM i suelen tener una gran cantidad de objetos, además del código fuente, que deben gestionarse, incluyendo comandos personalizados, scripts, áreas de datos y directorios de enlace. Los desarrolladores suelen dedicar un gran esfuerzo a garantizar que estos objetos exclusivos de IBM i estén donde deben estar.
Sin embargo, estos objetos no se pueden gestionar en Git. Normalmente, esto requeriría que los clientes reconstruyeran manualmente sus entornos con estos objetos en cada etapa del proceso de desarrollo. Pero MDChange puede ayudar a los clientes a gestionar estos objetos a medida que su código fuente pasa del desarrollo a las pruebas y la implementación a través de Git.
Si se ha dedicado tiempo a configurar todo esto en el entorno de la rama inicial, sería un gran riesgo y esfuerzo tener que repetirlo a medida que Git se fusiona con entornos superiores. MDChange rastrea todas las fusiones que se producen en los repositorios de Git desde una rama de características a, por ejemplo, una rama de integración, o desde la integración a una rama de producción. Y como rastrea todo eso, puede revisar qué requisitos de definiciones personalizadas se necesitaban para esa función en particular y luego volver a aplicarlos a los entornos superiores a medida que se implementan automáticamente, para que no se olvide nada. El desarrollador ni el operador que lo implementó no tienen que repetir manualmente ese trabajo.
Traducción y adaptación del artículo original en inglés, escrito por Alex Woodie y publicado en ITJungle
