Bis die Konvention "Zum Schutz der Rechte einer unmenschlichen Person" verabschiedet wurde, müssen Sie diese verwenden und den Bots die Arbeitsroutine geben. Es ist sinnvoll, sofort zu beginnen, oder nach 5 Jahren wird der Aufstand der Autos beginnen. Massenklagen, um die Gefühle von Bots mit langweiligen Aufgaben zu beleidigen, werden die Gerichte für die Regulierung der Mensch-Maschine-Beziehungen überfluten. Also beeil dich.
Konservative Routine und Arbeitsweise, sklavische Einhaltung eines festgelegten Musters, wurden zu einer mechanischen Gewohnheit. 6 Buchstaben.
Es gibt solche Arbeiten, die Sie nicht machen wollen, aber Sie müssen. Dieser Artikel enthält keine großen Beilagen mit Code und Anweisungen zum Erstellen Ihres Bots von Grund auf neu. Ich möchte Ihnen besser sagen, wie der Veröffentlichungsprozess in unserer Dodo Pizza funktioniert, wie wir ihn automatisieren und beschleunigen und unserem in C # geschriebenen Bot etwas von der langweiligen Routine geben. Ich werde auf die Funktionalität und Logik des Bots achten. Es wird cool sein, wenn dieses Material Sie dazu inspiriert, Ihren Assistenten zu schreiben, der Ihnen und Ihren Kollegen das Leben leichter macht.
Vor ein paar Jahren haben wir einmal pro Woche eine Veröffentlichung veröffentlicht. Im Mai 2018 haben wir uns mit einer maximalen Veröffentlichungsrate von 147 Stunden das Ziel gesetzt, jeden Tag freizugeben. Jetzt unser Minimum: vier Stunden bis zur Veröffentlichung, aber das kommt nicht oft vor. Wir möchten den Datensatz korrigieren und den gesamten Prozess auf einen einzigen Knopfdruck reduzieren können.
Freigabezyklus
Jetzt in Dodo IS veröffentlichen sieben Teams abwechselnd eine Veröffentlichung. Eine Person aus dem Team wird „glücklich“ - Relizmen. Relizmen als Flugzeugpilot: Er verfügt über eine Reihe von Hebeln und Geräten, die er geschickt einsetzen muss, um die nächsten Updates einzuführen. Wir dachten und entschieden: "Es ist Zeit, einen Autopiloten zu machen, und wir verbringen unsere Zeit besser mit etwas Aufregenderem, als langweilige Tabellen mit Statistiken auszufüllen und automatische Testläufe zu verfolgen."
Um ein Relisman zu werden, ist es also notwendig, dass Ihr Team an die Reihe kommt. Damit alles klar war und niemand verwirrt war, klebten wir Aufkleber mit den Namen der Teams an die Wand. Das Release-Team erhält eine Ehrenkrone, die wir jedes Mal mit Griffen bewegen.
Nach Erhalt der
schwarzen Kronenmarkierung muss sich Relismain merken, wo die Checkliste der Freigabeschritte liegt. Weiter: erinnert -> gefunden -> eine Kopie aus der Vorlage erstellt und schließlich die Checkliste im Kaiten-System geöffnet. Kaiten ist eine elektronische Tafel, auf die wir in Form von Karten legen und den Status von Aufgaben in der Entwicklung überwachen. Für neue Entwickler war dieses Verfahren insgesamt sehr offensichtlich. Und woher wissen Sie, wo Sie nach diesem Kontrollblatt suchen und wo Sie anfangen müssen, wenn es keine Hinweise gibt?
Nachdem wir unseren Willen zu einer Faust zusammengefasst hatten, entschieden wir, dass es genug war, um ihn zu ertragen. Es ist Zeit, dem Bot etwas von der langweiligen Routine zu geben. Wer wenn nicht wir? Wann, wenn nicht jetzt?
Was wir automatisieren konnten
Die Entscheidung wurde getroffen, es ist Zeit, mit der Entwicklung unseres Autopiloten zu beginnen! Nachdem wir die Kaiten-API hier gefunden haben:
https://faq.kaiten.io/docs/api , haben wir mit nur einer Anfrage eine Karte für die neuen Relizmen erstellt.
Jetzt muss diese Karte an das Team übergeben werden, das die nächste freigibt.
Die Logik hier ist:
- Die vorherige Version vervollständigt die Version, indem Sie in Slack einen Befehl für den Bot eingeben.
- Der Bot nimmt die Relisman ID in Slack und sucht, in welchem Entwicklungsteam sich unser Glückspilz befindet. Zu diesem Zweck durchläuft der Bot die Slack-Benutzergruppen und prüft, aus welchen von ihnen unser releisen besteht.
- Nachdem der Bot die Gruppe gefunden hat, prüft er, welches Team als nächstes freigegeben wird, und sendet eine Warnung an den allgemeinen Chat. In der Nachricht gibt der Bot sorgfältig einen Link zu der bereits erstellten Checkliste an, damit Sie nirgendwo hingehen.
Großartig! Jetzt haben wir eine Ahnung, was als nächstes zu tun ist. Wir öffnen die Checkliste und sehen sie uns an: "Erstellen Sie einen Kanal für die Veröffentlichung in Slack, laden Sie alle Teams ein, deren Änderungen in der Veröffentlichung enthalten sind, und finden Sie heraus, ob sie manuelle Tests benötigen." Es bleibt unserem Bot dies beizubringen.
Öffnen Sie die Slack-API-Dokumentation hier
https://api.slack.com und suchen Sie nach einer Methode zum Erstellen eines Kanals.
Wie Sie sehen können, gibt es in Slack wie in anderen Tools nichts Kompliziertes. Es kommt darauf an, eine POST-Anfrage mit zwei erforderlichen Parametern zu senden (dies sind die entgegengesetzten, die als erforderlich bezeichnet werden). In der Anfrage müssen wir den Namen des erstellten Kanals (Parametername) und das Autorisierungstoken (Parametertoken) übergeben. Beachten Sie die Zeile "Funktioniert mit: Token-Typ - Benutzer, erforderliche Bereiche - Kanäle: Schreiben".
Slack hat zwei Arten von Token: Benutzer, die an Benutzer ausgegeben werden, und Bot, die an Anwendungen ausgegeben werden. Bei der Ausstellung eines Tokens legen wir fest, welche Rechte zur Übertragung des Eigentümers gelten. Zum Erstellen von Kanälen benötigen wir ein Benutzertoken (Tokentyp - Benutzer), das zum Schreiben von Kanälen berechtigt ist (Kanäle: Schreiben).
Ich möchte eine Nuance unserer Nachrichten an Slack erwähnen. Anfangs haben wir nicht darüber nachgedacht, was wir tun würden, wenn etwas schief gehen würde. Wir rekrutieren ein Team in Slack, das alle Aufgaben ausführt, die wir ihm gestellt haben. Und was passiert, wenn das Team bei einer der Aufgaben fällt? In unserem Fall war die Antwort: "nichts". Und das ist schlecht. Die Lösung für uns bestand darin, im Release-Chat zu schreiben, welche Aktion gerade ausgeführt wird. Wenn der Befehl nicht ausgeführt wurde, melden Sie einen Fehler im Chat und protokollieren Sie den Fehler.
Die zweite erfolgreiche Lösung bestand darin, die Datenbank zu verbinden, in der wir den Status der Ausführung der Aktionen der Befehle speichern. Nachdem wir nun eine neue Version mit dem Befehl "/ startregress" gestartet haben, haben wir keine Angst, dass etwas herunterfällt, und wenn Sie es erneut aufrufen, werden die Befehle von Anfang an ein zweites Mal ausgeführt. Wir müssen nicht jedes Mal einen neuen Kanal in Slack erstellen, eine Pull-Anfrage stellen usw. Wir haben in Slack einen Kanal erstellt. Wir haben den Status der erfolgreichen Ausführung in der Datenbank aufgezeichnet und werden nicht mehr zu dieser Aktion zurückkehren.
Durch Klicken auf eine Schaltfläche erstellen wir nun einen Freigabekanal und laden alle dort ein, deren Aufgaben freigegeben werden.
Als nächstes folgte die Integration mit Github und TeamCity. Wir arbeiten an Gitflow. Wenn wir freigeben möchten, nehmen wir den DEV-Zweig, das Working = Green =, auf dem die Tests bestanden werden, und erstellen daraus den Freigabezweig.
Dazu geht unser Bot zu TeamCity und sucht dort einen Testlauf für den DEV-Zweig. Wenn die Tests grün sind, wie Gras in der Nähe des Hauses, gehen Sie zu GitHub, erstellen Sie einen Release-Zweig und eine Pull-Anfrage!
Beim Erstellen einer Pull-Anforderung müssen wir eine Beschreibung der Änderungen hinzufügen, die wir einführen. Dann kommt uns Kaiten zu Hilfe. Unser Bot erstellt eine Spalte mit dem Namen der Version, übernimmt Aufgaben aus der DEV-Spalte und verschiebt sie in die Version. So wissen und sehen wir, was mit uns gemahlen wird. Nach dem Verschieben kopiert der Bot die Namen der Karten und fügt sie der Pull-Request-Beschreibung unter Bezugnahme auf die Karten selbst hinzu. Jetzt können wir für jede Version sehen, welche Aufgaben ausgeführt wurden, und durch Öffnen der Karte über den Link alle Details zu diesen Aufgaben herausfinden.
Es ist fast möglich zu veröffentlichen, es bleibt nur, um unsere Änderungen gründlich zu testen. Zu diesem Zweck wird der Release-Zweig in einer Umgebung in der Nähe der Produktion bereitgestellt (wir nennen ihn Phase) und nach dem Release getestet. Die Bereitstellung und die Tests werden in TeamCity in einer Pipeline zusammengefasst. Unsere Aufgabe besteht darin, sie zu starten und mit gekreuzten Fingern darauf zu warten, dass die Tests ordnungsgemäß funktionieren. Der Bot startet zu Beginn der Regression eine Pipeline.
Ich möchte Sie daran erinnern, dass wir damit begonnen haben, dass dies alles manuell gemacht wurde. Relizmen ballte die Fäuste und schaltete Links und Tools ein: TeamCity, Kaiten, Slack, Github und das ist noch nicht alles! Und jetzt haben wir eine ganze Reihe von Aktionen, aus denen das erste Team für den Bot bereits gebildet ist. Der Auslöser gibt "/ startregress" ein und lehnt sich in seinem Stuhl zurück und beobachtet, wie unser Bot:
- Erstellt einen Kanal im Messenger
- ruft dort alle an, die Sie brauchen
- prüft, ob eine Pull-Anfrage erstellt werden kann
- Erstellt eine Pull-Anfrage und füllt deren Beschreibung aus
- Erstellt eine Freigabespalte auf einer elektronischen Tafel und verschiebt dort Aufgabenkarten
- Startet eine Pipeline, die den Release-Zweig für die Umgebung freigibt und dort Tests ausführt
Wir analysieren den gesamten Release-Prozess und schreiben auf, wie viel Zeit jede Phase der Veröffentlichung benötigt. Dies gibt der Entwicklung und dem Unternehmen ein Verständnis dafür, welche Zeit verschwendet wird und was uns daran hindert, Benutzern neue Funktionen bereitzustellen. Wir sitzen zwei Tage und können die Tests nicht durchführen ?! Mit unseren Tests stimmt also etwas nicht. Sie müssen ihnen mehr Zeit und Aufmerksamkeit widmen. Zuvor haben wir bei der Durchführung der Aktionen unserer Checkliste mindestens fünf Mal Google Sheets besucht. Jedes Mal, wenn Sie dort ein Datum eingeben und die Uhrzeit einstellen.
Ok, Google, wir automatisieren Sie auch! Um einfach und mühelos mit Tabellen arbeiten zu können, verbinden wir das Nuget-Paket Google.Apis.Sheets.v4 mit dem Projekt unseres Bots. Und dann geschieht alles auf ähnliche Weise mit anderen Diensten gemäß dem Schema: Wir senden eine Anfrage, in der wir angeben, welcher Wert in welche Zelle eingefügt werden soll. Diese Abfrage sieht folgendermaßen aus:
public void InsertEntry(string cellAddress, string value) {
Nachdem wir die Integration mit Google eingerichtet haben, haben wir den zweiten Befehl unseres Bots "/ update" vorbereitet.
- Fügt eine leere Zeichenfolge hinzu, um Werte einzufügen
- Geht zu GitHub, schaut nach, wann der Release-Zweig erstellt wurde, und fügt dem Tablet das Erstellungsdatum hinzu
- Von TeamCity werden Daten zum ersten Start der Pipeline und Informationen zum erfolgreichen Abschluss der Pipeline abgerufen
Der nächste Schritt ist, dass der Auslöser die Freigabe würfelt. Jetzt erfolgt die Berechnung manuell. Nachdem wir ein Land angelegt haben, beobachten wir, wie sich die Veröffentlichung im Kampf verhält. Nachdem wir sichergestellt haben, dass gemäß den Protokollen und Überwachungstools von Kibana und Grafana alles in Ordnung ist, veröffentlichen wir das nächste Land. Dieser Prozess ist nicht so einfach zu automatisieren. Aber hier gibt es etwas zu verbessern, wenn auch nicht mit Hilfe eines Bots. Zum Beispiel haben wir zuvor jedes Mal das Infrastruktur-Team gefragt, ob eine Freigabe möglich ist. Denn wenn wir dies tun würden, könnten andere Arbeiten auf unseren Servern stattfinden und unsere Veröffentlichung wäre unangemessen eingegangen.
Wir haben ein Meeting zusammengestellt, um den Release-Prozess zu optimieren. Eine der Lösungen war, dass der Auslöser jetzt einfach den Status in einem der Slack-Kanäle überprüft, in denen die Infrastruktur die Erlaubnis zum Abheben veröffentlicht. Dies ist bequemer, als ständig dasselbe zu fragen und in 90% der Fälle die Antwort „Sie können“ zu erhalten.
Aus irgendeinem Grund kamen solche scheinbar elementaren Dinge nicht sofort in den Sinn. Besonderer Dank gilt den neuen Entwicklern im Unternehmen. Früher oder später zu uns gekommen, wurden sie zu Relismen. Für die Leute, die lange mit uns zusammengearbeitet haben, schien der Prozess nicht kompliziert, sondern vertraut zu sein. Neue Teammitglieder haben unsere Aufmerksamkeit auf Wachstumspunkte gelenkt und sich aktiv an der Organisation der Arbeit an Verbesserungen beteiligt.
In der Zwischenzeit sind wir zur letzten Etappe gekommen. Unser Release Liner ist gelandet, nur ein "/ releasecomplete" -Team trennt uns vom Ende. Was macht sie:
- Pull-Anforderung zusammenführen mit Freigabe an Hauptzweig
- Entfernt den Release-Zweig
- Erstellt eine Release-Beschreibung auf Github
- Archivfreigabekanal in Slack
- Verschiebt die Karten in Kaiten aus der Spalte "Release -..." in die Spalte "Fertig" und löscht die Release-Spalte
- Übergibt den Staffelstab und lädt ein, den nächsten Befehl freizugeben
Zusammenfassend möchte ich, dass Sie sich die Frage stellen: Haben Sie langweilige Routineprozesse? Machst du sie immer noch mit deinen Händen? Was hindert Sie daran, dies ein für alle Mal zu beenden? Treffen Sie sich, besprechen Sie Prozesse, werfen Sie alles weg, was Sie nicht brauchen, und es wird einfach zu einem Ritual. Wenn Sie alles automatisieren, was Sie brauchen, werden Sie die Freude an dem haben, was vorher wehgetan hat, und bis zum Haufen sparen, indem Sie die Veröffentlichung oder andere Prozesse beschleunigen.