Solucione los problemas de rendimiento en repositorios grandes
Con la última versión de MDChange, su software de gestión de cambios para IBM i, Midrange Dynamics aborda cómo se comporta Git en entornos de desarrollo de gran tamaño, habituales en entornos empresariales IBM i.
Cuando un repositorio contiene unos pocos cientos de elementos, Git funciona perfectamente en IBM i. El repositorio clonado puede comunicarse de forma ágil con el repositorio principal alojado en un servidor Windows o Linux. En estos entornos más pequeños, los equipos de desarrollo pueden realizar check-outs, actualizar el código y hacer commits sin ralentizaciones perceptibles.
El problema aparece cuando el número de elementos crece. Con 50.000 elementos, el rendimiento se desploma. Según Michael Morgan, fundador y CEO de Midrange Dynamics, no es raro que un programador IBM i deba esperar hasta ocho minutos para realizar un check-in o check-out en repositorios locales tan grandes.
Una solución común es dividir un repositorio monolítico en varios repositorios más pequeños. Sin embargo, dispersar el código puede generar nuevos desafíos en la gestión.
1. Manteniendo repositorios monolíticos
Si la empresa decide conservar un repositorio único, MDChange genera automáticamente varios clones de ese repositorio directamente en la partición de desarrollo de IBM i. A continuación, emplea balanceo de carga entre varios procesos de servicio de MDChange para minimizar los tiempos de espera, especialmente cuando se trabajan múltiples ramas simultáneamente.
En este escenario, MDChange evalúa qué rama de Git tiene la cola de espera más corta y asigna las transacciones a esa rama. Esto garantiza a los desarrolladores un tiempo de respuesta mucho más rápido, independientemente del tamaño del repositorio.
2. Dividiendo en repositorios más pequeños
Si la organización opta por fragmentar el código en varios repositorios pequeños, MDChange rastrea automáticamente las dependencias entre ellos. Esto permite que los desarrolladores continúen su trabajo sin preocuparse por la gestión manual de esas relaciones.
MDChange orquesta este proceso de forma automática. Detecta en qué repositorios existen las dependencias. Si crea una rama en uno y existe una dependencia en otro, la herramienta crea las ramas correspondientes tanto en servidores remotos como GitHub, como localmente en IBM i, asegurando que todos los artefactos se integren en el orden correcto durante el despliegue.
Gestión mejorada de definiciones personalizadas en IBM i
Los entornos de desarrollo en IBM i no solo gestionan código fuente: también manejan mandatos personalizados, scripts, áreas de datos y directorios de enlace. Tradicionalmente, estos objetos requerían reconstrucciones manuales en cada fase del desarrollo, lo que era laborioso y propenso a errores.
Con la nueva versión de MDChange, estos objetos se gestionan automáticamente a medida que el código progresa desde el desarrollo hasta las etapas de prueba y producción mediante Git.
Conclusión
El uso de Git en IBM i sigue creciendo, impulsado por la estandarización en las prácticas de desarrollo y las expectativas de los nuevos profesionales del sector. Pero la adopción de Git en entornos grandes sin las herramientas adecuadas puede convertirse en un obstáculo.
Midrange Dynamics aborda estos retos con la última versión de MDChange, que no solo soluciona problemas de rendimiento en grandes repositorios, sino que también facilita la gestión de definiciones personalizadas y dependencias.
Defendemos el uso de Git, pero es fundamental contar con las herramientas adecuadas para que no se convierta en una carga para los equipos de desarrollo.
