Linux-Kernel-Workflow

Einer der wichtigsten und am weitesten verbreiteten Workflows bei Pengutronix ist der, mit dem der Linux-Kernel entwickelt wird.

Der Linux-Kernel ist in verschiedene Subsysteme aufgeteilt, die in etwa mit einzelnen Abteilungen eines Unternehmens vergleichbar sind. Je nach Komplexität kann es weitere Subsysteme geben. Mögliche Änderungen an dem Linux-Kernel (Bugfixes, neue Treiber, Verbesserungen an der Code-Qualität) werden zunächst innerhalb des Subsystems diskutiert. Für jedes Subsystem (dieses ist mit einer mittleren Managementebene vergleichbar) ist ein Maintainer verantwortlich, der Tests durchführt und prüft, ob die Qualitätsstandards eingehalten sind. Wenn alles in Ordnung ist, fließen die Änderungen aller Subsysteme in die nächste Version des Linux-Kernels ein. Dieser wird von Linus Torvalds (dem Erstautor und Maintainer von Linux) persönlich released.

Den beschriebenen Workflow haben wir für die Arbeit am Prozesshandbuch adaptiert: Änderungen an der Prozessdokumentation werden mit den jeweiligen ProzessnutzerInnen diskutiert und anschließend an die Geschäftsführung zur Freigabe gegeben. Derzeit ist das Pengutronix-Prozesshandbuch-Projekt noch klein genug, so dass auf das mittlere Management verzichtet werden kann.

Versionskontrolle

Um diesen Workflow realisieren zu können, werden die Prozesse als strukturierte Textdateien geschrieben, die versionskontrolliert verwaltet werden. Der Release-Branch der Versionsverwaltung ist nur für die Geschäftsführung schreibbar, so dass über ein neues Release des Prozesshandbuchs auch gleichzeitig die Freigabe sichergestellt ist.

Der Vorteil von Dateien, die als reStructuredText (.rst) oder Markdown (.md) geschrieben werden im Gegensatz zu nicht-textbasierten Formaten wie .docx oder .odf, ist, dass die inhaltliche Änderung zusammen mit einem Zeitstempel und den Autoren in einer Versionsverwaltung einfach verfolgt werden kann. Zudem ermöglicht eine Versionsverwaltung neben der reinen Änderungsverfolgung auch Beschreibungstexte, in denen festgehalten werden kann, warum eine Änderung erfolgt und welche Entscheidungen zu der Prozessänderung geführt haben.

Web-Darstellung

So groß der Charme von Textdateien aus Sicht der Prozessschreibenden auch ist, für die Prozessnutzenden kann die Benutzerfreundlichkeit verbessert werden. Daher wird bei Pengutronix das quelloffene Software-Dokumentationswerkzeug Sphinx eingesetzt, um eine Webansicht zu generieren. In dieser können die Prozesse sowohl direkt verlinkt werden als auch Formulare, die zu einem Prozess gehören, als Download bereitgestellt werden.

Build-Server

Mit Hilfe eines Build-Servers wird das aktuelle Release der Prozessdokumentation gebaut und als Webansicht zur Verfügung gestellt. Gleichzeitig ermöglicht der Build-Server die Nutzung von automatisierten Tests.

Bei Pengutronix wird beim Bauen durch den Build-Server unter anderem geprüft, ob das Datum, an dem das nächste Prozessreview fällig wäre, überschritten wurde. Sofern dieser Fall eintritt, werden Erinnerungs-E-Mails verschickt, so dass der Prozess zeitnah auf seine Aktualität hin überprüft werden kann.

Das Setup wurde hier nur schematisch beschrieben, da es nicht um konkrete Produkte, sondern deren Einsatz zur Prozessdokumentation im Fokus steht. Wichtig ist, dass eine Versionsverwaltung zur Änderungsverfolgung und ein Buildserver für das "Continuous Testing" und "Continuous Deployment" verwendet werden.

Struktur einer Prozessbeschreibung

Damit das Setup im vollen Umfang genutzt werden kann, ist es entscheidend, dass im Vorfeld eine Struktur für das Handbuch und den Aufbau eines Prozesses festgelegt wird. Ein gutes Beispiel für die Gliederung der Prozesse und, wie so ein Handbuch gestaltet werden kann, ist das "Company Handbook" von GitLab Inc..

Um etwas in die Praxis zu gehen, wird Ausschnittsweise die Struktur eines Prozesses in der Prozessdokumentation von Pengutronix beschrieben sowie exemplarisch ein Test vorgestellt.

Ein Prozess besteht aus drei Abschnitten: Der erste Abschnitt ist eine Tabelle, in der Metadaten erfasst werden. Wann wurde der Prozess zuletzt aktualisiert? Wann ist das nächste Review fällig? Gibt es einen Vorgänger-Prozess? Welcher Prozess schließt sich an den aktuellen Prozess an? Gibt es Formulare zum Download?

Der zweite Abschnitt enthält die eigentliche Prozessbeschreibung. Für diese ist keine feste Form vorgegeben. Damit der Prozess gut lesbar ist, werden weitere Strukturierungselemente, wie Infoboxen oder Aufzählungen, verwendet.

Der dritte Abschnitt ist für allgemeine Informationen reserviert, die an die Qualitätskriterien der ISO 9001 angelehnt sind. Dabei sollen unter anderem folgende Fragen beantwortet werden: Wer sind die ProzessnutzerInnen und -eigentümerInnen? Wann wird der Prozess aktiviert? Welche Anforderungen gibt es an die ProzessnutzerInnen und welche Qualitätskriterien gibt es zur Erfüllung an den Prozess?

Die Struktur richtet sich zum einen an die ProzessnutzerInnen, damit die Informationen möglichst leicht gefunden werden können. Zum anderen erlaubt gerade die Metadaten-Tabelle den Einsatz von Testautomatisierung.

Testautomatisierung

Einer der wichtigsten Einsätze für die Testautomatisierung ist eine regelmäßige Erinnerung, dass Prozesse einem Review unterzogen werden sollen.

Damit bestimmte Elemente, wie das nächste Review-Datum eines Prozesses, geprüft werden können, muss sehr exakt angegeben werden, wo das Element zu finden ist. Dafür eignet sich besonders die Tabellenstruktur.

Die Tests wurden hier in Python geschrieben und für das Parsen der Datei die docutils-Library verwendet. Das vorliegende Code-Beispiel zeigt den Test auf das Review-Datum eines Prozesses.

def check_Wiedervorlage(self, document):
     assert 'Wiedervorlage' in self._data, \
         annotate(self._table, "metadata table missing 'Wiedervorlage' row")
     value = self._data['Wiedervorlage']
     match = re.match(r"(\w+): ([\d\-]+)", value)
     assert match, \
         annotate(self._table, "metadata 'Wiedervorlage' row has the wrong format")
     groups = match.groups()
     try:
         dt = datetime.strptime(groups[1], "%Y-%m-%d")
     except ValueError:
         dt = None
     assert dt is not None, \
         annotate(self._table, "metadata review time ('{}') format is invalid".format(groups[1]))
     assert dt >= datetime.strptime(datetime.now().strftime("%Y-%m-%d"), "%Y-%m-%d"), \
         annotate(self._table, "metadata review time ('{}') is in the past".format(groups[1]))

Dieser Test besteht aus drei Testschritten: Zunächst wird geprüft, ob die Tabellenspalte überhaupt gefunden wurde, anschließend, ob das Datum dem erwarteten Format entspricht, und zuletzt, ob dieses Datum in der Vergangenheit liegt.