Comment l’équipe d’ingénierie chez IBM utilise Slack dans ses cycles de développement de produits

A woman working on a large computer.

Vous pouvez lire ce blog en anglaisallemand, et japonais.

Quels que soient les progrès accomplis la veille par Thomas Lawless (Ingénieur logiciel en chef chez IBM) ou par son équipe, chaque nouveau jour de travail commençait invariablement de la même façon. Il fallait vérifier s’il y avait ou non du code à passer en revue. « Nous avions l’impression de recommencer le même processus chaque matin », confie-t-il.

M. Lawless est chargé de superviser la production, le déploiement et la livraison de certaines des applications intranet les plus importantes d’IBM.
« Mes activités englobent le développement logiciel, l’intégration continue, l’automatisation de tests, l’automatisation du déploiement et les opérations », explique-t-il. « Cela signifie que je travaille tous les jours avec 40 ou 50 personnes différentes, qui appartiennent toutes à des équipes différentes ».

L’un des aspects essentiels du travail de Thomas Lawless est d’introduire des techniques de développement et des services destinés à améliorer les opérations et à réduire les délais de livraison. Cela fait un peu plus d’un an que Thomas Lawless utilise Slack comme plateforme de communication pour ses échanges avec d’autres équipes d’IBM. Toutefois, il a vite découvert que Slack était également un excellent outil pour collecter certaines données numériques, comme les alertes système et les notifications d’autres services.

« Nous avons élaboré un processus que nous nous plaisons à appeler “flux de livraison de bout en bout”. Il commence avec le code source et finit avec le déploiement », explique Thomas Lawless. « À présent, la puissance et la versatilité des flux de communication de Slack sont intégrées à chacun des étapes de ce processus ».

Gérer les processus de build et de déploiement grâce à Slack

Chez IBM, les équipes ont une préférence pour les chaînes publiques (par exemple, #équipe-développement), car elles permettent aux membres de l’équipe d’aborder des problèmes dans une discussion en cours et à des experts d’autres équipes d’intervenir et de donner leur avis.

Thomas Lawless

Thomas Lawless, Ingénieur logiciel en chef, IBM

Les chaînes consacrées à des équipes contiennent de messages provenant de personnes réelles, mais aussi des alertes système provenant des nombreuses applications qu’elles utilisent. Imaginons par exemple qu’un développeur décide de soumettre à révision un récit utilisateur dans le code source. Le système publie une notification dans la chaîne Slack de l’équipe qui informe tout le monde qu’un extrait de code est prêt à être passé en revue. La personne en charge de la révision peut directement accéder au code dans le système depuis le message Slack.

« Avant que nous adoptions Slack, un développeur devait trouver la personne qui lui semblait pertinente pour effectuer la révision, puis lui envoyer un e-mail ou démarrer un chat avec elle », explique Thomas Lawless.

Étant donné que leurs flux de travail sont intégrés à Slack, les équipes peuvent suivre le rythme de leur progression, tout en sachant que si des extraits de code doivent être passés en revue, les personnes concernées recevront une notification et pourront accéder aux fichiers directement depuis Slack.

Rassembler les équipes en cas d’alerte système pour une meilleure gestion des incidents

Voici un bref aperçu des chaînes d’équipes les plus populaires chez IBM, avec des exemples de conversations ou de notifications que l’on peut y trouver :

#aide-services : recueille les notifications de type « pull requests » pour faciliter les vérifications de code automatiques et alerter l’équipe quand la requête a été approuvée, ce qui évite aux membres de l’équipe de passer d’une application à l’autre pour accéder à la dernière mise à jour. L’équipe utilise également les outils d’intégration continue Jenkins et Travis pour prévenir les personnes concernées du changement de statut d’une nouvelle version.

#aide-déploiements : les membres d’une équipe sont informés des échecs de déploiement quand les changements de code passent par l’automatisation des tests.

#aide-tâches : des notifications sous forme de mémos sont publiées quand une erreur se produit dans les tâches de traitement par lots.

#suivi-starfleet : des notifications de NewRelic, de Splunk et de PagerDuty sont publiées sur cette chaîne pour le suivi de l’environnement d’exécution et pour la gestion des incidents.

« En quelque sorte, la chaîne joue un rôle de journal d’audit », poursuit Thomas Lawless. « Nous utilisons ces chaînes consacrées à des incidents comme support de notre analyse pour nos retours d’expérience. Rien n’est laissé au hasard car l’historique entier de l’incident est à portée de main ».

Thomas Lawless explique que, lorsqu’une notification signalant un échec ou un incident est publiée sur une chaîne Slack, les membres de l’équipe concernés créent une chaîne consacrée à cet incident dans laquelle ils peuvent discuter des mesures à adopter et inviter d’autres experts si besoin est.

Une fois le problème résolu, l’équipe dispose d’une véritable archive qui contient tous les détails de l’incident et notamment les fichiers, les captures d’écran, les messages d’erreur et les alertes qui ont pu être utilisés dans le processus de résolution du problème.

« En quelque sorte, la chaîne joue un rôle de journal d’audit », poursuit Thomas Lawless. « Nous utilisons ces chaînes consacrées à des incidents comme support de notre analyse pour nos retours d’expérience. Rien n’est laissé au hasard car l’historique entier de l’incident est à portée de main ».

Plus récemment, M. Lawless et son équipe ont commencé à utiliser Slack pour communiquer avec les fournisseurs des différents services qu’ils utilisent. Il a constaté que la plupart des entreprises acceptent volontiers de partager une chaîne privée pour discuter de toutes sortes de problèmes et de questions qui se présentent. Ce système évite à tout le monde d’interminables allers-retours entre les clients et les fournisseurs.

Des flux de communication centralisés et rationalisés pour des gains de productivité majeurs

Thomas Lawless et son équipe ont intégré Slack à chaque étape du processus de développement, de l’écriture et du test du code source initial jusqu’au déploiement final. Finis les matins consacrés à la recherche de code ! Tout le monde reprend son travail là où il l’a laissé la veille.

« À chaque fois que j’ai trouvé une nouvelle intégration Slack, je l’ai activée », confie Thomas Lawless. « Il y a tant à y gagner, et l’ensemble de nos intégrations nous ont déjà permis de décupler l’efficacité de nos processus ».

Slack is the collaboration hub, where the right people are always in the loop and key information is always at their fingertips. Teamwork in Slack happens in channels — searchable conversations that keep work organized and teams better connected.