Open Source im professionellen Einsatz
Linux-Magazin 05/2016

Wie Admins gute Paket-Qualität gewährleisten

Erst testen, dann beamen

Es ist der Horror, wenn nach einem Update alle Rechner in der Firma streiken. Wer dafür keine Nerven hat, sollte die Grundfunktionen vor jedem Paketupdate testen – nach Möglichkeit automatisch. Wie das gehen kann, und wer die Packages auf die Zielrechner beamt und wann, das erklärt dieser Schwerpunkt.

1085

Keine Firewall und kein IDS kann die Sicherheit für Linux-Server und -Desktops so wirksam schützen, wie das regelmäßige Updates tun. Darum informieren Linuxe ihre Anwender, wenn Paketupdates anstehen, wenn sie diese nicht sogar automatisch einspielen. Diese auch für Admins erfreuliche Tatsache bürdet ihnen aber auch eine mit jedem Update wiederkehrende Frage auf: Funktioniert danach noch alles auf den Systemen?

Quantitativ betrachtet lautet die Antwort: Meistens ja. Denn zumindest die Distributionen mit viel Manpower wie Debian, Fedora, Open Suse, Ubuntu und einige mehr testen ihre Software recht umfänglich, bevor sie sie auf hunderttausende Rechner loslassen. Enterprise-Distributionen rechtfertigen ihre Subskriptionspreise zum guten Teil mit der Zusicherung, dass ihre Maintenance funktions- und schnittstellenneutral abläuft.

Doch Fehler lassen sich im Einzelfall nicht vermeiden. Mehr noch: Viele Firmen haben Spezialsoftware auf ihren Rechnern installiert, die sie nicht aus den Repositories der benutzen Distribution beziehen. Ob die sich mit einem sich alle paar Tage quasi selbstmodifizierenden System verträgt, überprüft kein Mensch. Dem seiner Verantwortung für die Funktion der IT sich bewussten Admin bereitet das Bauchschmerzen. Was tun, wenn eines morgens eine Anwendung nicht mehr (richtig) funktioniert, die fast alle Mitarbeiter benutzen? Oder wenn keiner mehr drucken oder auf Samba-Shares zugreifen kann? Oder die grafischen Tablets in der Konstruktionsabteilung streiken? Die Antwort auf solche Fragen darf man ruhig als "geschäftskritisch" bezeichnen.

Was tun?

Jeder IT-Verantwortliche sollte das gedanklich mal durchgespielt haben und überlegen, wie er in diesem Fall konkret organisatorisch und technisch reagieren würde. Firmen, die eine Softwareverteilung [1] wie Ansible, Puppet oder Chef benutzen, würden wahrscheinlich alle Rechner auf den Stand von vor dem Update zurückrollen. Das löst das Problem zwar nicht nachhaltig, der Geschäftsbetrieb wird aber nach vielleicht einer Stunde wieder anlaufen. Die internen Kosten einen solchen Vorfalls sind trotzdem immens und dem Standing der IT-Abteilung nicht zuträglich.

Und bei Weitem nicht jeder hat ein Softwareverteil-System am Laufen, denn der Einrichtungs- und Pflegeaufwand lohnt meist nur, wenn man genug ähnliche Systeme unter der Obhut hat. Letztlich wird jeder Operations-Verantwortliche besser schlafen, wenn er die Funktionstests nicht den Angestellten in der Firma ohne dessen Wissen durchführen lässt, sondern zumindest die zwei, drei, vier Hauptanwendungen vorab testet. Sinnvollerweise automatisiert der Admin das Anschieben der Tests, die Tests selber und deren Auswertung weitgehend. Firmen, die eine eigene Entwicklungsabteilung haben, werden sich hierbei auf Continuous-Integration-Systeme stützen (siehe Kasten "Interview").

Interview: Qualitätssicherung bei Univention

Michel Smidt gehört zum Professional Service Team bei der Bremer Linux-Firma Univention. Deren Hauptprodukt, die Distribution Univention Corporate Server (UCS), fußt auf Debian Linux.

Linux-Magazin: Ihre zahlenden Kunden verlassen sich darauf, dass die Software, die Sie ausliefern, funktioniert. Womit testen Sie das?

Michel Smidt: Weil es sich beim UCS um ein sehr komplexes und vielschichtiges Produkt handelt, sind kontinuierliche, automatisierte Tests für uns ein sehr hilfreicher früher Indikator für Integrationsprobleme. Wir nutzen dafür Jenkins mit einer Reihe von Plugins und bauen dazu nachts zahlreiche verschiedene Umgebungen mit dazugehörigen automatisierten Tests auf. Das reicht von einfachen Installation bis hin zu komplexen Multiserverumgebungen mit mehreren Serverrollen und Active-Directory-Anbindungen.

Unser Jenkins führt pro Konfiguration ein so genanntes Shell Build aus. Das beginnt mit einem Checkout der speziellen Buildkonfiguration aus dem Git. Die Buildkonfiguration selbst ist ein Skript, in dem wir die Instanzen (Anzahl, Rolle, Instanzengröße, Hostserver, UCS-Profile) definieren. Wenn nötig, definieren wir hier auch Schritte zur Ausführung (Domänenjoins, Installation von Spezialpaketen). Viel davon haben wir in Libraries ausgelagert.

Dann starten die wirklichen Tests mit Produkt- oder Kundentestpaketen. Manchmal legen wir sie auch in die Kundenpakete selbst hinein. Die Tests sind in Python geschrieben und verwenden entweder das Python-eigene Unittest-Framework [5] oder Pytest [6]. Von uns selbst stammen Testhelper, beispielsweise um das UCS-LDAP leer zu räumen oder um ein Nutzerobjekt anzulegen, welches der Test erwartet.

Linux-Magazin: Wonach wählen Sie die Testszenarien aus?

Michel Smidt: Wir versuchen für jede Codeänderung mindestens einen Test zu haben. Das kann ein Unit-, ein Integrationstest oder ein anderer Check sein. Wir haben sogar viele als »expected to fail« -markierte Tests: Anhand der vorgegebenen Eingabe erwarten wir, dass das getestete System einen Fehler meldet. Sollte der nicht kommen, wäre das ein echter Fehler.

Linux-Magazin: Wo bleiben die Resultate?

Michel Smidt: Jenkins holt die auf den Testinstanzen entstehenden XML-Resultate ab, zeigt übersichtliche Diagramme an und versendet auch Mails. Ein Entwickler erfährt also, dass ein ihn betreffender Test fehlgeschlagen ist. Bei Entwickler-Branches muss der Mitarbeiter den Code selbst fixen, andernfalls wird der Branch nicht in den Hauptzweig gemerged. Sobald alles sauber erscheint, gehen die Änderungen in einen Release-Hauptzweig ein. Schlagen jetzt trotzdem wieder Tests fehl, macht der für die Komponente Zuständige ein Bugticket auf.

Etwas direkter läuft bei unseren Kundenprojekten, weil deren Testzyklen kürzer als bei regulären Produkten ausfallen: Sobald unsere Entwickler eine Änderung in Git einpflegen, baut ein Buildserver neue Pakete, und es starten automatisch UCS-Umgebungen mit den Tests. Anschließend erhält der Entwickler Meldungen, ob seine Änderungen unerwünschte Seiteneffekte in anderen Softwarekomponenten erzeugt haben. In den Kundenprojekte versuchen wir so nah wie möglich an dem späteren Zustand der Produktivumgebung zu bleiben. Teilweise schreiben wir extra Mock-Services, welche die Interaktion mit Fremdsystemen simulieren.

Selbst ist der Admin

Eine normale Anwenderfirma muss die Tests selbst entwerfen. Das klingt schwieriger als es ist, da schon wenige mit gutem Ausgang absolvierte Basistests ausreichen, um die Wahrscheinlichkeit, dass niemand mehr arbeiten kann, signifikant zu verringern. So braucht man beim Standard-Webbrowser nicht zwingend automatisch zu testen, ob nach einem Update die deutsche Rechtschreibhilfe in Formularen noch funktioniert. Normale Anwender werden ein paar Stunden auch ohne klarkommen. Geht aber firmenweit die Druckfunktion nicht mehr, dann ist das kritisch. Der Schwerpunkt dieses Linux-Magazins beschreibt mit mehreren Ansätzen beispielhaft, wie jeder solche Tests selbst implementieren kann.

Die Funktionstests bekommen nur einen Sinn, wenn sie vorab auf einem dafür reservierten echten oder virtuellen System laufen. Das bezieht seine Pakete direkt aus den Repositories der Distribution. Wer wie oben flächendeckend eine Softwareverteilung einsetzt, tut sich nun recht leicht: Laufen die Tests auf dem separaten System, spielt er die Updatepakete in die Softwareverteilung ein.

Wer kein solches System hat, muss auf andere Weise die Pakete zurückhalten. Sind alle Systeme gemanagt, könnte der Systemverantwortliche das Linux-Paketmanagement so modifizieren, dass es erst auf einen externen Befehl hin seine Updates holt und installiert. Das prinzipbedingte Problem hierbei: Erscheinen zwischen Test und Ausrollen weitere Updates Upstream, bleiben die ungetestet.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Debian Src 3.0

    Debian 6.0 enthält neben vielen angenehmen Features für Endnutzer auch eine wichtige Neuerung für Entwickler: das Source-Paketformat 3.0. Admins profitieren vom 3.0-Format durch neue Funktionen, die Bau und Pflege ihrer Pakete vereinfachen.

  • Softwareverteilung Pulp als Community Release 14

    Pulp, eine Softwareverteilung für Red-Hat-basierte Systeme, ist in Community Release 14 erhältlich.

  • Rollout Testing

    Sicherheitslücken, Bugs und technischer Fortschritt bringen Distributionen jeden Tag in Bewegung. Admins, die fürs Deployment der Pakete die Verantwortung tragen, bleibt nichts als testen, testen, testen …

  • Debianopolis

    Debian ist frei und seine Entwickler sind Kosmopoliten. Das Linux-Magazin berichtet regelmäßig Interna aus der Debian-Entwicklerszene und angrenzenden Projekten.

  • Softwareverteilung Pulp erreicht 1.0

    Das Pulp-Projekt hat seine freie Softwareverteilung für Red-Hat-basierte Systeme in Version 1.0 veröffentlicht.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.