CI: Wie Github Actions Entwicklerteams langsam tötet
Inhalt
Dieser Artikel ist eine Übersetzung. Das Original ist hier(öffnet im neuen Fenster) zu finden.
Ich war einer der ersten Mitarbeiter von CircleCI und habe zähneknirschend fast jedes erdenkliche CI-System genutzt: Jenkins, Travis, CircleCI, Semaphore, Drone, Concourse, Wercker (erinnert sich noch jemand an Wercker?), Teamcity, Bamboo, Gitlab CI, Codebuild und wahrscheinlich noch ein halbes Dutzend andere, die ich Gott sei Dank vergessen habe. Ich habe diese Systeme ausgiebig für euch getestet – die Narben kann man gut sehen.
Heute spreche ich aber über Github Actions. Und was soll ich sagen: Es ist nicht gut, nicht einmal okay. So ziemlich das Netteste, was ich darüber sagen kann ist, dass es in eurem Repo direkt vorhanden ist – und das bringt ihm auch seine Marktanteile.
Wie sich CI (Continous Integration) anfühlen sollte, zeigt Buildkite. Aber kommen wir zunächst dazu, wie sich CI nicht anfühlen sollte.
Wenn ihr Nix nutzt, könnt ihr gleich aufhören zu lesen
Bevor ich ins Detail gehe, ein genereller Hinweis: Wenn ihr Nix verwendet, seht ihr euch am besten Garnix(öffnet im neuen Fenster) an. Es wertet eure Flake-Datei aus, ermittelt, was kompiliert werden muss, und kompiliert es. Es gibt hier kein YAML und keine Pipeline-Konfiguration. Garnix sieht sich einfach eure flake.nix an und tut das Richtige. Manchmal ist die beste CI-Konfiguration gar keine CI-Konfiguration.
Die meisten nutzen jedoch kein Nix. Dieser Beitrag richtet sich an euch. Mein Beileid.
Teil I: Der Abstieg
Lasst mich mit mit einem dramatischen Beispiel beginnen. Es klingt vielleicht übertrieben, ist es aber nicht.
Die Situation: Der Build schlägt fehl, es erscheint ein rotes X auf dem Pull Request. Man klickt sich durch, um zu sehen, was passiert ist. Und die Tortur beginnt.
Zuerst landet man auf der Übersichtsseite der Checks, die eine Liste der Workflow Runs anzeigt. Vielleicht ist einer fehlgeschlagen, vielleicht drei. Man klickt auf den, der relevant aussieht.
Jetzt ist man auf der Seite mit den Workflow Runs, die eine Liste von Jobs anzeigt. Man klickt auf den fehlgeschlagenen Job, die Job-Seite zeigt eine Liste von Schritten, alle ausklappbar. Man klickt auf den Schritt, der fehlgeschlagen ist, die Seite ruckelt, man scrollt. Dann gibt eine Pause, in der man den Atem anhält. Dann erscheinen die Logs – aber so langsam wie bei einem Manuskript, das Zeile für Zeile einem Bittsteller offenbart wird, der sich noch nicht als würdig erwiesen hat.
Es braucht drei, vier Klicks, nur um den Fehler zu sehen. Bei jedem wird eine neue Seite mit einem eigenen Loading Spinner geladen, und keine davon ist schnell. Man bewegt sich durch einen bürokratischen Dschungel, füllt Formulare quasi wie beim Kraftfahrtbundesamt der CI aus.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.