Skip to main content
Vorgestellt von Collin für GoRails. Erneut veröffentlicht auf AppSignal am 19. September 2026. Rails 8.1 wird mit einem CI-Runner ausgeliefert. bin/ci führt Ihre Checks auf Ihrem eigenen Rechner aus, gesteuert von einem Skript unter config/ci.rb, das neue Anwendungen für Sie generieren. Ein gehosteter Runner ist oft langsamer als der Laptop, der bereits vor Ihnen steht. Bei vielen Projekten ist die Wartezeit das Einzige, was er hinzufügt. Die Arbeit wurde von Jeremy Daer bei 37signals geleitet.

​
Inhalt dieses Tutorials

  • config/ci.rb lesen und erweitern.
  • Die Suite mit bin/ci ausführen.
  • Einen erfolgreichen lokalen Lauf an einen GitHub-Pull-Request zurückmelden.

​
Voraussetzungen

​
Das CI-Skript

config/ci.rb listet die auszuführenden Schritte auf. Die generierte Version ruft Skripte auf, die bereits in bin vorhanden waren:
  • bin/setup bereitet die Umgebung vor.
  • bin/rubocop führt Style-Checks aus.
  • Bundler Audit prüft Gems auf bekannte Sicherheitslücken.
  • Importmap Audit macht dasselbe für JavaScript.
  • Die Test-Suite wird ausgeführt.
Hier ist nichts verborgen. Jeder Schritt ist ein gewöhnliches Skript in bin, lesbar und für sich allein ausführbar. Ein fehlgeschlagener Schritt lässt sich leicht isoliert reproduzieren. Fügen Sie Schritte für alles hinzu, was Ihr Projekt sonst noch braucht, und entfernen Sie die, die nicht zutreffen.

​
Ausführen

Die Ausgabe zeigt eine Zeile pro Schritt, mit einer Gesamtzeit am Ende. Bei einem Fehler wird der fehlgeschlagene Schritt benannt, Sie beheben ihn und führen den Lauf erneut aus. Ein vollständiger Durchlauf dauert bei einer kleinen Anwendung einige Dutzend Sekunden.

​
Einen Pull Request abzeichnen

Wenn CI lokal läuft, hinterlässt das bei GitHub keinen Nachweis, dass sie bestanden wurde. Die Freigabe-Integration schafft diesen Nachweis: Sie postet einen Status-Check an den Branch, der besagt, dass die Checks gelaufen sind und bestanden haben. Installieren Sie die GitHub CLI und anschließend die Erweiterung:
Aktivieren Sie anschließend den Freigabe-Block in config/ci.rb. Bei einem erfolgreichen Lauf zeichnet er den Commit ab, und der Check erscheint auf dem Pull Request. Bei einem fehlgeschlagenen Lauf tut er das nicht. Zwei Dinge sorgen beim ersten Mal für Verwirrung, und beide erzeugen dieselbe Meldung “sign-off failed”: Beide folgen derselben Regel: Die Freigabe bezeugt einen Commit, der im Remote existiert. Committen, pushen und dann bin/ci ausführen.

​
Was sich das für Ihr Monitoring ändert

CI auf die Rechner der Entwickler zu verlegen, entfernt einen Kontrollpunkt, der zugleich auch ein Nachweis war. Gehostete CI protokolliert jeden Lauf zu einem Commit; ein lokaler Runner tut das nicht, abgesehen vom Freigabe-Check. Legen Sie deshalb bewusst fest, welchen Nachweis Sie nach dem Deploy behalten:
  • Senden Sie bei jedem Deploy einen Deploy-Marker. Marker setzen in dem Moment, in dem eine Revision live geht, eine Linie in Ihre Diagramme. Außerdem gruppieren sie Fehler nach dem Deploy, der sie eingeführt hat. Bei lokaler CI ist der Marker häufig der erste dauerhafte Nachweis, der eine Revision mit einem Zeitpunkt verknüpft.
  • Beobachten Sie den Deploy, nicht den Build. Ein grüner lokaler Lauf und ein grüner Build-Server zeigen beide, dass Ihre Checks für den vorliegenden Code bestanden haben. Keiner von beiden sagt Ihnen, wie sich das Release verhalten hat. Vergleichen Sie Fehlerraten und Antwortzeiten rund um den Marker für die ersten Minuten nach einem Deploy.
  • Halten Sie die Checks ehrlich. bin/ci ist ein Skript, das Ihr Team bearbeiten kann. Ein Schritt, der auskommentiert wird, um etwas zu entblockieren, bleibt gerne auskommentiert. Prüfen Sie config/ci.rb genauso wie eine Workflow-Datei.

​
Transkript

Aus dem Video transkribiert und leicht bearbeitet. Die automatischen Untertitel haben mehrere Produkt- und API-Namen falsch verstanden, diese wurden korrigiert.
0:02 Hallo zusammen, willkommen zurück zu einer weiteren Lektion hier bei GoRails. Und in dieser hier schauen wir uns den lokalen CI-Runner an, der jetzt mit Rails 8.1 ausgeliefert wird. Wenn Sie also auf der Ruby on Rails.org-Seite den kleinen Beitrag dazu aufrufen, können Sie ein bisschen über die lokale CI sehen. Diese Arbeit wurde von Jeremy Daer geleitet, genau hier von 37signals. Und die Idee dahinter ist, dass Sie keinen, wissen Sie, Cloud-Computer brauchen, um Ihr CI-Setup auszuführen, wenn Sie es auch lokal auf einem Computer ausführen können.0:39 Das ist in vielen Fällen deutlich schneller, als es auf einem Cloud-Computer auszuführen. Sie sehen hier, dass bereits ein Standard-CI-Skript für Sie eingerichtet ist. Das liegt in config/ci.rb und wird über den Befehl bin/ci ausgeführt. Hier ist diese Datei, richtig? Das ist genau die Datei, wie sie mit Rails ausgeliefert wird.1:00 Und Sie sehen, dass es eine Reihe von Schritten gibt, die Sie bei Bedarf noch erweitern können. Aber es gibt hier einige, wissen Sie, grundlegende Schritte. Aber eigentlich rufen die alle nur andere bin-Skripte in Ihrer Anwendung auf, die Dinge erledigen wie zum Beispiel das Einrichten der Entwicklungsumgebung, das Ausführen von RuboCop gegen Ihren Code, das Ausführen von Bundler Audit, Importmap Audit, und so weiter und so fort. Sie sehen also hier, dass Ihre Tests ausgeführt werden. Und jetzt gibt es auch eine optionale GitHub-Integration hier, die Pull Requests für Sie abzeichnen kann.1:33 Sagen wir, hey, CI ist gelaufen. Dieser Pull Request ist bereit. Sie können ihn mergen, wenn Sie möchten. Natürlich könnten Sie diese Nachricht bearbeiten, aber das ist die Standardnachricht. Und um das zu nutzen, müssen Sie außerdem diese Erweiterung von Basecamp installieren, die gh-signoff-Erweiterung.1:49 Und, wissen Sie, es ist hier ziemlich einfach. Wenn die CI erfolgreich ist, zeichnet sie das ab und sagt, es ist alles gut. Andernfalls lässt sie es fehlschlagen und sagt, hey, das nicht mergen. Da muss zuerst noch etwas behoben werden. Schauen wir uns das also mal in der Praxis an.2:03 Ich habe gerade eine Anwendung, in der wir das CI-Skript hier haben. Ich habe die GitHub-Sachen momentan auskommentiert. Lassen Sie uns das einfach mal ausführen und schauen, wie das aussieht. Also gut, ich führe jetzt einfach den Befehl bin/ci hier aus. Und wir sehen, das führt jetzt alle die Schritte aus, die in dieser config/ci.rb-Datei definiert sind.2:22 Sie sehen hier, dass wir einen Fehler haben. Ich gehe gleich noch mal nach oben. Irgendetwas mit dem Importmap-Audit ist aus irgendeinem Grund fehlgeschlagen, das schauen wir uns gleich an. Hier unten sehen Sie also den einen Fehler, den wir hatten, also ist die Continuous Integration in 20,23 Sekunden fehlgeschlagen, was ziemlich schnell ist. Und wenn wir wieder nach oben scrollen, sehen wir hier unseren einen Fehler.2:44 Es gibt ein Importmap-Sicherheits-Audit, das fehlgeschlagen ist. Schauen wir uns das an und sehen, was das Problem ist. Wir können das in unserem Code beheben und die CI dann erneut ausführen. Das mache ich jetzt gleich. Also gut, lassen Sie uns die CI jetzt noch mal ausführen und sehen, ob sie besteht oder fehlschlägt oder irgendetwas anderes passiert.2:57 Okay, so haben wir unser Importmap-Audit bestanden. Das ist also gut. Wir sollten jetzt eigentlich alles im grünen Bereich haben, denn ich glaube, das war der einzige Fehler, den wir hatten. Wir haben hier zwar noch ein paar Duplikationswarnungen, aber okay, jetzt sehen wir, dass die Continuous Integration in diesem Lauf bestanden hat.3:14 Das ist also schön und gut für uns lokal. Aber was, wenn wir das auf GitHub kommunizieren müssen? Wir öffnen einen Pull Request. Ich habe also eine kleine Änderung an der README für diesen Code vorgenommen, nichts Großes. Wir nutzen das nur als Beispiel, um die CI auszuführen.3:27 Um die gh-signoff-Sachen zu nutzen, brauchen wir also wieder die installierte GitHub CLI und diese Basecamp-Erweiterung. Ich habe die GitHub CLI bereits installiert. Ich zeige Ihnen das, indem ich hier einfach gh ausführe, und wir sehen, dass das tatsächlich die CLI von GitHub ist. Das Einzige, was wir also noch installieren müssen, ist diese Erweiterung hier, die ich noch nicht installiert habe. Kopieren wir also diesen Befehl und führen ihn aus.3:53 Also installieren wir jetzt diese gh-signoff-Erweiterung von Basecamp. Okay, gut. Das ist also erledigt. Und jetzt kommentieren wir die Bedingung hier ein. Okay, speichern.4:05 Und jetzt lassen Sie uns unsere CI hier noch mal ausführen. Jetzt, wo die CI diesmal gelaufen ist, sehen wir, dass die Freigabe fehlgeschlagen ist. Und der Grund dafür ist, dass ich zwar einen Branch für die Aktualisierung der README erstellt habe, aber wir haben hier lokal nicht committete und nicht gepushte Änderungen. Wir müssen diese Dinge also zuerst committen. Ich schaue mir also kurz mal den git status an.4:27 Und dann, ja, das sieht gut aus. Fügen wir das alles hinzu und committen es. Wir sagen: README aktualisieren und GitHub CLI in CI aktivieren. Okay, jetzt sind wir also gut aufgestellt. Sollte hier alles bereit sein.4:46 Und jetzt führen wir den Befehl bin/ci noch mal aus. Und schauen wir, was diesmal passiert. Okay, es ist wieder fehlgeschlagen. Wir haben unsere Änderungen committet, aber sie noch nicht gepusht. Wir sehen hier also, dass das wahrscheinlich in diese Kategorie fällt, dass wir immer noch nicht gepushte Änderungen haben.5:02 Pushen wir das also. Ich öffne das hier mal. Und dann fügen wir einfach eine Beschreibung hinzu. Es ist ein ganz einfacher Test der neuen lokalen CI in Rails 8.1. Erstellen wir also hier einen Pull Request.5:15 Führen wir jetzt noch mal bin/ci aus. Schauen wir, was passiert. Okay, jetzt sehen wir, dass wir, nachdem wir die Änderungen committet und gepusht haben, diese erfolgreiche Freigabe bekommen. Wir sehen hier also, dass der Commit abgezeichnet wurde. Und dann bekommen wir die Nachricht, wissen Sie, Freigabe erteilt, alle Systeme bereit für Merge und Deploy, bestanden in, wissen Sie, 0,8 Sekunden, Continuous Integration insgesamt bestanden in 23,37 Sekunden.5:43 Und wenn wir jetzt zurück zu GitHub kommen und hier nach unten scrollen, sehen wir, wenn wir uns den Bereich Checks anschauen, dass der Freigabe-Check tatsächlich, wissen Sie, auf den Branch gepusht wurde. Es steht dort, dass abgezeichnet wurde, und wir haben den Check. Also ist alles bereit, oder? Jetzt, wo diese lokale CI gelaufen ist, können wir das also zusammen mit der GitHub CLI nutzen, um Checks abzuzeichnen und zu sagen, wissen Sie, hey, wir haben das lokal ausgeführt, alles ist erfolgreich durchgelaufen, und wir können mergen. Wir müssten also eigentlich nichts von dem hier noch mal machen.6:20 Weil wir das alles schon lokal gemacht haben. Wir müssen das nicht noch mal in der GitHub-CI hier machen. Also ziemlich coole Sache. Sobald das alles koordiniert ist, ist die Freigabe-Sache wirklich cool. Und außerdem ist der ganze Code hier im CI-Skript etwas, das Sie selbst ausführen, erweitern und sich ansehen können, wissen Sie, Sie können sich jede dieser Dateien anschauen, die Setups in Ihrer Rails-App.6:44 Also RuboCop. Die liegen alle im bin-Verzeichnis in Ihrer Rails-Anwendung, direkt hier. Wissen Sie, die Bundler-Sachen können Sie auch selbst ausführen. Aber ich meine, das ist alles hier verfügbar. Wenn Sie sich den Code dazu ansehen müssen, gehen Sie einfach zu einer dieser Dateien in bin, und Sie sehen, sie sind alle hier.7:01 Zum Beispiel gibt es ein Setup, RuboCop direkt darüber. Bundler Audit ist auch dabei. Also wirklich coole Sachen hier mit der lokalen CI-Erweiterung in Rails 8.1. Also auf jeden Fall würde ich sagen, schauen Sie es sich an, probieren Sie, ob es für Sie funktioniert. Vielleicht können Sie einen Teil Ihres CI-Setups straffen und einfach auf das hier umsteigen und vielleicht ergänzen, was Sie brauchen, oder weglassen, was Sie nicht brauchen, wie auch immer Sie möchten, wissen Sie?7:26 In diesem Sinne, ich hoffe, Ihnen hat diese Lektion gefallen, und ich sehe Sie beim nächsten Mal.

​
Über dieses Tutorial

Dieses Tutorial fasst einen GoRails-Screencast über den lokalen CI-Runner in Rails 8.1 zusammen, vorgestellt von Collin. Der Screencast ist das Originalwerk. GoRails veröffentlicht ihn und den Rest der Serie unter gorails.com.