Thomas Lawless, ingeniero jefe de software de IBM, y su equipo comenzaban cada día comprobando si había código que revisar, independientemente de lo productivo que hubiese sido el día anterior. “Era como si cada día tuviésemos que volver a empezar desde el principio”, explica.
Lawless es responsable de supervisar la producción, implementación y entrega de algunas de las mayores aplicaciones de la intranet de IBM. “Entre mis responsabilidades habituales están el desarrollo, la integración, la automatización de pruebas e implementaciones y las operaciones”, explica, “lo que se traduce en que, en un día cualquiera, trabajo con 40 o 50 personas, todas en distintos equipos”.
“Disponemos de lo que nos gusta llamar una 'canalización 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 Slack en todas las etapas clave de ese proceso”.
Un aspecto fundamental del trabajo de Lawless consiste en introducir técnicas y servicios de desarrollo que mejoren las operaciones y aceleren la entrega. Hace más de dos años comenzó a utilizar Slack con otros equipos de IBM para unificar las comunicaciones, pero pronto descubrió que Slack también sirve de repositorio de la comunicación no humana, como alertas de sistema y notificaciones de otros servicios.
“Disponemos de lo que nos gusta llamar una 'canalización 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 Slack en todas las etapas clave de ese proceso”.
Gestión de procesos de compilación e implementación en Slack
En IBM, los equipos se apoyan en canales abiertos de Slack (por ejemplo, #development-team) para comentar abiertamente incidencias y que expertos de otros equipos puedan unirse con facilidad y contribuir al debate.
Los canales de equipos contienen mensajes de personas, además de alertas de sistema procedentes de las numerosas aplicaciones que utilizan. 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 informándoles a todos de que hay código nuevo que revisar. El revisor, directamente desde el mensaje de Slack, entra en el sistema y revisa el código.
“Antes de que utilizáramos Slack, un desarrollador tenía que dar con el revisor y enviarle un correo electrónico o iniciar un chat personal con él”, explica Lawless.
Al tener centralizados en Slack los flujos de trabajo de los equipos, pueden mantener el ritmo de sus avances, sabiendo que recibirán una notificación por cada revisión de código que se necesite, a la que podrán dar respuesta directamente desde Slack.
Cohesión de equipos en torno a alertas de sistema para una gestión de incidencias más eficiente
Estos son algunos de los principales canales de los equipos de IBM y sus características:
#help-services: recopila notificaciones de pull requests para facilitar las revisiones automatizadas de código entre pares y alerta al equipo cuando la solicitud ha sido aprobada, ahorrándole a los miembros tener que cambiar de aplicación para ver la última actualización. El equipo también confía en su integración Jenkins/Travis CI, que le notifica cuándo cambia el estado de una compilación.#help-deployments: notifica a los miembros del equipo sobre implementaciones fallidas cuando los cambios de código avanzan en la automatización de pruebas.#help-tasks: publica una notificación cuando se produce un error en un trabajo de procesamiento por lotes.#starfleet-monitoring: aquí se publican las notificaciones de NewRelic, Splunk y PagerDuty para supervisar el tiempo de ejecución y gestionar incidencias.
“El canal funciona como una especie de mecanismo de auditoría”, explica 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 en Slack salta una alerta sobre un error o una incidencia, los correspondientes miembros del equipo crean un nuevo canal sobre la incidencia donde pueden hablar sobre posibles soluciones y donde cualquiera puede invitar a otros expertos si es necesario.
Cuando la incidencia ha sido resuelta, el equipo termina elaborando un registro detallado de ella que incluye todos los archivos, capturas de pantallas, mensajes de error y alertas que utilizaron hasta alcanzar la solución.
“El canal funciona como una especie de mecanismo de auditoría”, explica 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”.
Hace poco Lawless y su equipo han empezado a usar Slack con los proveedores de los distintos servicios que utilizan. Se han dado cuenta de que la mayoría de las empresas están encantadas de compartir con sus equipos un canal de Slack cerrado donde abordar los problemas y dudas que puedan tener, ahorrándoles el intercambio de correos electrónicos.
Menos pasos extra para ser más productivos
Lawless y su equipo han integrado 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 que revisar, todo el mundo sigue donde lo dejó el día anterior.
“Cada vez que veo una integración de Slack, la activo”, afirma Lawless. “Proporciona muchísimo valor y nos permite ahorrar muchísimos pasos extra en el proceso”.
