Autor

openSUSE setze verstärkt auf Tumbleweed [3] – das Rolling Release der beliebten Distribution – und das liege auch daran, dass die auf mittlerweile durchschnittlich 12.000 Benutzer angewachsene Nutzerschar erkannt habe, dass diese Version die am besten getestete SUSE-Variante sei. Das, so Brown, sei nur möglich durch die Tools im Hintergrund. Die openSUSE-Community hat sich ein Ökosystem geschaffen, welches das Bauen und Testen einer Linux-Distribution weitgehend automatisiert, so dass die Entwickler sich auf das konzentrieren können, was ihnen am meisten Spaß macht: Neue Features entwickeln – und natürlich Bugs fixen.

An erster Stelle im Ökosystem steht da der vielgelobte openSUSE Build Service [4], der heute einfach Open Build Service oder kurz OBS genannt wird. Dieser Cluster aus mehreren hundert Cores baut automatisch Binärpakete aus Quelltextarchiven, die die Entwickler hinaufladen. Neben SUSEs eigener Buildfarm arbeiten hier zwischen 400 und 800 Rechnerkerne, gesponsort von SUSE und Partnern, frei verwendbar für Community und Entwickler im Web. Keines dieser Tools ist auf SUSE oder openSUSE beschränkt – man versteht es vielmehr als Service für freie Linux-Entwickler, und deshalb lassen sich mit dem OBS eben auch Ubuntu, oder sogar Red-Hat-, Debian- oder Mandrive-Pakete bauen. Der große Vorteil für Developer ist: Sie brauchen sich keine Gedanken mehr um ihre Build-Systeme zu machen, all das übernimmt der OBS. "Wirf Deinen Quellcode vorne rein, dann kommen hinten die Pakete für zahllose Architekturen und Distributionen raus" lautet das Versprechen.

Eine komplette Distribution besteht in der Regel aus zahllosen binären Softwarepaketen. Die Auswahl dieser Pakete (vom Entwickler selbst oder von anderen, beispielsweise im OBS entwickelt und veröffentlicht) obliegt normalerweise dem Distributor, doch in Zeiten des Cloud-Computing oder generell von verbreiteter Virtualisierung wuchs das Interesse an maßgeschneiderten ISO-Images für einzelne Anwendungen. Man nehme Pakete von Serverdiensten, kombiniere sie mit allen notwendigen Libraries und ein paar netten Tools, baue daraus ein ISO-Image und schon hat man ein maßgeschneidertes Image für die eigene Cloud. Genau dabei hilft SUSE Studio.

Ein Distributor wie openSUSE muss diese Schritte naturgemäß sehr häufig machen, und deshalb etablierte die Community auch hierfür eine automatisierte Lösung: SUSE Studio erledigt den Bau von ISO-Images (oder auch VMware- oder andere Virtualisierungsabbilder) über ein schickes Webinterface, per Mausklick und auf Wunsch vollautomatisch. Im Hintergrund werkelt der Image-Builder KIWI [5], SUSE Studio ist "nur" ein Ruby-on-Rails-basiertes Webinterface für KIWI.

Auch Studio steht der Öffentlichkeit zur Verfügung, Anwender können Images bauen, uploaden, zum Download bereitstellen und verändern. Fans von Owncloud, KDE, GNOME oder die Firmen hinter diversen Open-Source- oder auch proprietärer Software nutzen den Dienst, um ihre Lieblingssoftware oder ihre Produkte unter die Leute zu bringen. Aktuell supportet Studio KVM, Virtual Box, VMWare und besagte ISO-Images. Wer mag, klickt sich seine eigene Variante zusammen, indem er auf einem Image aufbaut oder mit openSUSE, SLES oder JeOS beginnt.

Sowohl Studio als auch der Build Service gewannen stark an Bedeutung, als das Rolling Release Tumbleweed [3] mehr und mehr zentraler Bestandteil der openSUSE-Entwicklung wurde. Ende 2014 entschieden die Entwickler, den Development-Tree Factory mit dem Rolling Release zu verschmelzen. Schon openSUSE 13.2 war dann nur mehr ein Snapshot von Tumbleweed, der als Version 13.2 veröffentlicht wurde. Tumbleweed ist die Basis für alle Entwicklungen in openSUSE heute, gleichzeitig aber auch das Test-Bed für Entwickler.

Aus dem oben beschriebenen Workflow fallen täglich ISO-Images an, die den aktuellen Stand von openSUSE Tumbleweed wiedergeben. Taucht ein solches ISO-Image auf, stürzt sich voll automatisch ein (oder mehrere) Worker von openQA darauf und testet die Funktionalität, also beispielsweise ob die Distribution sauber installiert.

openQA fungiert dabei als Test-Tool zur Qualitätssicherung (Quality Assurance, QA), hilft aber auch bei Themen der Continuous Integration (CI) und Versionskontrolle. Startet ein Build nicht, können die Entwickler und QA-Tester genau nachvollziehen, was wann und warum geändert wurde und den Fehler auslöste. Wie Abb.5 zeigt, schwankt dementsprechend auch die Qualität der Snapshots, ein natürlicher Prozess in Entwicklungsumgebungen.

Das Leben ist zu kurz für manuelle Tests!

openQA entstand eigentlich aus der für Entwickler nervigen Situation, dass jede Form der Qualtitätssicherung zahlreiche, gleiche, immer wiederkehrende Schritte verlangt. Das zu automatisieren lag nahe, und es scheint sehr gut gelungen zu sein: Immerhin gab auch SUSE mittlerweile bekannt, den Quelltext seines Enterprise Servers in der openSUSE-Toolchain freizugeben und mit openQA zu testen [6]. Wie das Projekt heißen soll, darüber streiten sich die Entwickler noch beherzt, aber der Weg ist klar: Für die kommenden, "festen" openSUSE-Releases mit Versionssnummern soll SLES die Basis sein und so Power-User addressieren, denen weniger an topaktueller, aber eventuell instabiler Software liegt. Das "Projekt ohne Namen" will so die auf Stabilität und Zuverlässigkeit bedachten openSUSE-Anwender bedienen. Details dazu bietet Richard Browns Keynote [3] .

openQA wendet einige der grundlegendsten UNIX-Dogmas konsequent an: "Keep it simple, one tool for one Job". Taucht ein neues ISO-Image im Arbeitsverzeichnis auf, so startet openQA einfach einen Worker, der wiederum eine KVM-Instanz bootet, in der das neue ISO-Image als Boot-Medium dient. Davon gibt es Screenshots und Videos auf der Webseite, die das Nachvollziehen von Fehlern stark vereinfachen.

Weil das Booten oder gar die Installation einer Linux-Distribution Eingaben erfordert und zwar schon auf dem ersten Bildschirm (im Bootmanager), mussten sich die Entwickler etwas einfallen lassen. Glücklicherweise bringt KVM bereits (fast) alles mit, was man dafür benötigt: Einen VNC-Server und eine API für die Eingabe von Tastaturbefehlen und Mausevents.

Was jetzt noch fehlt ist die Erfolgskontrolle und geeignete Tests. openQA nimmt mehrmals pro Sekunde einen Screenshot der virtuellen Maschine auf. Die Entwickler wiederum haben derartige Bildschirmschnappschüsse vorbereitet, die das Wunschergebnis wiedergeben. Und OpenCV (Open Computer Vision) [15], eine Bibliothek zur befehlszeilenbasierten Bildverarbeitung, übernimmt das Vergleichen. Um die Erfolgskontrolle zu optimieren, erfanden die openQA-Entwickler um Bernhard Wiedemann (SUSE), der openQA im Jahr 2010 initiierte, das Konzept der Needles (Nadeln).

Dass das auch die Konkurrenz nicht kalt lassen konnte, zeigt die Entwicklung rund um Fedora. Es war ebenfalls Brown, der eine erste Testsuite speziell für Fedora entwickelt hatte. In seinem Vortrag auf der Suse Conference [7] beschreibt er lakonisch, dass die größten Schwierigkeiten dabei gewesen seien, zu verstehen, wie man Fedora überhaupt installiere, weil der Installer Anakonda doch einige andere Herangehensweisen vorweise. Nichtsdestotrotz habe er dann einige Tests entwickelt und so beweisen können, dass openQA selbstverständlich auch andere Linuxe unterstütze. Seine Tests liegen frei zum Download [8].

Auf Red Hats Entwicklerkonferenz DevConf im tschechischen Brno machte dann auch schnell die Runde, dass Red Hat selbst eine openQA-Instanz am Laufen habe, weil man das System als interessant und wertvoll ansehe. Analog zum Open Build Service (auch davon betreibt Red Hat eine eigene Installation) bevorzuge Red Hat wohl eigene Lösungen, anstatt sich ins Community-Angebot einzubringen, heißt es in Nürnberg.