Sin importar qué tanto hubieran avanzado Thomas Lawless, ingeniero de software sénior de IBM, o su equipo el día anterior, comenzaban cada jornada laboral comprobando si había código por revisar: “Era como si rehiciéramos el proceso cada mañana”, afirma.
Lawless es responsable de supervisar la producción, la implementación y la entrega de algunas de las aplicaciones de la intranet de IBM de mayor tamaño. “Mi ámbito de trabajo abarca el desarrollo, la integración continua, la automatización de pruebas, la automatización de la implementación y las operaciones”, explica, “lo que significa que, en un día determinado, trabajo con 40 o 50 personas diferentes, todas de distintos equipos”.
“Disponemos de lo que nos gusta llamar un ‘flujo de entrega de principio a fin’, que se inicia con el código fuente y recorre todo el proceso hasta la implementación de la producción”, afirma Lawless. “Y ahora hemos integrado a Slack en todos los hitos fundamentales de ese proceso”.
Un aspecto fundamental del trabajo de Lawless es incorporar técnicas y servicios de desarrollo para mejorar las operaciones y acelerar la entrega. Hace más de un año, comenzó a usar Slack con otros equipos de IBM como un centro para las comunicaciones entre los equipos, pero pronto descubrió que Slack también es eficaz para recopilar comunicaciones no humanas, como alertas de sistemas y notificaciones de otros servicios.
“Disponemos de lo que nos gusta llamar un ‘flujo de entrega de principio a fin’, que se inicia con el código fuente y recorre todo el proceso hasta la implementación de la producción”, afirma Lawless. “Y ahora hemos integrado a Slack en todos los hitos fundamentales de ese proceso”.
Gestión de procesos de compilación e implementación en Slack
En IBM, los equipos prefieren usar canales públicos de Slack (por ejemplo, #desarrollo-equipo) en los que los miembros pueden conversar abiertamente sobre las incidencias y los expertos de otros equipos pueden unirse fácilmente y contribuir al debate.
Los canales de los equipos contienen mensajes de personas y alertas del sistema de las numerosas aplicaciones que usan. Digamos, por ejemplo, que un desarrollador envía el código fuente de la historia de un usuario para su revisión. El sistema activa una notificación en el canal de Slack del equipo en la que se informa a todos los participantes que hay código nuevo por revisar. A partir de allí, el revisor puede ingresar en el sistema y revisar el código directamente desde el mensaje de Slack.
“Antes de que usáramos Slack, un desarrollador tenía que encontrar a la persona que creía que debía ser el revisor y enviarle un correo electrónico o iniciar un chat personal con ella”, dice Lawless.
Dado que los equipos centralizan sus flujos de trabajo en Slack, pueden seguir el ritmo de sus avances porque saben que recibirán una notificación sobre cada revisión individual de código que se necesite y podrán ocuparse de ella directamente desde Slack.
Cohesión de equipos en torno a alertas de sistemas para una gestión de incidencias más eficiente
Echemos un vistazo a algunos de los canales de equipos más destacados en IBM y el tipo de conversaciones y notificaciones que se publican allí:
#ayuda-servicios: se recopilan notificaciones de solicitudes pull (PR, por sus siglas en inglés) para facilitar las revisiones automatizadas de código entre pares y se alerta al equipo cuando la solicitud ha sido aprobada, con lo que los miembros no necesitan cambiar de aplicación para ver la última actualización. El equipo también cuenta con la integración Jenkins/Travis CI, que les notifica cuando cambia el estado de una compilación.#ayuda-implementaciones: se notifica a los miembros del equipo sobre implementaciones fallidas cuando los cambios en el código avanzan hacia la automatización de pruebas.#ayuda-tareas: se publica una notificación cuando se produce un error en un trabajo de procesamiento por lotes.#starfleet-supervisión: aquí se publican las notificaciones de NewRelic, Splunk y PagerDuty para fines de supervisión de los tiempos de ejecución y gestión de incidencias.
“El canal funciona como una especie de mecanismo de auditoría”, dice Lawless. “Usamos estos canales de incidencias como la base de nuestros análisis a posteriori, y lo mejor es que no tenemos que jugar a las adivinanzas, porque tenemos todo el historial allí mismo”.
Lawless explica que, cuando aparece una alerta sobre un error o una incidencia en Slack, los miembros del equipo correspondiente crean un nuevo canal específico de la incidencia en el que pueden analizar posibles soluciones y cualquiera puede invitar a otros expertos si es necesario.
Cuando el problema se ha resuelto, el equipo dispone de un registro de la incidencia completa, que incluye todos los archivos, capturas de pantallas, mensajes de error y alertas que se consideraron hasta alcanzar la solución.
“El canal funciona como una especie de mecanismo de auditoría”, dice Lawless. “Usamos estos canales de incidencias como la base de nuestros análisis a posteriori, y lo mejor es que no tenemos que jugar a las adivinanzas, porque tenemos todo el historial allí mismo”.
Recientemente, Lawless y su equipo han empezado a usar Slack con proveedores de los distintos servicios que usan. El ingeniero observó que la mayoría de las empresas están encantadas de compartir con sus equipos un canal privado de Slack en el que conversen de los problemas y las dudas que puedan tener, lo que les permite evitar muchos intercambios innecesarios.
Menos pasos adicionales para una mayor productividad
Lawless y su equipo han integrado a Slack en cada una de las fases del proceso de desarrollo: desde escribir y probar el código fuente inicial hasta la implementación final. En lugar de pasar toda la mañana comprobando si hay nuevo código por revisar, todos los miembros del equipo retoman su trabajo donde lo dejaron el día anterior.
“Cada vez que veo una integración de Slack, la activo”, comenta Lawless. “Aporta muchísimo valor y nos permite ahorrar muchos pasos adicionales en el proceso”.
