Hoy en día los nuevos requisitos de integración y arquitectura (nube híbrida) están empujando los límites de la adopción DevOps en IBM i – AS400 como filosofía de desarrollo. La mayoría de las organizaciones con IBM i también desarrollan en sistemas distribuidos donde las herramientas de código abierto (open source) y la ‘contenerización’ son la norma. La madurez completa de DevOps depende de compartir métodos y herramientas de desarrollo en todas las plataformas para garantizar una fácil colaboración entre desarrolladores experimentados y nuevos al IBM i.
Es decir, lo ideal es que los equipos de desarrollo utilicen las mismas herramientas en todos los sistemas (IBM i, Linux, Windows, etc.) y arquitecturas (on-premise, cloud, multi-cloud, etc.) que tenga la compañía.
Para que DevOps tenga éxito, se necesita una forma de trabajo “híbrida”, que permita el acceso a las mismas herramientas desde la interfaz y el IDE preferido de cada equipo.
Este artículo se comenzó a trabajar con la intensión de ser una guía de pasos para lograr la madurez de DevOps. Sin embargo, no hay una ruta o metodología única para lograrlo, por lo que cada organización priorizará diferentes pasos dependiendo sus circunstancias. Así que en esta guía, en lugar de compartirte ‘pasos’, te compartiremos 8 consejos clave para lograr una integración DevOps exitosa en tu IBM i y sistemas distribuidos (en caso de haberlos).
“Para evitar proyectos de desarrollos costosos y arriesgados en el futuro, es importante actuar hoy y comenzar el proceso de adopción DevOps en su IBM i. Con un enfoque progresivo, cada paso individual demostrará un avance notable y medible con ROI (retorno de inversión).”
Philippe Magne – Fundador ARCAD Software
Los desarrolladores de IBM i han perfeccionado sus habilidades y prácticas durante décadas, han adquirido conocimientos altamente detallados y una profunda comprensión de la operación del negocio. Este conocimiento a menudo está únicamente en herramientas/utilidades personalizadas como plantillas de código fuente, notas, e incluso de memoria. La experiencia permite a los desarrolladores realizar cambios rápidos en el código de una manera eficiente para aquellos familiarizados con las herramientas nativas.
DevOps amenaza con cambiar este statu quo y, por lo tanto, es normal que algunos desarrolladores se preocuparán de que su conocimiento pueda perder valor. Otros tal vez pensarán que DevOps es otra tendencia pasajera. Algunos pueden estar preocupados de que las nuevas herramientas modernas de DevOps causen problemas porque no pueden conectar el estilo de desarrollo antiguo con el nuevo, o que no tendrán funcionalidades específicas para el IBM i. Algunos pueden pensar que DevOps se propone solo para que los desarrolladores veteranos puedan ser reemplazados fácilmente por desarrolladores más jóvenes y menos costosos. Algunos simplemente creen que no hay un retorno de inversión en la transición a DevOps.
Esto no podría estar más lejos de la verdad. DevOps nunca reemplazará las habilidades de personal sobre el IBM i, sino que las aprovechará y explotará al máximo. La automatización liberará a los desarrolladores de realizar trabajos manuales, tediosos, y que no suman nada al negocio, permitiéndoles enfocarse en tareas más gratificantes y de mayor valor agregado o impacto. DevOps permite a los desarrolladores tradicionales y nuevos compartir un repositorio y herramientas en común mientras mantienen su propio IDE familiar: RDi, 5250 o Web.
Todo su equipo de desarrollo debe estar alineado con esta idea, antes de comenzar cualquier esfuerzo por adoptar la filosofía DevOps en su IBM i.
Los desarrolladores nuevos a la plataforma IBM i pueden no estar cómodos con lenguajes de formato fijo como RPG IV; o trabajando con bases de datos con definiciones más antiguas como DDS o herramientas 4GL más antiguas como CA 2E Synon.
Un paso opcional es transformar el código RPG o 4GL tradicional en código moderno, como RPG de formato libre – RPG FREE FORM (que se parece mucho a Java) y DDL SQL (que es familiar para todos). Algunas aplicaciones legacy utilizan nombres de campos (columnas) incómodos con tamaños pequeños. Estos también pueden ser transformados como parte de la modernización del código. Las implementaciones de DevOps moderno ofrecen herramientas de transformación para acelerar el proceso junto con la automatización de pruebas para eliminar el riesgo de regresión.
Para el caso particular del IBM i, herramientas como ARCAD for DevOps cuentan con módulos capaces de modernizar el código fuente hacia RPG Free, y la reingeniería de bases de datos hacia SQL de forma sencilla. Un paso esencial para acelerar la adopción y curva de aprendizaje de nuevos programadores en su equipo de ingeniería.
Con el reciente auge de arquitecturas en la nube, ha llegado la adopción empresarial de herramientas de código libre (open source), a manera de micro-servicos para escalar los procesos de desarrollo de software. Es justo decir que gran parte de la nube fue posible gracias tanto a factores económicos como a la capacidad de adaptación que caracteriza al software libre.
Esta creciente confianza hacia aplicaciones de software libre ha transformado el panorama del ciclo de desarrollo de aplicaciones a nivel empresarial. Aunque las herramientas nativas en IBM i pueden parecer muy diferentes a sus equivalentes de software libre como Git y Jenkins, hay una emergente necesidad de unificar los procesos en todas las plataformas por igual, tanto en la nube como en sitio (on-premise).
El objetivo es lograr un solo punto de control para monitorear aplicaciones diversas y administrar sus interdependencias de manera segura. Tener una “pila de herramientas DevOps empresarial” elimina las complicaciones de trabajar entre los equipos legacy y distribuidos gracias a un repositorio de código fuente común y un pipeline CI/CD compartida.
En ocasiones y particularmente para el IBM i, construir un pipeline de entrega de software personalizada ha sido complejo, a tal grado que involucra customizar o arreglar herramientas disímiles utilizando scripts personalizados que no escalan y terminan haciendo más costoso el proceso de desarrollo. Para eliminar este sobrecosto, las implementaciones de DevOps en IBM i deben basarse en herramientas integradas y listas para usar con complementos preconstruidos para integrarse con aplicaciones DevOps de código abierto más comunes (ej. Github, Jira, Jenkins, JUnit, etc.).
Aquí, la clave del éxito es ofrecer a los equipos tradicionales acceso a herramientas de código abierto desde un entorno moderno que mantenga las características específicas de IBM i que necesitan para sentirse cómodos y productivos. Lo que puede parecer un “santo grial” es una realidad hoy en día y es el camino claro para lograr la modernización en los procesos de desarrollo del IBM i.
Un paso clave en el proceso de madurez DevOps, es identificar y eliminar los “bloqueos” que han estado retrasando el trabajo de los desarrolladores. En el modelo tradicional, los desarrolladores trabajaban en cambios con relativamente poca comunicación diaria entre sí, estableciendo sus prioridades diarias por sí mismos. Este enfoque puede que comience de forma ágil y efectiva, pero al poco tiempo causa bloqueos frustrantes, donde un desarrollador puede estar bloqueado para realizar una acción debido a que otro desarrollador ha realizado una acción de bloqueo (por ejemplo, bloquear algunos objetos).
Es difícil predecir con precisión cuánto tiempo tomará cada desarrollador para completar un cambio. Algunos desarrolladores pueden estar saturados y estresados, mientras otros están inactivos esperando. A veces, debido a la falta de visibilidad, los desarrolladores eligen priorizar cambios que no son las prioridades comerciales más valiosas. Los clientes a menudo se frustran debido a que las estimaciones de entrega son constantemente inexactas y hay una gran cantidad de solicitudes de cambio.
Adoptar métodos ágiles en su IBM i ayudará a alinear las prioridades de desarrollo estrechamente con las necesidades del cliente, y a monitorear mejor la carga de trabajo de los desarrolladores. Los clientes notarán el beneficio cuando cuenten con estimaciones más precisas.
Una herramienta fundamental para un enfoque ágil es una solución de seguimiento de problemas automatizada, como Jira. Jira es una de las herramientas más utilizadas para la gestión de proyectos, seguimiento de errores, problemas y flujo de trabajo. Estas herramientas mejoran la visibilidad de las tareas entre los miembros del equipo, lo que ayuda a mejorar la forma en que se cierran las tareas, así como para identificar y eliminar los obstáculos. ARCAD for DevOps le permite integrar su IBM i con este tipo de herramientas.
Git se ha convertido en el estándar de la industria para el control de versiones y es probable que ya se esté utilizando en su organización (fuera del IBM i). Git simplifica el desarrollo concurrente y aporta agilidad en la gestión y entrega de las versiones. Facilita el cumplimiento de auditoría, ya que Git registra todos los cambios realizados en su aplicación. Su mecanismo de ramificación (branching) ligero y sus características de combinación (merge) ayudan a su equipo de desarrollo a ser más colaborativo. Los cambios de fuente realizados por varias personas (piensen en desarrollo comunitario o social) se combinan automáticamente cuando no se detectan conflictos, lo que brinda a los desarrolladores la máxima flexibilidad y libertad en la gestión de sus cambios.
Esta flexibilidad contrasta con el bloqueo de fuente que imponen las herramientas tradicionales de gestión de cambios IBM i.
Sin embargo, el “Git puro” no tiene conocimiento de IBM i y no es capaz de manejar las muchas variantes de lenguajes en la plataforma. Para ser verdaderamente efectivo en IBM i, Git requiere una inteligencia adicional para manejar las especificidades nativas, como los objetos sin fuente. Con este propósito, ARCAD for DevOps proporciona una capa avanzada e integrada de tecnología IBM i que maneja todas estas particularidades del IBM i de manera transparente y “tras bambalinas”.
De esta manera, una nueva generación de desarrolladores “nuevos en IBM i” pueden estar rápidamente al día en la plataforma. Al mismo tiempo, los equipos de desarrollo tradicionales de IBM i pueden beneficiarse de las características de Git manteniendo su entorno familiar. Los desarrolladores tienen acceso directo a las características de ARCAD, como:
Y dependiendo del flujo de trabajo deseado, ARCAD for DevOps puede implementar Git en un modelo centralizado, distribuido o mixto. El módulo de ARCAD Skipper es el encargado de hacer toda esta labor en su IBM i.
Adoptar el ‘verdadero enfoque Git’ es probablemente el hito más importante en la adopción DevOps en su IBM i.
Con la gestión de código fuente de Git, es necesario fusionar las ramificaciones (branches) de código con la rama principal lo más a menudo posible, ya que cuanto más tiempo pasen sin fusionarse, mayor será la posibilidad de tener conflictos por empalmar el código, lo que puede resultar en hacer retrabajos.
La integración continua es solo eficiente de manera óptima si está completamente automatizada. Es un hito importante para lograr un DevOps moderno y aumenta notablemente la velocidad general de desarrollo. Las herramientas de automatización, como Jenkins, GitLab CI o Azure pipelines, pueden ayudar a simplificar, automatizar, acelerar y eliminar errores de las tareas de compilado. Sin embargo, en IBM i, estas herramientas deben utilizarse en conjunto con procesos de compilado inteligentes que tengan en cuenta las dependencias y compilen cambios complejos en la secuencia correcta.
Este nivel de automatización ahorrará tiempo, mejorará la calidad y reducirá la necesidad de que los desarrolladores mantengan sus propias herramientas personalizadas. En el IBM i, es posible solucionarlo de forma nativa con el módulo de ARCAD Builder.
En IBM i, al igual que en cualquier plataforma, las liberaciones a producción apresuradas han causado fricción entre los equipos de desarrollo tradicionales y los equipos de operaciones responsables de mantener estas aplicaciones estables. Para superar los objetivos conflictivos de Dev (desarrollo) y Ops (operaciones), y para lograr los beneficios prometidos en velocidad y confiabilidad, se requiere una frecuencia mucho más alta de liberaciones de software a producción, aunque sean modificaciones más pequeños.
Algunos equipos avanzados tienen la capacidad de hacer varias liberaciones incluso por minuto. Según el informe State of DevOps de 2019, equipos de desarrollo de alto rendimiento son aquellos que logran más de 1,460 liberaciones al año, lo que equivale a cuatro implementaciones por día, algo atípico en IBM i y un logro que solo se podría alcanzar con un ciclo DevOps verdaderamente continuo.
Las herramientas de gestión de liberaciones automáticas, aceleran y eliminan errores de los mecanismos de entrega. En las arquitecturas modernas de IBM i, cualquier solución de gestión de liberaciones debe orquestar la implementación en todas las plataformas y brindar soporte para entornos on-premise, híbridos y multi-cloud. Una implementación común y compartida de la empresa garantizará la integridad de la aplicación implementada en todas las plataformas.
DROPS es una solución que le permitirá gestionar y automatizar su proceso de liberaciones en el IBM i, y también en cualquier otro sistema en su operación (Windows, Linux, AIX, etc.). Facilitando la liberación a producción habilitando el verdadero poder de CI (Continuous Integration).
A medida que aumentan las liberaciones de software, los usuarios esperan continuidad operativa ininterrumpida de sus aplicaciones empresariales las 24 horas del día, los 7 días de la semana. Por supuesto, existe una oposición lógica entre las liberaciones frecuentes, el mantenimiento de la calidad del software liberado y un ambiente estable. DevOps es solo una parte de la solución.
Para protegerse contra fallas operativas, se necesita una “puerta de calidad” automatizada. Las herramientas DevOps modernas implementan una de medidas de seguridad en cada fase del ciclo de desarrollo para evitar que las actualizaciones no probadas lleguen a producción. Los defectos de calidad y el código con malas prácticas debe ser identificadas y corregidas en diferentes instancias de un pipeline CI/CT/CD. Al detectar los defectos lo antes posible (preferiblemente en la fase de escribir código, previo a compilado), reducimos su costo y su tiempo medio de reparación (MTTR).
Los controles comienzan con el análisis de código estático en cada comit de código, seguido de las pruebas unitarias del lado del desarrollador para detectar el código erróneo antes del compilado de la aplicación. Al final del ciclo, las pruebas de regresión funcional detectan efectos secundarios no identificados comparando los datos con una ejecución de prueba anterior. A través de la automatización iterativa, un enfoque DevSecOps minimiza el riesgo de interrupciones no planificadas y asegura un ROI medible.
Los diferentes módulos de ARCAD Software le facilitarán considerablemente su proceso de adopción y maduración DevOps en su IBM i y sistemas distribuidos (Windows, Linux, etc.). Ya que aplicaciones open source que utilice en sistemas distribuidos (ej. Github, Jira, Jenkins, etc.), pueden ser integrados de forma transparente con el proceso de desarrollo en su IBM i.
ARCAD for DevOps cuenta con módulos que cubrirán sus necesidades en cualquier etapa del ciclo de vida de sus aplicaciones, sin importar si son aplicaciones Legacy o nuevas:
Este artículo fue originalmente escrito por ARCAD Software, TIMWare es socio de negocio y especialista técnico en sus soluciones de DevOps.
