Estos son 9 pasos en la visión personal de Adrian Tully como Jefe Global de Servicios de Ingeniería y Herramientas de DevOps en HSBC, para ayudar a hacer la transición de un ‘equipo de desarrollo AS/400’ a un Agile Pod IBM i con una metodología DevOps de CI/CT/CD (Continuous Integration / Continuous Testing / Continuous Delivery) totalmente automatizada.
El siguiente reporte es una traducción en palabras de Adrian Tully, publicado originalmente en el blog de Arcad Software.
Nunca fue fácil convencer a los desarrolladores veteranos de la necesidad de hacer un cambio para convertirse en un Agile Pod moderno después de décadas de tradición. Los desarrolladores que todavía prefirieron usar el término ‘AS / 400’ en protesta pasiva contra esos que abandonaron el nombre original de IBM i hace más de veinte años no se dejaron influenciar fácilmente por la moda. Inicialmente, se me apareció un muro de resistencia cuando presenté por primera vez la idea de un Agile Pod. Sus argumentos sonaban lógicos, racionales, meditados, fervientes, convincentes y al mismo tiempo… erróneos. Mi gigantesca tarea fue convencer constantemente a un equipo global de 1500 desarrolladores tradicionales para que abandonaran estas ideas preconcebidas y dieran el salto de DevOps. Sin embargo, conozco a muchos que se han encontrado con estas mismas objeciones en equipos tradicionales de todos los tamaños.
Mi desafío fue ampliar las perspectivas y darles la vuelta a los siguientes argumentos:
Cada argumento de estos desarrolladores veteranos parecía sensato, sin embargo, había algo en el fondo de mi mente que me hizo pensar que una herramienta de desarrollo gráfico como Rational Developer para i (RDi) podría aportar algo más a esta mesa. Tenía que haber una forma de hacer que agregar valor a la vida de estos desarrolladores veteranos, ya que lanzaron sus muchas macros personalizadas cuidadosamente diseñadas a lo largo de los años.
¿Por qué comenzaron RDi varias veces al día? Me di cuenta de que el gerente del equipo de desarrollo no pasaba todo el día programando, por lo que entraba y salía de la tarea haciendo un poco de desarrollo aquí y allá. De ahí venía todo el ruido de inicio lento.
Mi pensamiento era que, si pudiéramos aumentar la productividad de los desarrolladores, seguramente su gerente no necesitaría entrar y salir de una herramienta de desarrollo. Esto eliminaría la necesidad de que actúen como desarrolladores a tiempo parcial y les daría más tiempo para administrar el equipo.
Noté que los desarrolladores pasaban todo el día en sus escritorios escribiendo especificaciones, codificando, configurando entornos de prueba, probando, tomando café y escribiendo documentación. Por lo tanto, solo necesitarían iniciar RDi una vez al día. Pensé que debía haber una forma de hacerles ver los beneficios de productividad de una herramienta de desarrollo gráfico con su color, su formato y su acceso mejorado a los sistemas. Incluso si la mayor parte de la programación todavía fuera RPG de formato fijo, los beneficios de una herramienta de desarrollo gráfico deberían simplificar y acelerar su codificación. Todavía tendrían que cambiar a la pantalla verde para hacer sus pruebas y configuraciones de entorno, pero dado que RDi estaría abierto todo el día, los desarrolladores no estarían expuestos a tiempos de inicio lentos en comparación con la pantalla verde, excepto una vez al día.
Mi plan era comenzar e instalar RDi en todas las computadoras portátiles de los desarrolladores para que algunos al menos lo probaran. Además, nos tomamos un tiempo para ofrecer un par de sesiones rápidas de capacitación en RDi, sólo para cubrir los conceptos básicos y ver si podíamos sorprenderlos.
Inicialmente se asumió que las reuniones diarias, por breves que fueran, eran una pérdida de tiempo porque estos veteranos ya sabían qué hacer. También hubo un alto nivel de desconfianza inicialmente sobre la introducción de nuevas herramientas de informes como Jira, una falsa suposición de que había un motivo de mala fe detrás de esto.
Persistí. En las primeras semanas, los scrums diarios (breves reuniones matutinas con todos los miembros del equipo para discutir las prioridades para el día siguiente) podrían no haber sido todo lo que los libros de DevOps habían dicho que deberían ser, pero fue un comienzo. Los 15 minutos previstos, inicialmente fueron 20 minutos, pero después de un corto tiempo los scrums se hicieron más cortos y productivos. Gradualmente, los miembros del equipo se sintieron más cómodos con el concepto de sprints (períodos cortos de tiempo encuadrado en los que el equipo de scrum trabaja para completar una cantidad determinada de trabajo). Con el tiempo, todos los miembros del equipo comenzaron a sentirse más involucrados en los objetivos del sprint (descripciones de dos oraciones de lo que el equipo planea lograr durante este sprint).
A medida que aumentaba la confianza, presentamos Jira, que nos permitió realizar un seguimiento de los “problemas” (un término genérico de Jira para un trabajo, como una tarea de proyecto o un ticket de asistencia técnica) de forma automatizada. Esto nos ayudó a encontrar mejoras en la forma en que cerraríamos el trabajo. De hecho, pudimos ver quién estaba trabajando en qué, y eso hizo que los conflictos fueran más fáciles de resolver. También encontramos una oportunidad para detener cualquier bloqueo (cualquier cosa que nos ralentizara) que se afianzara y detuviera el flujo de desarrollo. El rendimiento del equipo fue mejorando a medida que el camino hacia la finalización se volvió un poco menos obstruido y un poco más coordinado.
La unidad de equipo se fortaleció y tuvimos más tiempo para las aportaciones de los usuarios finales. Algunos miembros del equipo todavía no podían referirse a ellos como “clientes”, simplemente estaban demasiado “de moda”. Sin embargo, como resultado de esa información, pudimos comenzar a priorizar los cambios que brindaban el mayor beneficio comercial y nos enfocamos en entregar mejoras más pequeñas más rápido.
Ahora podíamos monitorear mejor la carga de trabajo, nuestra estimación había mejorado y, a su vez, eso nos permitió entregar más de lo que prometimos y más a tiempo.
Los miembros del equipo inicialmente lucharon contra la inercia, incluso cuando les estaba mostrando cómo salvar sus fines de semana. La mayoría de los desarrolladores veteranos inicialmente pensaron que pasar la mayor parte de su fin de semana ejecutando múltiples CRTDUPOBJ (comando de creación de objeto duplicado de IBM i) para copiar cambios de meses en bibliotecas de prueba era “la única forma segura”. La falta de una pista de auditoría transparente no pareció ser una consideración.
Insistí en que necesitábamos un conjunto de herramientas DevOps integrado y le pedí al equipo que confiara en mí pidiéndoles que consideraran cuánto progreso ya se había logrado. La oferta del gerente del equipo para construir uno simplemente no fue práctica. Simplemente no teníamos los recursos para hacer eso, y tendríamos que mantenerlo, apoyarlo, mejorarlo. Nos habría desviado de nuestros verdaderos objetivos.
No había tantos conjuntos de herramientas de DevOps creíbles y adecuados para IBM i en el mercado en ese momento (todavía no lo son). ARCAD cumplió con los requisitos, tienen una gran historia de varias décadas con nuestro legado AS / 400, System i, iSeries, IBM i y sus herramientas DevOps integradas que sobresalen en la construcción de un puente entre el mundo antiguo y el nuevo. ARCAD también tenía algunas características modernas realmente elegantes que el Pod de desarrollo (comencé a llamarlas así ahora, solo por diversión :)) inicialmente desaprobaría.
Hubo algunos beneficios instantáneos que me sorprendieron incluso después de que comenzamos a usar ARCAD. ARCAD Observer (herramienta de análisis de aplicaciones) creó instantáneamente (de la noche a la mañana) un rico repositorio de referencias cruzadas que documentó automáticamente todas nuestras aplicaciones relevantes, sus relaciones internas entre archivos, programas y otros objetos. Esto rápidamente permitió al Pod dedicar menos tiempo a analizar y más tiempo a crear. El tiempo de desarrollo de un extremo a otro disminuyó rápidamente. La preocupación inicial de que un conjunto de herramientas de DevOps sería una carga para un equipo ya ocupado y ralentizaría el tiempo de desarrollo de un extremo a otro se evaporó rápidamente. Encontramos ahorros de tiempo a lo largo de nuestro proceso, lo que nos permitió hacer más y más rápido.
El repositorio de ARCAD subyacente significaba que no teníamos que preocuparnos por lo que era necesario volver a compilar después de realizar un cambio. Los miembros de nuestro Pod estaban codificando y compilando de forma segura sabiendo que todos los objetos relacionados con sus cambios en el código también habían sido reconstruidos.
Todos los cambios se empaquetaron en entregas y la herramienta ARCAD Builder se aseguró de que todos los cambios se compilaran y entregaran para probar de la misma manera, siempre, un enfoque consistente que construye la aplicación según nuestros estándares que mejora tanto la velocidad como la confiabilidad.
Ya teníamos un proceso automatizado para integrar los cambios con los entornos de prueba, pero era increíble para mí que no tuviéramos algo automatizado para la producción. Con la herramienta ARCAD DROPS ya teníamos algo que podría usarse para esto, era sólo una extensión de nuestra configuración existente. Pensé que lo probaríamos un domingo y veríamos cómo funcionaba.
Normalmente no paso mis domingos por la mañana trabajando para poner cambios en la aplicación de producción, pero este domingo fue diferente. Estuvimos todos allí, el administrador del módulo de desarrollo, yo y nuestro gurú de gestión de cambios con más experiencia para entregar los cambios a través de un SAVF (Archivo de salvar). Nos advirtieron que podrían ser las 3 horas más aburridas de nuestra vida, ya que ese es el tiempo que se esperaba para que este volumen de cambios se entregara a producción.
Mi café ni siquiera se había enfriado y… “Creo que hemos terminado”, llevábamos 30 minutos en lo que se suponía que era una entrega maratónica de 3 horas. “Bueno, eso salió bien”… dije mientras DROPS había sacado a relucir el maestro de la subestimación en mí.
La entrega estaba completamente documentada, teníamos listas de objetos que se habían cambiado, teníamos detalles de los programas vinculados y archivos que se habían reconstruido. La trazabilidad de los cambios fue increíble y pudimos vincularlo todo al ticket del trabajo original a través de la integración de ARCAD en nuestro sistema de tickets de Jira. Incluso teníamos una función de retroceso sofisticada.
Instalamos el código fuente completo para todas las aplicaciones relevantes en la computadora portátil de cada miembro de Pod (RPG es muy compacto, por lo que no hay problemas de espacio). El módulo de desarrollo ahora pudo pasar más tiempo trabajando desde casa, lo que les dio más flexibilidad para administrar su tiempo y agregar equilibrio a sus vidas, sin mencionar un aumento de moral. Seguíamos haciendo los scrums diarios de forma virtual para asegurarnos de que todos estuvieran al día con el progreso del sprint, pero la necesidad de estar en la misma oficina se había reducido drásticamente.
Pasar a un repositorio central de código fuente y hacer que los miembros del Pod confirmen sus cambios en lugar de tener que estar constantemente en línea con el IBM i prácticamente eliminó el problema de las telecomunicaciones. Este dolor sucedería todos los días cuando los niños del vecindario regresaran a casa de la escuela al mismo tiempo y sobrecargaron el ancho de banda de las telecomunicaciones. También cuando los trabajadores apagan periódicamente la energía durante un par de horas, lo que lo obliga a contemplar la posibilidad de conducir hasta la cafetería local solo para volver a conectarse.
Implementamos Git (el sistema de control de versiones distribuido estándar de la industria para rastrear cambios) y funcionó muy bien aquí. La interfaz con ARCAD Builder y algunos complementos de ARCAD adicionales hicieron que vincular el repositorio de código fuente y las aplicaciones en IBM i fuera realmente fácil.
YouTube fue un gran recurso para ayudar al Pod a comprender los conceptos básicos de Git. Aprender sobre la ramificación y la fusión de una gran comunidad global de codificadores fue liberador para el Pod. Adoptar Git y ARCAD para nuestra codificación de juegos de rol ahora tenía más sentido para todos. Estábamos empezando a aprovechar el conocimiento colectivo de una comunidad mucho más grande. Estábamos empezando a compartir código con otros desarrolladores de IBM i en otras partes de nuestra empresa global. Ya no estábamos atrapados en una habitación sofocante escondidos detrás de un escudo bimodal de resistencia. Dado que ahora estábamos comenzando a utilizar herramientas y métodos modernos, permitió que Pod se sintiera más seguro con respecto a sus trabajos y su contribución a la empresa y nos permitió atraer a nuevo personal.
En cierto punto de este viaje, noté que los beneficios estaban comenzando a llegar más rápido que nuestros esfuerzos. Estábamos llegando a un punto en el que algunos beneficios comenzaban a aparecer de forma gratuita como subproductos de lo que ya habíamos hecho.
El Pod, que ahora está en contacto frecuente con una comunidad global de programadores, había comenzado a funcionar con DevOps y regresaban a mí con más formas de mejorar el ciclo de desarrollo y eliminar más bloqueadores.
ARCAD tenía macros de integración y compilación personalizables encadenadas, por lo tanto, después de una compilación exitosa, estábamos entregando cambios de aplicación automáticamente en entornos de prueba con las macros de ARCAD. Fue una buena solución; era un buen trampolín, pero ahora tenía un Pod hambriento de DevOps completo, así que sabía que pronto se necesitaría aún más automatización de DevOps.
ARCAD tiene una integración confiable con Jenkins, por lo que después de algunas discusiones con el Pod, devolvimos las macros de ARCAD a su estado original (no personalizado) para que siguieran siendo totalmente compatibles con Jenkins en el futuro. Luego implementamos la canalización natural de Jenkins para integrar y entregar nuestras compilaciones en nuestros entornos de prueba. Un Jenkins CI (servidor de integración continua) estaba ejecutando el proceso de desarrollo para nuestro desarrollo AS / 400 heredado, ¡bang! Este fue un objetivo desde el principio y cuando se puso en marcha le dio a todo el Pod una verdadera sensación de logro. Ahora teníamos una “carretera” pavimentada para la integración.
Ahora nos dimos cuenta de que estábamos implementando cambios en los entornos de prueba tan rápido que no permitimos el tiempo suficiente ni siquiera para las pruebas unitarias básicas. Esto resultó en muchos errores devueltos al Pod y esto, a su vez, tomó tiempo para los sprints. Inadvertidamente, habíamos introducido un cuello de botella exactamente donde no lo necesitábamos. Pasamos demasiado tiempo probando los cambios que estaban causando problemas al entregar mejoras a los clientes (sí. Finalmente convencí al Pod de que dijera clientes, no usuarios :)) en función de un cronograma acordado.
No hay nada más que se acerque a las capacidades de ARCAD listas para usar en lo que respecta a la automatización de pruebas unitarias, a menos que dedique un gran esfuerzo a reconstruir una pieza de código abierto de hace una década. ARCAD iUnit conectado directamente a nuestra tubería existente. El Pod estaba escribiendo sus propios casos de prueba ARCAD iUnit y compartiéndolos en uno o dos días. Los casos de prueba se vincularon a componentes específicos para que pudiéramos probar unitariamente solo las funciones específicas que habían cambiado en lugar de tener que probar un programa completo (tenemos programas grandes).
El Pod comenzó a usar ARCAD Verifier para automatizar las pruebas de regresión y se concentraron en crear escenarios de prueba que pudieran reutilizarse en varias funciones de la aplicación. Esta reutilización supuso un gran ahorro de tiempo. Esta prueba adicional completamente automatizada mejoró la confiabilidad de la aplicación tanto que se habría necesitado 3 veces más personal para lograr lo mismo utilizando los métodos anteriores.
Luego, el Pod implementó los complementos ARCAD Code Checker y ‘¡guau’, es una herramienta increíble! No es una herramienta de prueba, funciona para mejorar la calidad del código fuente en primer lugar. Nos permitió definir y aplicar estándares de codificación en todo el código fuente y demostró dónde existían debilidades de calidad y por qué. Fue como una revisión por pares automatizada. Pudimos hacer cumplir los estándares de calidad del código en todo el Pod de desarrollo. Por ejemplo, podríamos identificar automáticamente el código que habría generado problemas de seguridad (un problema adicional para un banco) y devolverlo directamente al desarrollador. A medida que pasaba el tiempo, el Pod podía ver problemas de calidad del código casi en tiempo real y solucionarlos en la raíz mientras codificaba.
En esta etapa, la integración continua y las pruebas continuas ya habían proporcionado mejoras cuánticas. Los cambios en las aplicaciones se estaban entregando de manera más rápida, más confiable y con un mejor valor comercial para nuestros clientes. Los clientes comentaban que veían las mejoras solicitadas con mayor rapidez y que obtenían mejores beneficios comerciales de ellas. Todo esto fue una consecuencia directa del ciclo DevOps que habíamos implementado.
Las corrientes de valor que estábamos construyendo con estas herramientas se veían bien y todavía había cosas que necesitábamos perfeccionar, pero nuestra “supercarretera” estaba en su lugar.
Sí, nos tomó 3 años, pero hemos logrado una canalización de CI / CT / CD completamente automatizada. Ahora estamos entregando continuamente cambios de IBM i a la producción a través de una comunidad de desarrollo ágil y sin pasos manuales. Se han recuperado los domingos y podemos realizar cambios en el negocio sin introducir tiempo de inactividad y esto, a su vez, ha aumentado las horas que el negocio puede operar, una ventaja competitiva.
El antiguo calendario de publicación mensual ha sido reemplazado por un panel de Value Stream que pueden ver los gerentes de nuestra compañía global. Las mejoras en la calidad de la aplicación ahora se pueden ver ya que varias herramientas de Arcad informan a un tablero de calidad gráfico.
Nuestras pruebas automatizadas han dado como resultado un ‘cambio a la izquierda’ para la detección y reparación de errores y esto ha supuesto una mejora real en los costos involucrados en cada cambio y la velocidad con la que se entregan. Todas las pruebas de regresión son completamente automáticas y las pruebas unitarias se han convertido en un clic del mouse.
Estas microentregas continuas y sólidas están teniendo un impacto positivo en el negocio. No hay más reuniones mensuales de revisión de cambios. En cambio, existe una mayor participación en el negocio, se discuten sus puntos débiles y se averigua cómo podemos evolucionar la aplicación a continuación para generar más beneficios comerciales para ellos.
Por último, pero no menos importante, todo el código RPG heredado se ha refactorizado automáticamente a un RPG moderno de formato libre utilizando ARCAD Transformer. Esta fue una inversión para el futuro, contamos con codificadores expertos con gran experiencia que planifican sus jubilaciones y trabajan junto con los codificadores más brillantes y jóvenes utilizando un repositorio de código fuente compartido alojado en una nube. Todos ellos desarrollando las aplicaciones para nuestro patrimonio IBM i y siguiendo una metodología Agile con un pipeline automatizado y todo bajo la atenta mirada de DevSecOps.
Esto está muy lejos de las “pantallas verdes” de hace 3 años.
