Slack est l'épine dorsale de DevOps


Dans le cloud, DevOps est devenu le mot à la mode le plus populaire de l'industrie. Alors que les entreprises transfèrent leurs charges de travail vers le cloud, le besoin de transparence et de visibilité à travers vos équipes de développement et opérationnelles a créé des rôles de travail entièrement nouveaux pour les ingénieurs DevOps et les ingénieurs de fiabilité de site (inventés par Google) qui brouillent les frontières entre ceux-ci bien établis et historiquement. rôles distincts. Dans cet article, nous parlerons des outils qui sont essentiels à une chaîne d'outils DevOps réussie et comment Slack est la colle qui rassemble tout cela.
Gestion du code source
Bien qu'il existe de nombreux choix en matière d'outils de contrôle de source, la plupart des ingénieurs avec lesquels nous parlons ont standardisé Git pour le contrôle de version. Il existe une variété de saveurs allant du Github public aux solutions sur site telles que Gitlab et Github Enterprise. Tout au long de l'année, de nombreux rapports ont été publiés sur les entreprises et leurs contributions à l'open source et à l'hébergement de ces projets dans Github. Du point de vue de l'utilisation publique de Github, il y avait un excellent article qui parlait de la façon dont l'utilisation de Github en entreprise peut prédire si elles perturbent ou sont perturbées du point de vue technologique. Un exemple de cette perturbation est ce qui se passe chez IBM. IBM a adopté Github pour une utilisation en entreprise dans Bluemix pour leurs clients ainsi que pour leur propre déploiement interne, qui est l'un des plus grands déploiements de Github Enterprise à ce jour. Il suffit de dire que l'utilisation de Git reste l'outil de choix pour les développeurs.
Intégration continue / déploiement continu (CI / CD)
Lorsque nous commençons à parler de CI / CD, la conversation commence à couvrir une variété de chaînes d'outils allant de Jenkins et Travis-CI aux offres commerciales d'une variété de fournisseurs. Alors que la discussion se tourne vers les chaînes d'outils CI / CD natives dans le cloud, Travis-CI a pris les devants dans les solutions hébergées, le tableau ci-dessous présentant les principales options hébergées dans le cloud pour les chaînes d'outils de développeur.

Comme cet article se concentre sur DevOps avec une forte opinion d'opinion sur le développement natif du cloud et où nous voyons le marché se diriger, nous allons nous concentrer uniquement sur Travis-CI. La puissance de Travis-CI peut être directement liée à leur modèle de configuration (travis.yml) et à la façon dont la configuration est gérée par le contrôle de source Github, ce qui donne au développeur un contrôle total sur l'exécution de la construction, des tests, de la couverture du code et du déploiement. Si vous développez votre code dans Github public, la facilité d'introduction de Travis-CI dans votre flux de travail prend quelques minutes. Les développeurs adorent la possibilité de déclencher des builds à partir de demandes de tirage dans Github, puis de passer immédiatement à Travis-CI pour voir le résultat de la build et déployer tout en cours d'exécution dans le cloud.


Surveillance et alertes
Traditionnellement, les développeurs considèrent la section CI / CD de cet article comme la fin de leurs responsabilités. À ce stade, j'ai mon code sous contrôle de source et en collaboration avec l'équipe de build, j'ai une build avec un ensemble de tests qui prouvent que mon code fonctionne donc je suis prêt à livrer ce code aux clients. La responsabilité des opérations et des problèmes de débogage passe à une autre équipe. Dans le nouveau monde natif du cloud, la responsabilité de gérer l'intégrité de votre application qui s'exécute dans le cloud est revenue à l'équipe de développement. Les équipes ont adopté des outils tels que New Relic pour pouvoir comprendre rapidement la santé de leurs applications et capturer des mesures concernant le temps de réponse, les charges de travail et les taux d'échec. La plupart des équipes ont intégré des outils de surveillance tels que New Relic à des services tels que Pager Duty pour informer de manière proactive leurs équipes DevOps / SRE lorsque le système n'agit pas comme prévu.
Données et perspectives
Dans une section précédente, nous avons parlé de la puissance de Travis-CI et de son modèle de configuration et de la capacité des développeurs à avoir le pouvoir d'influencer le fonctionnement de la construction et des déploiements pour leurs projets. Le concept autour du codage social dans Github a permis un modèle où tous les développeurs ont accès à l'ensemble du flux de travail CI / CD et peuvent obtenir des informations sur la version la plus récente, fournir des commentaires sur les demandes d'extraction, valider les derniers résultats de test et quels sont les résultats actuels pour couverture de code. Lorsque la conversation se déplace vers des outils tels que New Relic et Pager Duty pour obtenir des mesures de performances et savoir quel développeur est sur appel, les données sont tout aussi perspicaces et pertinentes mais sont généralement dans un silo séparé car les données sont en dehors de la portée du CD / CI .


Audit Trail

Tous les outils mentionnés jusqu'à présent jouent chacun un rôle important dans le processus DevOps. La plupart des développeurs sont dans le présent et veulent des données en temps réel pour prendre des décisions rapidement et définitivement. Il est également très utile de connaître les détails historiques, en particulier lors d'une autopsie où l'équipe de développement tente de revenir en arrière pour comprendre pourquoi une panne s'est produite. Historiquement, nous avons passé du temps à essayer de corréler les journaux à partir d'outils tels qu'Elasticsearch pour comprendre l'état du système lorsque la nouvelle relique a capturé l'erreur, ce qui a entraîné une légende du service de téléavertisseur. Une fois que nous avons identifié le problème, il est maintenant temps d'aller sur Github et de voir quelle version de validation mappée à ce déploiement Travis-CI, puis de vérifier comment notre couverture de code a manqué ce chemin de code lors de nos tests. Ce processus peut être assez ardu et long et est très sujet aux erreurs.


Collaboration sociale


La collaboration sociale peut sembler tangentielle à notre discussion sur les chaînes d'outils et il y a environ deux ans, nous aurions probablement convenu. Cependant, l'adoption d'outils tels que Slack a introduit un énorme changement de paradigme dans la façon dont notre équipe de développement interagit aujourd'hui. Avec une main-d'œuvre répartie dans le monde entier, avoir la possibilité de démarrer rapidement une conversation Slack et d'avoir des interactions en temps réel avec vos coéquipiers devient au moins aussi important que les outils de développement que vous utilisez pour le contrôle des sources et la création.


Slack dans DevOps


Nous pensons qu'il est facile de s'entendre sur le fait que des outils tels que Slack sont d'excellents outils de collaboration et que les équipes ont afflué vers Slack pour la collaboration de groupe et bien sûr générer des GIF aléatoires à l'aide de giphy. Cependant, le véritable pouvoir de Slack est le sens de la communauté et nos équipes de développement y ont gravité en masse. Lorsque nous avons interrogé notre équipe de développement au début de l'année, l'outil le plus utilisé était Slack. Voyons maintenant pourquoi.
Alors que notre équipe a adopté Slack, nous avons commencé à voir comment nous pouvons éviter tous les changements de contexte qui se produisent tout au long de la journée et comment nous pouvons garder nos développeurs concentrés sur les choses les plus importantes qui comptent. Nous avons constaté que Slack est un excellent outil pour abattre les barrières et donner à toute notre équipe un accès complet à notre flux DevOps. Nous avons commencé initialement avec New Relic en publiant des événements sur notre chaîne DevOps chaque fois que nous voyions une augmentation du temps de réponse (nous voyions un service avec des problèmes intermittents et nos développeurs voulaient être informés lorsque cela se produisait). Nous avons ensuite configuré PagerDuty pour publier sur Slack lorsqu'un développeur était sur le point de commencer un quart de travail et également s'il y avait une légende. Cela a vraiment aidé nos développeurs à comprendre les problèmes de nos systèmes en cours d'exécution.
Notre équipe a vraiment apprécié la transparence de notre processus de développement et a voulu étendre la portée pour inclure les CD / CI. Nous avons rapidement commencé à ajouter des événements supplémentaires autour des événements de cycle de vie de développement tels que les validations git, les demandes d'extraction ainsi que les événements de génération et de déploiement à Slack, ce qui nous a permis de mesurer rapidement l'état de notre processus DevOps de bout en bout, de la validation du code aux environnements de déploiement. Maintenant, lorsque nos équipes participent à un post mortem, nous avons une piste d'audit complète de tout notre environnement au sein de Slack qui nous donne un historique complet de ce qui a contribué au problème et peut facilement revenir sur les validations faisant partie d'un déploiement donné, tout au sein de Mou.
Notre principale force motrice autour de l'adoption de Slack était la transparence et le fait d'avoir une excellente base de collaboration pour nos équipes de développement. Ce que nous avons appris, c'est que de nombreux autres membres de notre organisation pourraient bénéficier de cette transparence et aimeraient également avoir un aperçu de notre système. À ce stade, nous sommes passés à un modèle Chatbot et avons présenté Cloudbot qui était un bot interactif avec lequel les membres de l'équipe pouvaient discuter et obtenir des réponses à leurs questions. Pour réduire la courbe d'apprentissage, nous avons formé Cloudbot à être cognitif à l'aide d'IBM Watson. En rendant les commandes cognitives, les utilisateurs n'avaient pas besoin de comprendre les commandes exactes pour connaître l'état de nos applications et savoir quel était le dernier code déployé.
Conclusion
Bien qu'il existe de nombreux aspects de DevOps, nous pensons que la transparence est la clé pour avoir une culture florissante. À l'aide d'outils tels que Slack, les développeurs peuvent tirer parti des mêmes outils de collaboration qu'ils utilisent pour interagir avec les membres de l'équipe et également interagir avec leurs chaînes d'outils. En rendant Slack cognitif, les utilisateurs peuvent poser des questions aux autres membres de l'équipe ainsi qu'aux robots et obtenir des réponses en temps réel à leurs questions. Avec le récent partenariat annoncé entre Slack et IBM, nous pensons que l'avenir est prometteur pour Slack et Cognitive Chatbots où Slack continue d'être l'épine dorsale de DevOps (alias ChatOps).