Automatisierung ist eine tolle Sache. „Wenn man etwas mehr als einmal macht, sollte man ein Skript schreiben“. Natürlich sind sie immer ein Ort für schnelle und schmutzige Hacks für „genau hier und jetzt“.
Sie lösen ein bestimmtes Problem und geben Ihnen die Möglichkeit, sich auf wichtigere Dinge zu konzentrieren. Aber wenn eine Routine anfängt, zu viel Ihrer Zeit zu beanspruchen… Dann ist vielleicht genau der richtige Zeitpunkt gekommen, um den Prozess zu automatisieren.
Es ist sowieso ein Gleichgewicht.
Mein Team arbeitet an einem CityFALCON-Projekt, einem sich schnell entwickelnden Fintech-Startup. Es handelt sich um ein Ökosystem aus mehreren Rails-Anwendungen: die Hauptwebsite und einige Dienste. In einer bestimmten Phase mussten wir eine weitere Version derselben Rails-Webanwendung erstellen, allerdings mit einer etwas anderen Struktur von Controllern, Routen und Ansichten.
Während wir überlegten, welcher Weg der neuen Anwendungsstruktur der beste wäre, um diese beiden Versionen nebeneinander existieren zu lassen, entschieden wir uns, schnell und schmutzig zu werden und einfach die neue Anwendung von unserem Master zu verzweigen.
Aus Gründen, die sich unserer Kontrolle entziehen, konnten wir den Code des Edelsteins zu diesem Zeitpunkt nicht in die Anwendung einbauen.
So kamen wir zu folgendem Setup: Die Anwendung hatte die Zweige „master“ und „v2“, die über Gemfile mit den Zweigen „master“ bzw. „v2“ von gem verknüpft waren. Und dann trat das Problem auf.
Wir mussten in der Lage sein, schnell zwischen diesen Versionen zu wechseln. Jeder solche Wechsel erforderte 2 Git-Checkouts in den entsprechenden Verzeichnissen, nachdem sichergestellt wurde, dass beide Arbeitskopien sauber sind oder alle Änderungen vor dem Wechsel gespeichert wurden. Es war ziemlich einfach, dies manuell durchzuführen, aber bald wurde es zu einer Prozedur, die mehrmals am Tag durchgeführt werden musste.
Das war der Moment, in dem die Automatisierung auf den Plan trat. Die naheliegendste Lösung waren benutzerdefinierte Git-Befehle – eine sehr praktische Funktion, mit der Sie Ihren Git-Workflow nach Belieben erweitern können. Obwohl es interessant war, sich in die Bash-Skripterstellung zu vertiefen und eine leichte Brise des Perl-Wahnsinns zu spüren :), merkten wir bald, dass unsere mangelnde Erfahrung in diesem Bereich ein Hindernis für uns war.
Und wir waren erstaunt, dass uns das nicht als erstes in den Sinn gekommen ist. Lasst uns alles in Ruby (um)schreiben! Wir nannten unseren eigenen Befehl git checkout. So sieht er im Moment des Schreibens aus:
Die Datei util.rb enthält Code, der von verschiedenen benutzerdefinierten Befehlen gemeinsam genutzt wird (wir haben ein paar zusätzliche benutzerdefinierte Befehle zusammen mit diesem implementiert). Hier ist ein Auszug daraus:
Unsere Befehle machen Gebrauch von Dotenv. Zum Beispiel wird der Pfad zum gem-Verzeichnis (um dorthin wechseln zu können) in der .env-Datei gespeichert. Sie erlaubt es uns, jede beliebige Konfiguration für diese Befehle hinzuzufügen, und sie wird im Projekt selbst enthalten sein.
Wir haben also nicht viel Zeit damit verbracht, ein Tool zu erstellen, das unseren Entwicklungsprozess erheblich vereinfacht hat. Wir haben Zeit und Mühe gespart und eine neue technische Erfahrung gewonnen. Ein wichtiger Faktor für den Erfolg war die Wahl der richtigen Werkzeuge für diese Aufgabe.
Was ist Ihre Geschichte für die Automatisierung an der richtigen Stelle?
