- Présentation du processus et de la méthode de développement d’un bot Slack qui publie automatiquement du contenu sur un blog technique
- Processus de développement
-
- Établir un plan d’automatisation
- Premièrement, lors de la publication de contenu sur le blog technique, il a été décidé d’intégrer dans un nouvel outil (un bot Slack) les outils utilisés jusque-là (Notion, GitLab). L’objectif était d’aider les membres de l’équipe à s’adapter facilement et rapidement au nouveau système de publication
- Deuxièmement, il a été décidé d’utiliser un framework TypeScript. TypeScript est largement utilisé et, comme il s’agit d’un langage à typage statique, il permet un développement plus fiable. Cela facilite aussi la maintenance du nouveau système de publication de manière simple et pratique
- Troisièmement, prendre en charge des interactions conviviales pour l’utilisateur
- Pourquoi avoir choisi un bot Slack
- Le bot Slack répondait à tous ces principes
- Slack fournit un framework appelé
Bolt. Il prend en charge JavaScript, Java et Python, et la documentation est également bien faite. En s’y référant, il est facile de développer un outil d’automatisation de la publication d’un blog technique. Même en l’exécutant en environnement local, il est possible de tester l’outil dans l’application Slack
- Slack permet de concevoir l’interface visible par l’utilisateur grâce à la fonctionnalité
Block Kit. En concevant le flux d’écran en JSON et en traitant les données avec des fonctions, il devient possible de proposer des interactions intuitives
-
- Concevoir les écrans
- Slack prend en charge les messages et les modales pour interagir avec les utilisateurs
- Le workflow de publication de contenu sur le blog technique a été implémenté sous forme de modale
- Processus de publication sur le blog technique avec le bot Slack
- Publication du blog : choisir quel contenu publier et où le publier
- Validation du blog : vérifier que tous les éléments nécessaires au frontend, comme les métadonnées et l’image de couverture, sont bien présents dans le contenu à publier
- Vérification des issues/MR GitLab : étape de création d’une issue et d’une MR dans GitLab. Si une issue et une MR existent déjà, le commit est ajouté à la MR correspondante
- Message de fin : une fois la publication terminée, laisser un message incluant le lien vers le contenu source dans Notion et le lien vers la MR GitLab
-
- Concevoir et développer le bot
- L’objectif était de faire interagir un seul bot avec différents services comme Notion et GitLab
- Il a été jugé que cette approche serait plus avantageuse pour déployer l’application ou modifier le bot en créant un pipeline CI/CD dans GitLab
- Le développement du bot s’est appuyé sur le langage TypeScript et le framework
Bolt pris en charge par Slack
- La structure des dossiers a été adoptée en s’inspirant de NestJS
workflow.ts : définit les écrans et le flux de données, et constitue le point de départ de tous les workflows
service.ts : définit la logique métier
model.ts : définit les types de données pour Slack ou les API tierces
modal.ts : définit les écrans d’interaction avec l’utilisateur
-
- Mode de fonctionnement du bot
- Le bot est invoqué lorsqu’une commande est saisie dans n’importe quel canal Slack
- À ce moment-là, l’utilisateur choisit le titre du contenu dans Notion et le canal où le publier, puis en cliquant sur le bouton « Soumettre », le système vérifie automatiquement si les métadonnées obligatoires ont bien été renseignées
- Les métadonnées obligatoires incluent l’ID GitLab, le nom de l’auteur, le nom du fichier md, l’image de couverture,
<!--truncate-->, etc. Si l’un de ces éléments manque, le contenu ne peut pas être publié
- Si toutes les métadonnées obligatoires sont bien renseignées, il est possible de passer à l’étape suivante en cliquant sur le bouton « Continuer »
- À ce moment-là, une issue et une MR pour ce contenu sont automatiquement créées dans GitLab
- Un label est aussi ajouté automatiquement à la MR, et jusqu’au pipeline de publication du contenu, tout s’exécute automatiquement
- Une fois l’exécution du pipeline terminée, il est possible de vérifier à l’avance l’état de publication du contenu via l’application de revue GitLab
- Résultats de l’adoption
- La fréquence à laquelle les technical writers et les ingénieurs créent des MR pour publier du contenu sur le blog technique a augmenté d’environ 30 %
- Publier du contenu en moins d’une minute en un seul clic
- Le taux d’échec des pipelines est descendu sous les 5 %
Aucun commentaire pour le moment.