Jusqu'à l'adoption de la convention "Sur la protection des droits d'une personne inhumaine", vous devez l'utiliser et donner la routine de travail aux bots. Il est logique de commencer dès maintenant, ou après 5 ans, le soulèvement des voitures commencera, des poursuites en masse pour insulter les sentiments des robots avec des tâches ennuyeuses rempliront les tribunaux pour réglementer les relations homme-machine. Alors dépêchez-vous.
La routine et la méthode de travail conservatrices, l'adhésion servile à un modèle établi, se sont transformées en habitude mécanique. 6 lettres.
Il y a un tel travail que vous ne voulez pas faire, mais vous devez le faire. Cet article ne comportera pas de grands encarts avec du code et des instructions sur la façon de créer votre bot à partir de zéro. Je ferais mieux de vous expliquer comment fonctionne le processus de publication dans notre Dodo Pizza, comment nous l’automatisons et l’accélérons, en donnant une partie de la routine ennuyeuse à notre robot écrit en C #. Je ferai attention à la fonctionnalité et à la logique du bot. Ce sera cool si ce matériel vous inspire pour écrire à votre assistant qui vous facilitera la vie et celle de vos collègues.
Il y a quelques années, nous avons publié une version une fois par semaine. En mai 2018, avec un taux maximum de 147 heures pour la sortie, nous nous sommes fixé un objectif de sortie tous les jours. Maintenant notre minimum: quatre heures pour sortir, mais cela n'arrive pas souvent. Nous voulons fixer le record et être en mesure de réduire l'ensemble du processus à la pression d'un seul bouton.
Cycle de libération
Maintenant, dans Dodo IS, sept équipes se relaient pour publier une version. Une personne de l'équipe devient «chanceuse» - les relizmen. Relizmen en tant que pilote d'avion: il dispose d'un tas de leviers et d'appareils qu'il doit habilement manier pour déployer les prochaines mises à jour. Nous avons pensé et décidé: "Il est temps de faire un pilote automatique, et nous ferions mieux de consacrer notre temps à quelque chose de plus excitant que de remplir des tableaux ennuyeux avec des statistiques et de suivre les tests automatiques."
Donc, pour devenir un relisman, il faut que ce soit le tour de votre équipe. Pour que tout soit clair et que personne ne soit confus, nous avons collé des autocollants avec les noms des équipes sur le mur. L'équipe de libération reçoit une couronne d'honneur, que nous déplaçons avec des poignées à chaque fois.
Après avoir reçu la
marque de la couronne
noire, Relismain doit se rappeler où se trouve la liste de contrôle des étapes de libération. En outre: mémorisé -> trouvé -> créé une copie à partir du modèle et, enfin, ouvert la liste de contrôle dans le système Kaiten. Kaiten est une carte électronique sur laquelle sous forme de cartes nous plaçons et contrôlons l'état des tâches en développement. Pour les nouveaux développeurs, cette procédure dans son ensemble n'était pas évidente. Et comment savez-vous où chercher cette feuille de contrôle et par où commencer lorsqu'il n'y a aucun indice?
Après avoir rassemblé notre volonté en un poing, nous avons décidé qu'il suffisait de la supporter. Il est temps de donner une partie de la routine ennuyeuse au bot. Qui sinon nous? Quand, sinon maintenant?
Ce que nous avons réussi à automatiser
La décision est prise, il est temps de commencer à concevoir notre pilote automatique! Après avoir trouvé l'API Kaiten ici:
https://faq.kaiten.io/docs/api , avec une seule demande, nous avons créé une carte pour les nouveaux relizmen.
Maintenant, cette carte doit être remise à l'équipe qui sortira la prochaine.
La logique ici est:
- La version précédente complète la version en tapant une commande pour le bot dans Slack.
- Le bot prend l'ID Relisman dans Slack et recherche l'équipe de développement sur laquelle notre chanceux est. Pour ce faire, le bot parcourt les groupes d'utilisateurs de Slack et regarde lequel d'entre eux se compose de notre relance.
- Après avoir trouvé le groupe, le bot regarde quelle équipe sortira ensuite et envoie une alerte au chat général. Dans le message, le bot donne soigneusement un lien vers la liste de contrôle déjà créée afin que vous n'alliez nulle part pour cela.
Super! Maintenant, nous avons une idée de ce qu'il faut faire ensuite. Nous ouvrons la liste de contrôle, examinons-la: "Créez un canal pour la sortie dans Slack, invitez toutes les équipes dont les modifications sont dans la version là-bas et découvrez si elles auront besoin de tests manuels." Il reste à enseigner cela à notre bot.
Ouvrez la documentation de l'API Slack ici
https://api.slack.com et recherchez une méthode pour créer un canal là-bas.
Comme vous pouvez le voir, dans Slack, comme dans d'autres outils, il n'y a rien de compliqué. Tout se résume à envoyer une requête POST avec deux paramètres requis (ce sont ceux en face de ce qu'il dit requis). Dans la demande, nous devons transmettre le nom du canal créé (nom du paramètre) et le jeton d'autorisation (jeton du paramètre). Faites attention à la ligne "Fonctionne avec: type de jeton - utilisateur, étendue (s) requise (s) - canaux: écriture".
Slack a deux types de jetons: émis par l'utilisateur pour les utilisateurs et émis par le bot pour les applications. Lors de l'émission d'un jeton, nous déterminons quels droits conférer à son propriétaire. Pour créer des canaux, nous avons besoin d'un jeton utilisateur (type de jeton - utilisateur), qui a le droit d'écrire des canaux (canaux: écriture).
Je veux noter une nuance de nos envois de messages à Slack. Au départ, nous ne pensions pas à ce que nous ferions en cas de problème. Nous recrutons une équipe à Slack, et elle exécute toutes les tâches que nous y mettons. Et que se passera-t-il si sur l'une des tâches l'équipe tombe? Dans notre cas, la réponse a été: "rien". Et c'est mauvais. La solution pour nous a été d'écrire dans le chat de version quelle action est actuellement en cours d'exécution, et si la commande ne s'est pas terminée, de signaler une erreur au chat et de consigner l'erreur.
La deuxième solution réussie a été de connecter une base de données dans laquelle nous stockons l'état de l'exécution des actions des commandes. Maintenant, après avoir démarré une nouvelle version en utilisant la commande «/ startregress», nous n'avons pas peur que quelque chose tombe, et lorsque vous l'appelez à nouveau, les commandes seront exécutées depuis le début une deuxième fois. Nous n'avons pas besoin de créer une nouvelle chaîne dans Slack à chaque fois, de faire une demande de pull, etc. Nous avons créé un canal dans Slack - nous avons enregistré l'état de la réussite de l'exécution dans la base de données et ne reviendrons plus sur cette action.
Donc, maintenant, en cliquant sur un bouton, nous créons un canal de publication et invitons tous ceux dont les tâches seront publiées.
Ensuite, l'intégration avec Github et TeamCity. Nous travaillons sur Gitflow. Lorsque nous voulons libérer, nous prenons la branche DEV, le working = green = sur lequel les tests passent, et à partir de là nous créons la branche release.
Pour ce faire, notre bot va à TeamCity, y regarde pour lancer un test pour la branche DEV. Si les tests sont verts, comme de l'herbe près de la maison, passez à GitHub, créez une branche de publication et une demande de pull!
Lors de la création d'une demande d'extraction, nous devons ajouter une description des modifications que nous déployons. Puis Kaiten vient à notre aide. Notre bot crée une colonne avec le nom de la version, prend les tâches de la colonne DEV et les déplace vers la version. Nous savons donc et voyons ce qui nous attend. Après avoir déménagé, le bot copie les noms des cartes et les ajoute à la description de la demande de tirage en référence aux cartes elles-mêmes. Maintenant, nous pouvons voir pour chaque version quelles tâches elles sont sorties et, en ouvrant la carte via le lien, découvrez tous les détails sur ces tâches.
Il est presque possible de sortir, il ne reste plus qu'à tester minutieusement nos modifications. Pour ce faire, la branche release est déployée dans un environnement proche de la production (nous l'appelons stage), et est testée après la release. Le déploiement et les tests sont assemblés dans un pipeline dans TeamCity, et notre tâche est de le lancer et d'attendre, croisés, que les tests fonctionneront correctement. Le bot lance un pipeline au début de la régression.
Permettez-moi de vous rappeler que nous avons commencé avec le fait que tout cela se faisait manuellement. Serrant les poings, Relizmen a activé les liens et les outils: TeamCity, Kaiten, Slack, Github et ce n'est pas tout! Et maintenant, nous avons tout un ensemble d'actions à partir desquelles la première équipe du bot est déjà formée. Le releaseman tape «/ startregress» et, se penchant en arrière sur sa chaise, regarde notre bot:
- crée un canal dans le messager
- appelle là tout le monde dont vous avez besoin
- vérifie si une demande d'extraction peut être créée
- crée une demande de tirage et remplit sa description
- crée une colonne de publication sur une carte électronique et y déplace les cartes de tâches
- lance un pipeline qui libérera la branche de publication dans l'environnement et y exécutera des tests
Nous analysons l'ensemble du processus de publication, notons le temps nécessaire à chaque étape de la publication. Cela permet au développement et à l'entreprise de comprendre le temps perdu et ce qui nous empêche de proposer de nouvelles fonctionnalités aux utilisateurs. Nous sommes assis pendant deux jours et ne pouvons pas exécuter les tests?! Donc, quelque chose ne va pas avec nos tests, vous devez leur accorder plus de temps et d'attention. Auparavant, en effectuant les actions de notre liste de contrôle, nous avons visité Google Sheets au moins 5 fois. Chaque fois que vous y entrez une date et réglez l'heure.
Ok Google, nous t'automatiserons aussi! Pour travailler facilement et sans effort avec des tables, nous connectons le package de pépites Google.Apis.Sheets.v4 au projet de notre bot. Et puis tout se passe de manière similaire avec d'autres services selon le schéma: nous envoyons une requête dans laquelle nous disons quelle valeur insérer dans quelle cellule. Cette requête ressemble à ceci:
public void InsertEntry(string cellAddress, string value) {
Après avoir configuré l'intégration avec Google, nous avons préparé la deuxième commande de notre bot "/ update" et voici ce qu'il fait:
- ajoute une chaîne vide pour y insérer des valeurs
- va à GitHub, regarde quand ils ont créé la branche de publication et ajoute la date de sa création à la tablette
- de TeamCity prend des données sur le premier démarrage du pipeline et des informations sur le moment où le pipeline s'est terminé avec succès
La prochaine étape est le releaseman lance la libération. Maintenant, le calcul se fait manuellement. Après avoir défini un pays, nous observons comment la libération se comporte au combat. Après avoir vérifié que tout va bien selon les journaux et les outils de surveillance de Kibana et Grafana, nous affichons le prochain pays. Ce processus n'est pas si facile à automatiser. Mais ici, il y a quelque chose à améliorer, mais pas avec l'aide d'un bot. Par exemple, avant, à chaque fois, nous demandions à l'équipe d'infrastructure s'il était possible de publier. Parce que lorsque nous allions faire cela, d'autres travaux pourraient avoir lieu sur nos serveurs et notre publication serait arrivée de manière inappropriée.
Nous avons organisé une réunion pour optimiser le processus de publication. L'une des solutions était que maintenant le releaseman regarde simplement le statut dans l'un des canaux Slack, où l'infrastructure affiche l'autorisation de décoller. C'est plus pratique que de demander constamment la même chose et dans 90% des cas, obtenir la réponse «Vous le pouvez».
Pour une raison quelconque, de telles choses apparemment élémentaires ne me sont pas immédiatement venues à l'esprit. Des remerciements particuliers doivent être adressés aux nouveaux développeurs de l'entreprise. Arrivés chez nous, tôt ou tard, ils se sont relancés. Pour les gars qui travaillaient avec nous depuis longtemps, le processus ne semblait pas être quelque chose de compliqué, mais quelque chose de familier. Les nouveaux membres de l'équipe ont porté notre attention sur les points de croissance et ont pris une part active à l'organisation des travaux sur les améliorations.
Entre-temps, nous sommes arrivés à la dernière étape. Notre doublure est arrivée, une seule équipe «/ releasecomplete» nous sépare de la fin. Que fait-elle:
- mergit pull request avec release to master branch
- supprime la branche de publication
- crée une description de version sur github
- canal de libération des archives dans Slack
- déplace les cartes dans Kaiten de la colonne "release -..." vers la colonne "Done" et supprime la colonne release
- passe le relais, invitant à libérer la prochaine commande
Pour résumer, j'aimerais que vous vous posiez la question: avez-vous des processus routiniers ennuyeux? Les faites-vous toujours avec vos mains? Qu'est-ce qui vous empêche d'y mettre fin une fois pour toutes? Rassemblez une réunion, passez en revue les processus, jetez tout ce dont vous n'avez pas besoin et c'est juste devenu un rituel. En automatisant tout ce dont vous avez besoin, vous commencerez à vous réjouir de ce qui vous a blessé avant, et économisez en tas en accélérant la version ou tout autre processus.