Standardmäßig setzt OS X und auch das neue macos Sierra auf die Bourne-again shell, kurz Bash, als Standard-Shell. Allerdings in Version 3 aus dem Jahre 2007. Apple aktualisiert zwar regelmäßig sein Betriebssystem, jedoch die Bash bleibt davon ausgenommen. Für mich persönlich unverständlich, denn gerade die Mischung aus einem unixoiden und einem Consumer-Betriebssystem verschafft einen Mac bei Entwicklern die notwendige Attraktivität.

Neben dem Umstand das die ausgelieferte Bash-Version gut neun Jahre alt ist, stellt Version 4 der Bash auch viele neue Features bereit. Das attraktivste Feature davon für mich sind assoziative Arrays, auf die ich nicht mehr verzichten wollte.

Die Bash 4 kann zusätzlich neben der Bash 3 über Homebrew oder MacPorts mit ein paar Schritten installiert werden.

Damit die nun installierte Shell auch als Login-Shell genutzt werden kann, muß sie zur Liste der erlaubten Login-Shells in /etc/shells hinzugefügt werden.

Kurze Zeit nachdem ich auf die Bash 4 umgestiegen bin, wollte ich alle meine Ports neu installieren und habe dafür zuerst alle installierten Ports entfernt — und damit auch meine eigene Login-Shell. Damit hatte ich mir jede Möglichkeit genommen eine Shell zu öffnen und meine Ports erneut zu installieren.

Passiert so etwas, kann die Shell auch über die Systemeinstellungen geändert werden. Dafür werden diese zuerst geöffnet und dann auf die Gruppe Benutzer & Gruppen geklickt.

Im Panel Benutzer & Gruppen werden links alle Benutzer aufgeführt. Um einen Benutzer bearbeiten zu können, muß das Schloß unten links mit dem Label Zum Bearbeiten auf das Schloss klicken geöffnet werden.

Die Einstellung für die Login-Shell für einen Benutzer ist in den Erweiterten Einstellungen enthalten, die über einen Klick mit der rechten Maustaste auf den zu ändernden Benutzer aufgerufen werden können.

In den erweiterten Optionen eines Benutzers gibt es ein Feld Anmelde-Shell, über das die zu verwendende Login-Shell eingestellt werden kann. Beispielsweise die vom Betriebssystem mitgelieferte Bash 3 unter /bin/bash.

Mich hat erneut überrascht, wie viel Unix in OS X enthalten ist und wie gut dieses auch in die übrigen Tools integriert ist. Nicht das ich nicht wüßte, das Darwin, das eigentliche Betriebssystem von OS X und macOS Sierra, auf BSD beruht und vieles nur von Aqua verdeckt wird. Doch das vergißt man leicht bei der täglichen Arbeit.

Viel Freude mit der jetzt jeweils aktuellsten Bash.

Seine Software-Projekte über eine selbst gehostete Continuous Integration-Lösung wie TeamCity oder Jenkins eine SaaS-Lösung à la Travis zu bauen, gehört heute zum guten Ton, sprich sollte Standard sein. Bei jeder Änderung im Projekt wird so geprüft, ob der Code kompiliert und alle Tests erfolgreich ausgeführt werden können. So stellen wir sicher, daß unsere Software sich in einen einwandfreien Zustand befindet. So weit so gut.

Leider führt dies zu einer trügerischen Sicherheit, denn ob ein Projekt baut oder nicht, hängt nicht nur vom Projekt selber ab, sondern auch von seinen externen Abhängigkeiten und dem System auf dem es gebaut wird. Diese Abhängigkeiten können wir nie vollständig kontrollieren. Zwar bieten die heute sich im Einsatz befindenden Build-Systeme die Möglichkeit Abhängkeiten zu Projekt-externen Librarys in Hinsicht auf Version und Quelle genau festzulegen, jedoch garantiert das nicht, daß diese Abhängikeit in dieser Version für immer an genau dieser Stelle zu finden sein wird.

Beispielsweise wurden vor einiger Zeit alle Dienste von Codehaus, inklusive dessen Maven Repositorys, abgeschaltet. Und GitHub-Accounts bestehen manchmal auch nicht für immer.

Häufiger als das jedoch sind Veränderungen auf dem Host, auf dem der Continuous Integration-Server läuft beziehungsweise auf dem der eigentliche Build erfolgt. Abgelaufene Zertifikate, aktualisierte Versionen von genutzten Tools wie Maven oder eine andere Ruby-Version und schon ist der Build kaputt, ohne das sich am Projekt selber etwas geändert hat.

In einem aktiv entwickelten Projekt fallen solche Probleme sofort auf, da es häufig Commits gibt, die einen neuen Build auslösen. Doch sobald die Aktivität abnimmt oder lange Zeit gar nicht mehr an dem Projekt gearbeitet wird, befinden wir uns in einer trügerischen Sicherheit. Jedes Projekt kann potentiell kaputt sein und wir damit nicht in der Lage Fehler zu beheben oder neue Features schnell einzubauen. Wer ein paar wirklich alte und inaktive Projekte hat, kann dies gerne selber überprüfen.

Aus diesem Grunde sind wir in meinem Team dazu übergegangen unsere Projekte jede Nacht zwischen drei und sechs Uhr morgens vollständig zu bauen. Sofern es Probleme dabei gibt, was ab und zu doch schon vorkommt, finden wir diese schnell und können Fehler beheben oder Anpassungen vornehmen. Für uns im Team ist eine wichtige Voraussetzung, um jeder Zeit lieferfähig zu sein.

Daher sollte jedes Projekt einmal pro Tag vollständig gebaut werden, unabhängig davon, ob es Änderungen daran gab oder nicht. Nur so kann sichergestellt werden, jeder Zeit daran weiter arbeiten zu können.

Für uns war dies nur der erste Schritt. Inzwischen sind wir dazu übergegangen unsere Buildchains zu generieren, doch dies ist ein anderes Thema.