Una guía completa para entender, implementar y utilizar Git en el IBM i (AS400 – iSeries), optimizando y escalando el proceso de desarrollo colaborativo por medio de ARCAD Software. Útil para líderes de proyectos, project managers, desarrolladores, así como directores o gerentes que busquen implementar y explotar el poder DevOps en el IBM i con control de versiones.
A estas alturas del partido parece un poco innecesaria la presentación de Git. Está claro que es una herramienta fundamental para los desarrollos colaborativos de forma eficiente, hoy en día incluso saber utilizarlo es una habilidad esencial para cualquier programador que quiera entrar al mundo profesional del desarrollo de software.
Git simplifica todo el proceso de desarrollo colaborativo y trae agilidad a los equipos de desarrollo en diferentes niveles; disminuyendo los riesgos que implica manipular código por diferentes mentes y habilidades. Son muchas las funciones que tiene Git, pero las más importantes a destacar es la posibilidad de:
En el universo del open source y los entornos híbridos, Git es el estándar de la industria. Sin embargo, para los sistemas IBM i la historia es un poco diferente.
La flexibilidad de Git contrasta con el enfoque ‘pesimista’ de las herramientas tradicionales para gestión de cambios en el IBM i. Estas herramientas bloquean el código cuando un programador trabaja en una aplicación, y si se cuentan con aplicaciones monolíticas, la rigidez y complicaciones del proceso de desarrollo son aún peores. Es la diferencia de trabajar con un repositorio distribuido a comparación de uno centralizado.
No obstante, Git ‘crudo’ no tiene conocimiento respecto al IBM i y no es capaz de lidiar con las diferentes variantes de los lenguajes en la plataforma. Para utilizarlo en IBM i correctamente, Git requiere automatización e inteligencia adicional para poder lidiar con las particularidades de la plataforma (ej. objetos sin fuentes).
En los siguientes puntos exploraremos los beneficios de Git a comparación de las herramientas tradicionales explicadas anteriormente, los pasos para implementarlo exitosamente, y cómo los módulos de ARCAD pueden simplificar el uso de Git en el IBM i.
En la comunidad profesional del IBM i, la mayoría de los proyectos de desarrollo se han manejado bajo la metodología de cascada (waterfall) mientras se utilizaba RPF de formato fijo (RPG Fixed). Sin embargo, el cambio hacia metodologías ágiles no es un impedimento para el IBM i a pesar de sus particularidades.
La adopción de un control de versiones como Git nos permitirá adoptar la metodología ágil denominada DevOps, este cambio de paradigma brindará agilidad a los desarrolladores para estar haciendo liberaciones de software de forma continua. Liberaciones más pequeñas, a comparación de una metodología de cascada, pero con mucho mayor frecuencia y seguridad.
Una metodología ágil fortalece las relaciones entre los integrantes de los equipos de desarrollo, disminuyendo curvas de aprendizaje y eficientizando procesos a todos los niveles; desde programadores expertos hasta nuevos en la plataforma. Adicionalmente, el entendimiento y compromiso de los programadores respecto al negocio y el uso de sus aplicaciones también aumenta .
El uso de Git en el IBM i facilita la integración de aplicaciones modernas y populares en el open source tales como Github, Jenkins, Jira, entre otras que forman parte del ecosistema DevOps. Integrando en el proceso de desarrollo action items, tareas y tickets que marcan la pauta de los trabajos a realizar en las ramificaciones de Git, nuestro proceso de desarrollo se vuelve más sólido al momento de modificar aplicaciones de gran tamaño en la compañía.
Por otro lado, el aislamiento de las ramificaciones en Git aumenta la facilidad para gestionar y controlar los cambios en los aplicativos. Además de elevar la seguridad de nuestro ecosistema productivo ya que las pruebas son más fáciles de realizar, disminuyendo los riesgos de romper alguna aplicación en producción por no hacer un proceso de pruebas pertinente.
Git ofrece varias opciones de ramificación para trabajar, como Gitflow, Trunk-Based y Feature-Release. Cualquiera que sea la forma en que decidas usar Git, los métodos te permiten entregar software en ciclos de desarrollo más rápidos, lo que significa que los cambios pueden ser probados y revisados sin retrasar o poner en riesgo otros flujos de desarrollo.
Se disminuye o elimina el tiempo de inactividad o tiempo muerto de los equipos de desarrollo. Con Git, los desarrolladores no tienen que esperar a que se complete alguna ramificación o un cambio de código concurrente antes de poder avanzar con su ciclo de desarrollo, y la gran mayoría de conflictos que solían ocurrir se resuelven “automáticamente” con Git.
Los desarrolladores tendrán la flexibilidad de tomar una solicitud de corrección urgente, crear rápidamente una nueva rama de corrección en Git, realizar cambios, confirmar código fuente, probar los cambios, probar toda la rama de corrección y luego implementarla sin problemas, todo esto sin afectar tu desarrollo actual.
Si la corrección es crítica, es posible utilizar un proceso de corrección urgente y liberar la corrección directamente en producción. De cualquier manera, si existe algún conflicto, esto se puede fusionar en cualquier rama activa a través de las funciones de fusión dentro de Git para asegurar que la corrección no se pierda en la siguiente implementación.
Git es, en esencia, la clave para adoptar un proceso de desarrollo moderno; empodera a tus desarrolladores y aumenta la productividad al automatizar el ciclo de desarrollo con flujos de trabajo personalizables y control de versiones distribuido.
Sin más vuelta, Git es elevar tu proceso de desarrollo al siguiente nivel. A continuación hablaremos de los pasos que recomendamos llevar a cabo para una implementación exitosa en el IBM i y los equipos involucrados.
Git proporciona acceso a algunas herramientas excelentes para permitirnos desarrollar a velocidad; y si bien puedes simplemente pasar directamente a Git, el proceso de implementación también es una oportunidad ideal para analizar y eliminar parte de la deuda técnica en las aplicaciones nativas del IBM i. Seamos honestos, el sistema lleva décadas activo, las posibilidades de encontrar código obsoleto y mal documentado son altísimas.
Y aquí también tenemos que hablar un poco de las fricciones que puedan surgir a partir de estos análisis. A nadie le gusta que los ‘exhiban’ cuando la casa está sucia, es normal que personas que llevan años en la compañía sean renuentes a la exposición de malos procesos de desarrollo que se tuvieron por tanto tiempo. Es responsabilidad de las gerencias gestionar estos casos con inteligencia, los proyectos de limpieza tienen que llevar a soluciones y no buscar culpables.
En fin, es probable que el código fuente se haya desarrollado durante décadas, y las mejoras en prácticas de desarrollo pueden dejar el código con una deuda técnica que reduce la eficacia de tus aplicaciones empresariales e introduce obsolescencia a las mismas. Esta deuda técnica afecta a la mantenibilidad de tu aplicación y aumenta los costos involucrados en hacer incluso cambios simples.
Antes de pasar a Git, ejecutar una “health check” con ARCAD Audit en tus aplicaciones detectará fuentes duplicadas, objetos sin fuente (o con una fecha posterior a la fuente), programas no utilizados y código muerto de varios proyectos antiguos que nunca se implementaron por completo. La herramienta ARCAD Audit limpia y archiva este código redundante, liberando tu aplicación de algunas áreas que pueden afectar la seguridad y la integridad de tu negocio.
A nivel de código fuente, para abordar la deuda técnica y mantener la calidad del código a medida que desarrollas, puedes utilizar herramientas de verificación de código continuo como ARCAD CodeChecker. El código limpio es más barato de mantener, más fácil de navegar y menos “aterrador” para los nuevos desarrolladores que se integran al equipo.
Limpiando tus aplicaciones evitas llevarte basura a tus procesos de control de versiones, disminuyendo complejidad y costos de mantenimiento de código.
Al pasar a Git, es importante involucrar a los equipos de IBM i desde el principio y durante todo el proceso de toma de decisiones. Para algunos, esto parecerá un cambio enorme en la forma en que han estado trabajando, algo del mismo tamaño que el cambio de terminales tontas a PCs. Es probable que más de la mitad de su equipo de desarrollo de IBM i haya comenzado en AS/400, si no antes, y la experiencia que tienen es fundamental, no solo en desarrollo sino también por el conocimiento operativo de los procesos.
Necesitamos que estén a bordo con los cambios que estamos introduciendo en la forma en que codifican e implementan sus cambios. Es importante transmitir las ventajas que ellos, como desarrolladores, obtendrán de Git una vez que suceda el cambio. Así como los beneficios a gran escala para toda la organización en cuanto a la gestión de TI, el cumplimiento de auditorías, la gestión de versiones, el personal de control de calidad y pruebas.
Tus equipos probablemente trabajan de formas ligeramente diferentes, así que querrás asegurarte de que tu estrategia no solo mejore el ciclo de cambios de la empresa, sino que también construyas un proceso compartido que entregue los mayores beneficios en todos tus equipos.
Usar ARCAD para una implementación gradual de prácticas de desarrollo modernas te permitirá mantener a tus desarrolladores de pantalla verde (5250) usando SEU pero aún así tener a Git como tu repositorio de código fuente. También es posible utilizar RDi por su puesto. Esto te ayuda a hacer la transición de tus equipos tradicionales hacia un pipeline empresarial de DevOps; con un entorno de desarrollo gráfico utilizando los complementos de ARCAD y un lenguaje de moderno completamente de formato libre.
Este es un cambio emocionante, y es fundamental mantener a todos los equipos del IBM i involucrados durante cada etapa del proyecto.
Suena simple, y entender los conceptos básicos de Git es fácil, pero un entrenamiento profesional en Git para tu equipo de IBM i es vital para una adopción efectiva. El conocimiento básico de Git ayuda a los desarrolladores a comprender los nuevos procesos y a obtener la terminología correcta para que la colaboración entre los desarrolladores de IBM i y de distintas plataformas (Windows, Linux, etc.) pueda fluir sin problemas; todos hablando un lenguaje común.
Existen muchos recursos para aprender Git en español, desde cursos accesibles en plataformas como Udemy hasta cursos certificados por plataformas como Platzi. No importa si el material no está enfocado en el IBM i, el conocimiento general de Git es el mismo en todos los sistemas.
La gerencia debe encargarse de un proceso de capacitación adecuado, con los medios y materiales que consideren pertinentes. Apoyar a los desarrolladores del IBM i, sobre todo a aquellos que llevan muchos años en la industria. Por otro lado, agregar como requisito el conocimiento de Git para la contratación de nuevos desarrolladores para reducir curvas de aprendizaje.
Durante el proyecto, muy probablemente será necesario involucrar o contratar personal externo con conocimiento en Git pero desconocimiento en IBM i. Esta fusión de habilidades y experiencia es altamente recomendable, ya que aumentará la colaboración entre los equipos de IBM i con sistemas abiertos. Contar con herramientas y un pipeline de entrega de software en común entre tecnologías diferentes pero interdependientes, reduce el riesgo de errores en la implementación y la costosas caídas de aplicaciones en producción.
La identificación y asignación de “campeones” entre el personal involucrado será clave para la correcta evolución del proyecto.
Estos campeones actuarán como enlace entre los diferentes equipos de tecnología, serán responsables de definir y adaptar la estrategia de ramificación para su entorno. También ajustarán la automatización a medida que los equipos de IBM i se adapten a la nueva forma de trabajar.
Al mismo tiempo, en equipos más grandes, los desafíos diarios que pueden surgir durante el desarrollo paralelo, como la resolución de conflictos de fusión, a menudo son referidos a un desarrollador senior o a un maestro de compilación (build master).
En un entorno IBM i, la naturaleza de un repositorio distribuido de Git no siempre es aplicable, ya que los desarrolladores a menudo requieren acceso directo a cierta funcionalidad del IBM i mientras codifican. Por esta razón, la integración de ARCAD con Git apunta a ofrecer la máxima flexibilidad, ofreciendo 3 opciones de estilo de desarrollo: Distribuido, Centralizado y Mixto.
ARCAD Skipper posibilidad adoptar de manera flexible estos estilos de desarrollo, para que de esta forma la utilización de Git en el IBM i sea posible.
Poder visualizar y demostrar las mejoras de Git ayudará a tu equipo a determinar el flujo de trabajo/modelo de ramificación óptimo para el entorno y comenzar a generar entusiasmo para el cambio a Git. Por otro lado, la visualización de resultados es la mejor forma de demostrar retorno de inversión a los directivos.
Puedes definir cómo quieres que se use Git en tu organización y empezar a construir evidencia de las mejoras que estás haciendo. Usando los tableros de ARCAD, puedes cuantificar la fortaleza de tu aplicación y demostrar el aumento en el rendimiento que los nuevos procesos de Git, sin duda, traerán a tu ciclo de desarrollo. Podrás evidenciar el aumento en la cantidad de cambios entregados al negocio, y los ahorros realizados gracias a la reducción del esfuerzo requerido por los equipos de desarrollo para entregar esos cambios.
Midiendo y visualizando resultados es la única forma de refinar estrategias de desarrollo. Ten en mente que en la tecnología y los negocios “datos matan relatos”.
El gestor de repositorio mejora significativamente el desarrollo colaborativo ya que es el encargado de gestionar los proyectos con sus múltiples ramificaciones, dando visibilidad completa a los desarrolladores, además de mejorar la documentación y el soporte de las aplicaciones. Usarlos no es estrictamente necesario para el desarrollo con Git, pero sí es altamente recomendable como ‘mejores prácticas’.
El uso de estos gestores de repositorios basados en Git aumenta la automatización con nuevas funciones y capas adicionales de seguridad. Las herramientas individuales dentro de ellos hacen que sea extremadamente fácil visualizar los cambios de código, lo que le permite rastrear fácilmente cualquier cambio específico que se haya realizado, quién lo hizo y cuándo.
Esto luego se puede rastrear hasta su fuente en producción o su sistema de seguimiento para construir evidencia de que se ha seguido el proceso correcto y que sus procedimientos de auditoría se adhieren sistemáticamente. Una cadena DevOps de principio a fin que incluya Git puede automatizar y rastrear estos pasos desde la creación de un ticket, a través del proceso de cambio, prueba e implementación, proporcionando a sus equipos de auditoría un procedimiento estándar para aprobar en lugar de una actividad ad hoc manual.
Los gestores de repositorios Git también permiten la integración con otras herramientas open source de DevOps. Por ejemplo, pueden vincularse directamente a Jira y registrar usuarios en líneas de código que hayan modificado la fuente por motivo de un ticket en Jira. También pueden proporcionar una interfaz con su conjunto de pruebas para permitirte adoptar un enfoque “shift left” (fallar rápido) y reducir el costo de los defectos.
Estas herramientas también pueden ayudar a liberar tus cambios a pipelines automatizadas para que se detecten defectos antes, y al reducir la intervención manual, puede reducir el costo de los errores que impacten al negocio.
ARCAD proporciona esa capa específica de tecnología IBM i necesaria para utilizar estas herramientas de gestión de repositorios Git de manera efectiva. Las herramientas de DevOps estándar de la industria no saben lo que es un IBM i, pero la capa de tecnología ARCAD sí lo sabe. Las herramientas ARCAD mantienen un repositorio de metadatos sobre su aplicación IBM i y utilizan este conocimiento para automatizar todo el ciclo de DevOps, desde el análisis de impacto hasta la compilación, prueba e implementación.
Si tu compañía tiene desarrollos en sistemas abiertos, como Linux o Windows, es muy posible que ya cuenten con algún gestor de repositorio ya sea en sus servidores o en la nube. Sin embargo, estas herramientas no están integradas con el proceso del IBM i.
Es más efectivo integrar al IBM i al gestor Git que tenga la compañía que comenzar a utilizar uno diferente. Es por tal motivo que ARCAD compatibiliza la integración de Git del IBM i con cualquier herramienta gestora de repositorio, algunas de ellas peeden ser Github, Gitlab, Bitbucket, Sourcetree, entre otras.
Una implementación efectiva DevOps implica la utilización de herramientas en común sin importar el sistema; IBM i, Windows, Linux, AIX, etc. Aquí te compartimos un artículo que habla más al respecto entre otros consejos:
La flexibilidad de Git al ramificar desde una línea principal de código es extremadamente poderosa cuando se utiliza correctamente, pero requiere una planificación cuidadosa para evitar problemas de fusión más adelante.
Las ramificaciones paralelas permiten a los desarrolladores generar código sin obstáculos a gran velocidad. Sin embargo, si los desarrolladores (bajo presión), promueven apresuradamente sus cambios simultáneamente, los conflictos de fusión inevitablemente ralentizarán la liberación de código y obstaculizarán el proceso de DevOps. Para lograr liberaciones más rápidas, es vital crear un proceso claro para realizar cambios en el control de origen; este “proceso” se conoce como estrategia de ramificación.
La elección de la estrategia de ramificación dependerá de varios factores: la frecuencia de liberaciones, el nivel de habilidad de tus equipos así como su tamaño. Acertar con la estrategia determinará la rapidez con la que tus equipos puedan entregar cambios al negocio y su capacidad de reacción para corregir errores. El sistema de versionado incorporado en ARCAD for DevOps le ayuda a implementar la estrategia de Git que mejor se adapte a su entorno.
Las estrategias de branching más populares son:
Aquí te compartimos un artículo con la explicación de cada una de ellas para que encuentres cuál es la que más se ajusta a tu situación.
Subir el código fuente de tu IBM i a Git es sencillo y puede hacerse de muchas formas diferentes, por ejemplo desde RDi utilizando eGit o incluso desde una línea de comando de Git.
Cuando subes el código fuente de tu IBM i a Git, el código ya no se almacena en archivos físicos de código fuente, sino que ahora se encuentra en archivos de flujo de texto similares a los archivos .txt en tu PC o los que se almacenan en el IFS. El código fuente en sí parece idéntico al código fuente en el IBM i, pero simplemente se almacena de una manera diferente.
Git por sí solo no puede gestionar los objetos “sin fuente” en el IBM i, como los programas ILE. (Con ILE, se compila el código fuente para crear módulos y luego se vinculan los módulos en un programa ILE). Esto agrega complejidad al usar “Git puro” en IBM i.
Para simplificar el proceso, ARCAD genera fuentes para todos los tipos de objetos sin código fuente (áreas de datos, programas de servicio, archivos de mensajes, archivos descritos por programas, etc.) para que puedan ser fácilmente gestionados con Git. Ahora que todos los componentes de tu aplicación están indexados y rastreados en el repositorio de metadatos ARCAD, tienes garantizado un procedimiento a prueba de auditorías y completamente rastreable.
Esta es la “inteligencia adicional” que requiere Git de la que hablábamos al inicio, y con ARCAD lo tienes cobierto. Aquí te compartimos una guía paso a paso de cómo se subirían las aplicaciones del IBM i a Git (en este cado a Github) con ARCAD for DevOps.
Sin una compilación integrada en Git, comenzarás a agregar complejidades a tus procesos donde no es necesario. Incluso si compilas desde RDi después de hacer el commit a Git, habrás introducido ineficiencias en tu proceso.
Principalmente porque se habrá creado un conjunto de restricciones y tareas manuales para tus desarrolladores, lo que aumenta el riesgo en el proceso de cambio. Esto te implicará pasos adicionales en tu proceso que no es totalmente automatizado, por ejemplo, una aprobación manual de que se hayan incluido todos los objetos correctos o que se hayan utilizado los cambios (deltas) de rama correctos para crear los objetos.
Los plugins desarrollados por ARCAD para integrarse con Git proporcionan una forma sencilla de mejorar el ciclo de desarrollo en tu IBM i. El núcleo de ARCAD es un repositorio de metadatos derivado de tus aplicaciones que contiene conocimiento detallado de referencias cruzadas que muestran qué programas utilizan qué campos y qué componentes relacionados deben volver a compilarse cuando realizas un cambio de código.
De esta manera, ARCAD for DevOps puede compilar específicamente los componentes que se han visto afectados por tu cambio, evitando la sobrecarga de volver a compilar todo lo demás en la rama. Este compilado “inteligente” se inicia automáticamente por ARCAD desde tu delta de Git.
Desde sus orígenes, el sistema de control de versiones de ARCAD y su “modo incremental” para el desarrollo en paralelo ha sido diseñado de manera que se adapte estrechamente al sistema de gestión de ramas en Git. Esto ha permitido una integración estrecha y transparente entre la ramificación de Git y los fundamentos de ARCAD que se utilizan para crear una compilación de deltas.
Usando webhooks en Git, esto también se puede automatizar para que en cuanto se fusiona una característica en tu rama liberada, podamos desencadenar un compilado del código fuente que ha cambiado, trayendo cualquier archivo lógico o vista relacionada si has actualizado un archivo, y trayendo toda la lista de programas, programas de servicio y módulos que utilizan tu código fuente cambiado e incluyendo todo esto en tu compilación.
La simplicidad que esto aporta a su proceso es un argumento clave para utilizar ARCAD for DevOps y gestionar su ciclo de cambios de Git en IBM i. Especialmente en esta nueva era de hacer “más con menos”.
Una vez que el control de versiones de Git está implementado en el IBM i, es el momento adecuado para considerar automatizaciones adicionales para eliminar cuellos de botella típicos en el proceso de cambios, como la revisión manual de código entre pares, las pruebas unitarias y las pruebas de regresión.
Un proceso de CI/CT/CD integrado en IBM i que comprende una compilación inteligente (CI), pruebas automatizadas (CT) y liberaciones seguras (CD), utilizando ARCAD con Git, entregará mejoras sustanciales en la frecuencia y calidad de los cambios que está entregando al negocio.
Reduce el tiempo de inactividad para sus usuarios finales al entregar los cambios más rápidamente y al permitir el despliegue de aplicaciones sin interrumpir su operación. ARCAD for DevOps ha mejorado en más de un 80% el proceso de desarrollo cuando empresas con IBM i han combinado ARCAD y Git como parte de una cadena DevOps.
El mundo del IBM i se ha visto un tanto relegado en cuanto a las nuevas tecnologías que surgen para optimizar el proceso de desarrollo. No es posible utilizar herramientas de gran utilidad como Github, Jenkins, Jira, Docker, JUnite, Selenium, entre otras muchas más.
Sin embargo, ARCAD Software crea este puente entre el viejo y el nuevo mundo del desarrollo con las diferentes módulos de su solución ARCAD for DevOps. La solución cuenta con módulos para gestionar al detalle cada una de las etapas del ciclo de vida de nuestras aplicaciones, optimizando nuestro proceso de desarrollo a todos los niveles. Menos errores, riesgos, y costos, y más agilidad, eficiencia, y seguridad.
En TIMWare somos socios comerciales y expertos técnicos en las soluciones DevOps de ARCAD Software. Estamos a disposición para ayudarte y asesorarte en el proceso de adopción DevOps en tu IBM i.
