Git es una herramienta potente que cada vez adoptan más organizaciones IBM i. En los últimos cinco años, el uso de código fuente gestionado con Git en la plataforma casi se ha duplicado (Fortra’s IBM i Marketplace Study).
Es fácil entender esta tendencia. Git permite gestionar todo el código fuente —incluido el código nativo de IBM i, como RPG— junto a otros lenguajes como Java, PHP o Node.js dentro de un único repositorio. Esto simplifica la gestión del código y facilita enormemente la coordinación entre equipos de TI heterogéneos.
Sin embargo, a medida que Git se va implantando en la plataforma, surge cierta confusión en torno a la gestión de código fuente y la gestión de cambios. Con frecuencia se consideran lo mismo o intercambiables. No lo son. Es esencial comprender las diferencias y utilizar ambas disciplinas para optimizar al máximo tu entorno IBM i.
Gestión de código fuente VS. gestión de cambios
La gestión de código fuente, también conocida como control de versiones, consiste en registrar, almacenar y organizar el código y otros activos digitales. Al permitir que varios desarrolladores trabajen sobre la misma base de código sin sobrescribir el trabajo de los demás, desempeña un papel clave en la colaboración del equipo.
Una herramienta típica de gestión de código fuente, como Git, permite crear ramas para nuevas funcionalidades, fusionar el código de vuelta a la rama principal, etiquetar versiones, resolver conflictos de fusión y mantener un historial detallado de quién hizo qué cambios y cuándo. Registra el trabajo de cada persona para que los equipos puedan colaborar, fusionar cambios y volver a una versión anterior cuando sea necesario. Esa colaboración con historial detallado es la razón de ser de la gestión de código fuente.
De un vistazo…
| Aspecto | Gestión de código fuente | Gestión de cambios |
|---|---|---|
| Registra | Código y versiones del código fuente | Compilación, seguridad, aprobaciones, despliegue |
| Propósito | Colaboración, ramas, reversión, historial del código | Control de riesgos, cumplimiento, programación, auditoría |
| Cuándo se usa | Durante el desarrollo y las pruebas | Durante el desarrollo, las pruebas, el despliegue y producción |
| Fortaleza | Excelente gestionando qué cambió | Excelente gestionando quién aprobó, cuándo se promovió y la compilación de objetos IBM |
La gestión de cambios comparte algunos elementos, pero su propósito es muy diferente. Una solución de gestión de cambios administra las modificaciones de TI mediante un proceso estructurado. Guía a los desarrolladores por la planificación, el desarrollo, la compilación, la seguridad, las aprobaciones y la implantación de esos cambios de forma controlada. El objetivo de la gestión de cambios es reducir significativamente el riesgo, minimizar la interrupción del negocio y asegurar que los cambios valiosos puedan implantarse para favorecer la estabilidad y el crecimiento.
Una herramienta típica de gestión de cambios permite manejar el código fuente y los objetos compilados, la promoción de objetos y sus autorizaciones; proporciona trazabilidad para SOX, PCI o HIPAA; impone aprobaciones antes del despliegue; programa implantaciones para evitar tiempos de inactividad; y automatiza la reversión si surge un problema durante el despliegue. Actúa como una red de seguridad que posibilita actualizaciones periódicas de las aplicaciones de negocio con un riesgo mínimo.
¿Por qué no solo Git en IBM i?
En diferentes conversaciones, el equipo de MDNA ha conocido varios entornos que intentan utilizar Git como si fuese una solución de gestión de cambios. Existen brechas claras entre la gestión de código fuente y la gestión de cambios que hacen que este uso de Git no sea el ideal.
Objeto vs. fuente
IBM i compila el código fuente en objetos. Tener el código solo en Git no garantiza que sepas qué está implantado; es fundamental controlar y documentar el proceso de compilación y enlace que produce los objetos. Una vez creados, los objetos deben asegurarse correctamente. El historial de compilación complementa el seguimiento de auditoría para documentar las aprobaciones y el proceso de promoción.
Riesgo en la implantación
Las reglas de compilación y promoción de objetos —como dependencias o bloqueos de *data areas*—, así como ciertas herramientas específicas de IBM i, no pueden manejarse únicamente con flujos de trabajo puros de Git.
Requisitos normativos
En algunos entornos IBM i, los registros de pruebas y aprobaciones del CAB, separados del historial de *commits* de Git, son obligatorios, lo que hace que la gestión de cambios sea imprescindible para cumplir con las normativas.
Rendimiento lento
Git puede ser muy rápido cuando el repositorio tiene solo unos cientos de elementos. Sin embargo, las aplicaciones en IBM i con código sustancial suelen contener decenas de miles de elementos, lo que puede hacer que las operaciones de Git se ralenticen mucho.
Diferentes pero complementarias
Dado que la gestión de código fuente y la gestión de cambios persiguen propósitos distintos, pero complementarios, en la mayoría de entornos IBM i modernos se considera importante contar con una herramienta para cada disciplina. Hacerlo aporta beneficios significativos.
Prácticas de desarrollo modernas
Con Git, los desarrolladores pueden trabajar con ramas y revisiones entre pares, al tiempo que participan en una canalización CI/CD.
Trazabilidad completa
Puedes ver exactamente qué *commit* de Git se implantó, cuándo se implantó y quién lo aprobó.
Cumplimiento y auditoría
La gestión de cambios eficaz va un paso más allá de los registros de Git y crea informes de auditoría personalizables para ayudar a cumplir los requisitos normativos.
Menos errores
El *branching* de Git protege el desarrollo del código, mientras que las reglas de promoción introducidas por la gestión de cambios reducen el riesgo de desplegar código no probado u objetos mal enlazados o asegurados.
Consistencia entre plataformas
Pocas organizaciones hoy trabajan con una sola plataforma. Es extremadamente útil que IBM i pueda participar en un entorno híbrido con componentes Java, .NET o Node.js.
Estos beneficios pueden marcar la diferencia en los entornos IBM i. Una vez establecidas las razones para utilizar Git junto con una buena herramienta de gestión de cambios, es esencial contar con una solución moderna y específica para IBM i. Los productos heredados no optimizarán tus flujos de trabajo con Git al máximo y a menudo se quedarán cortos. Estas son algunas funciones clave que debes buscar en una solución sólida de gestión de cambios:
- Capacidades de integración
- Gestión de SQL y objetos del IFS
- Referenciación cruzada hasta nivel de campo
- Interfaces/APIs para herramientas externas
- Integración con IDEs modernos
- Comprobaciones previas a la instalación, detección de conflictos y automatización de reversión
- Seguridad y cumplimiento granulares
- Informes detallados y personalizables
Querrás una herramienta de gestión de cambios con este nivel de funcionalidad si de verdad quieres optimizar Git en IBM i.
Una pareja perfecta: la ventaja de MDChange
MDChange es un ejemplo excelente de herramienta moderna de gestión de cambios de Midrange Dynamics. El flujo de trabajo con Git en MDChange está diseñado específicamente para IBM i, optimizando la gestión de repositorios, las pruebas y los despliegues para lograr mayor productividad, flexibilidad y escalabilidad. MDChange potencia el rendimiento con GitHub, GitLab, Bitbucket y Azure Repos, lo que se traduce en ganancias de productividad significativas.
Maximiza la eficiencia de Git para grandes aplicaciones IBM i
Git puede ser increíblemente rápido con unos pocos cientos de elementos en un repositorio. Pero cuando se trata de decenas de miles —algo habitual en aplicaciones IBM i con código muy extenso—, los tiempos de espera durante la creación de una nueva rama pueden ser de minutos.
MDChange permite trabajar con repositorios grandes de forma eficiente o dividirlos en otros más pequeños y manejables. En ambos casos, la clonación es rápida y la experiencia con Git resulta fluida y muy ágil.
Al mantener un único repositorio Git grande, MDChange crea automáticamente múltiples *clones* directamente en el sistema IBM i, utilizando balanceo de carga entre varios *service jobs* para asegurar tiempos de espera mínimos, incluso durante desarrollos concurrentes en múltiples ramas.
Orquesta el desarrollo entre múltiples repositorios Git
Si se trabaja con repositorios más pequeños, MDChange orquesta la creación de ramas, gestiona *merge requests* y controla las dependencias entre repositorios. Así se garantiza que el entorno de destino reciba los artefactos necesarios en el orden correcto. Una vez más, se emplea balanceo de carga para coordinar procesos entre varios *service jobs* y manejar con rapidez los repositorios.
Git destaca en el desarrollo concurrente, pero el desarrollo ágil no está completo sin la capacidad de probar en paralelo. Mientras que los ciclos de desarrollo pueden durar solo unos días, las pruebas pueden alargarse semanas.
Ahí es donde MDChange va un paso más allá. Cuando una *feature branch* se publica automáticamente —por MDChange u otro proceso—, MDChange crea al instante bibliotecas y carpetas del IFS basadas en la rama, utilizando patrones de nombres personalizados. Población de datos, compilaciones continuas de los cambios e inclusión de dependencias que residen fuera de Git: todo queda automatizado.
Si surge algún problema, los desarrolladores pueden modificar el código directamente en IBM i. MDChange rastrea esos cambios y los sincroniza con el repositorio, asegurando que todo se mantenga actualizado.
Conservación transparente de scripts y objetos personalizados
A medida que el proyecto evoluciona, es cada vez más importante conservar comandos, scripts y objetos no gestionados en Git a través de los distintos entornos.
Por ejemplo, al fusionar una *feature branch* en una rama de integración, MDChange se asegura de que todos los objetos y definiciones personalizados de los entornos inferiores se incluyan automáticamente en el conjunto de despliegue del entorno de destino. Es una transición fluida que mantiene todo funcionando en armonía.
Despliegues simplificados y granulares a producción
Tanto si el conjunto de despliegue proviene de la fusión de varias ramas como de una única *feature branch*, MDChange facilita ejecutar despliegues granulares a producción o dividir conjuntos específicos según funcionalidades u otros criterios. Estos conjuntos pueden enviarse a varias particiones de prueba o producción en momentos programados, dando al equipo flexibilidad para implantaciones dirigidas y sensibles al tiempo.
Gestión flexible de repositorios
Ya se trabaje con repositorios grandes o se dividan en otros más pequeños, MDChange ofrece la máxima eficiencia.
Balanceo de carga automático
MDChange utiliza balanceo de carga entre *service jobs* para minimizar los tiempos de espera en las transacciones, incluso durante desarrollos de alto volumen con múltiples ramas.
Pruebas concurrentes sencillas
Automatiza bibliotecas basadas en ramas, creación de carpetas en IFS, población de datos y compilación continua para acelerar las pruebas en paralelo, independientemente de la complejidad.
Conservación de objetos personalizados entre entornos
Realiza el seguimiento y despliegue automático de scripts, comandos y objetos no procedentes de código fuente a medida que los desarrolladores avanzan entre desarrollo, integración y producción.
Despliegues granulares y flexibles
Divide fácilmente los conjuntos de despliegue por funcionalidades u otros criterios, habilitando implantaciones dirigidas y sensibles al tiempo en múltiples particiones de prueba o producción.
Gestión de bases de datos
MDChange maneja cambios en ficheros de base de datos, identifica ficheros y dependencias de objetos, asegura la repoblación correcta de datos, reconstruye rutas de acceso (*access paths*), restablece la *journaling* y gestiona *triggers*. Con MDRapid, puedes minimizar el tiempo de inactividad y el riesgo, haciendo posible realizar cambios en ficheros grandes de manera rápida y sencilla.
Aprovechar la potencia de IBM i con herramientas de gestión de código y de cambios
Al combinar las fortalezas complementarias de Git para la gestión de código con una solución de gestión de cambios específica para IBM i como MDChange, las organizaciones obtienen lo mejor de ambos mundos: desarrollo rápido y colaborativo y despliegues seguros y controlados. Este enfoque dual permite adoptar prácticas DevOps, mantener el cumplimiento normativo completo y mantener sincronizados los entornos de desarrollo y producción sin sacrificar rendimiento ni fiabilidad. En el entorno actual, esto es imprescindible para las organizaciones IBM i que quieran mantenerse ágiles, competitivas y preparadas para el futuro.
Acelerar el cambio y la integración en IBM i
Organizaciones IBM i, grandes y pequeñas, confían en el software y los servicios de Midrange Dynamics North America para evolucionar sus estrategias de TI mientras aumentan la productividad. Con las soluciones integradas de Midrange Dynamics, puedes implantar canalizaciones DevOps y CI/CD, analizar aplicaciones, automatizar pruebas unitarias, minimizar tiempos de inactividad y crear APIs REST. Puedes alcanzar tus objetivos de gestión de cambios, modernización de aplicaciones y CI/CD en plazo y dentro del presupuesto. Tanto si estás empezando como si careces de actualizaciones de software, soporte ágil y tarifas razonables con tu proveedor actual, podemos ayudarte. Las décadas de experiencia de nuestro equipo te facilitarán construir excelentes aplicaciones.
Traducción y adaptación de artículo escrito por Anna Marrah de Midrange Dynamics y publicado en mcpressonline.com
