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

Quels que soient les progrès accomplis la veille par Thomas Lawless (Ingénieur logiciel principal 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.

Thomas 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. « Ce qui 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. Il utilise Slack depuis plus d’un an 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 ce que nous aimons appeler un “flux de livraison de bout en bout” qui commence par le code source et va jusqu’à sa mise en production », déclare Thomas Lawless. « Désormais, Slack est intégré à toutes les étapes importantes de ce processus. »

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

Chez IBM, les équipes ont une préférence pour les canaux publics Slack (#équipe-développement, par exemple) car ils permettent à leurs membres de discuter ouvertement des problèmes rencontrés, et à des experts d’autres équipes de participer au débat et de donner leur avis.

Les canaux consacrés à des équipes contiennent des 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 le témoignage d’un utilisateur dans le code source. Le système publie une notification dans le canal Slack de l’équipe informant 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 une conversation 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 qu’elles recevront une notification si des extraits de code doivent être passés en revue 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 canaux 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 et alerter l’équipe quand la requête a été approuvée, évitant 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 informer 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 ce canal pour le suivi de l’environnement d’exécution et pour la gestion des incidents.

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

Une fois le problème résolu, l’équipe dispose d’un véritable enregistrement de l’ensemble de l’incident et notamment les fichiers, les captures d’écran, les messages d’erreur et les alertes utilisés dans le processus de résolution du problème.

« En quelque sorte, le canal joue un rôle de journal d’audit », déclare Thomas Lawless. « Nous utilisons ces canaux consacrés à 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, Thomas 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 un canal privé Slack pour discuter de toutes sortes de problèmes et de questions qui se présentent, leur évitant d’interminables allers-retours entre les différentes personnes concernées.

Des processus plus simples pour des gains de productivité considérables

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 », déclare Thomas Lawless. « Il y a tant à gagner, et l’ensemble de nos intégrations nous ont déjà permis de décupler l’efficacité de nos processus. »