In dem heutigen Artikel geht es um ein ernsthaftes Thema.
Ich denke es ist meine Pflicht, Sie zu warnen, da ich - wie Sie ja wissen - nicht immer über ernste Themen schreibe. Dieser Artikel ist jedoch ernst, weil ich zusammenfassen möchte, wie wir kontinuierlich an der Verbesserung der absolut Außergewöhnlichen Nuxeo-Content-Services-Plattform[1] arbeiten.
Und dazu gehört nun einmal, dass ich Ihnen von unseren Prozessen für Qualitätssicherung (QS) und kontinuierliche Integration (CI, abgeleitet vom Englischen “continuous integration”) berichte. Hier bei Nuxeo ist das eine ernste Angelegenheit.
Und damit das auch so bleibt, hat man sichergestellt, dass ich damit so wenig wie möglich zu tun habe. Zuständig für diese Verfahren ist unser Technikteam: Entwickler (sowohl Back-End als auch Front-End), QS-Team, DevOps, SysAdmin …
Also so gut wie jeder bei Nuxeo außer mir … Deswegen ist das Verfahren auch absolut hieb- und stichfest.
Wir von Nuxeo nehmen die Transparenz unserer Entwicklungsprozesse ernst: Für uns ist alles “open source”, vom Quellcode bis hin zu unternehmensinternen Prozessen.
Tagtäglich geben wir vollständige und transparente Einblicke dazu, wie wir Nuxeo - unser beeindruckendes und unglaublich leistungsstarkes Produkt, das Sie bereits verwenden oder bald verwenden werden[2] - bauen und verbessern. In dieser QS-/CI-Dokumentation finden Sie genaueste Beschreibungen und wenn Sie sich das Dokument durchlesen, werden Sie feststellen, dass jedes einzelne Element absolut hochmodern ist. Wir verwenden (in der Reihenfolge ihrer Nennung) GitHub, Jenkins, Maven, mehrere Test-Tools (Einheitstests, Funktionstests, Leistungstests), die hier aufgelistet und eingehender beschrieben sind.
Das große Ganze
Diese Verfahren sind in der folgenden Grafik zusammengefasst[3]:
Die Darstellung verdeutlicht noch einmal den Kernpunkt, nämlich die Prinzipien, die hinter dem kontinuierlichen Build der Nuxeo Platform stecken. Abhängig davon, mit welchem Teil der Plattform wir uns beschäftigen, sind zahlreiche weitere Details und untergeordnete Verfahren und Prozesse involviert.
Wenn wir beispielsweise ein optionales Add-on (Nuxeo Vision, Digital Signature usw.) überarbeiten, hat das bei Weitem keine so großen Auswirkungen wie die Arbeit an einem der zentralen Plug-ins (wie beispielsweise der Plug-ins, die eine Verbindung zum Back-End-Datenbankspeicher herstellen). Außerdem laufen die Verfahren nicht immer zwingend hintereinander ab, wie hier gezeigt. Codeprüfung, Brainstorming und erneute Anpassung können beispielsweise zu beliebigen Zeitpunkten erfolgen.
Erläuterung des großen Ganzen
Hier also die Hauptprozesse für QS und CI bei Nuxeo:
Ein Entwickler oder eine Entwicklerin von Nuxeo schließt seine/ihre Arbeit an einem Plug-in (nennen wir es Plug-in A) ab und hat einen bestimmten Zweig um Funktionen ergänzt oder Fehler behoben (niemand darf unmittelbar am Masterzweig arbeiten). Die Plattform basiert auf einer Komponentenmodellarchitektur - das bedeutet, dass alle Funktionen Plug-ins sind und nicht am gesamten Quellcode gearbeitet werden muss. Plattformentwickler und -entwicklerinnen arbeiten immer nur an einem Plug-in auf einmal (Nuxeo WebUI, Nuxeo S3 Storage, Nuxeo LiveConnect, Bulk Document Importer usw.).
Der Entwickler bzw. die Entwicklerin testet seine oder ihre Änderungen lokal und pusht die Änderung an GitHub, sobald er oder sie zufrieden ist. Falls nicht, heißt es: von vorne anfangen.
Nachdem die Änderung an GitHub übermittelt wurde, ermöglicht es ein Hook unserem Jenkins-Server, zu erkennen, dass Plug-in A bearbeitet wurde. Jenkins ruft dann die Änderungen ab und …
… fordert bei Apache Maven eine Integration von Plug-in A in den Zweig des Entwicklers bzw. der Entwicklerin an. Das bedeutet: erstellen und testen. An dieser Stelle können weitere Details und untergeordnete Verfahren zum Einsatz kommen, die in der oben gezeigten Zusammenfassungsgrafik nicht dargestellt sind: Abhängig vom Plug-in kann auch ein Auslöser für die Erstellung aller abhängigen Module aktiviert werden oder Funktions- oder Leistungstests werden für die volle Integration von Plattform und Plug-in durchgeführt.
Nehmen wir einmal an, dass das Plug-in erfolgreich auf unseren Jenkins-Servern erstellt und getestet wurde. “Auf unseren Servern” ist deshalb ein nützliches Detail, weil somit (wirklich) das Problem mit dem Phänomen “Aber auf meinem Computer funktioniert’s …” vermieden werden kann. Der Entwickler oder die Entwicklerin kann nun eine Pull-Anfrage auslösen, um die Änderungen in den Masterzweig zu übernehmen. Mindestens zwei Entwicklerkollegen prüfen dann den Code und bestätigen die Änderungen. Die Schritte 1 bis 4 werden also so lange wiederholt, bis sich alle über die Änderungen einig sind.
Zu diesem Zeitpunkt wird der Entwicklerzweig mit dem Masterzweig verschmolzen und die nächste ernste Stufe beginnt.
Maven übersetzt das Plug-in in den Master und testet es.
Falls alles in Ordnung ist, wird das Plug-in komprimiert …
… und es kann mit den Validierungsverfahren begonnen werden: Es erfolgen Funktionsprüfungen, Leistungsprüfungen, Matrixprüfungen … einfach alles.
Falls “alles” in Ordnung ist, wird das Plug-in dann an den Nuxeo Marketplace übermittelt, wo es für unsere Kunden zugänglich ist. Die Kunden können ihre eigenen Tools für kontinuierliche Integration/Bereitstellung verwenden, um das Plug-in automatisch abzurufen. Dieser Vorgang lässt sich ganz einfach automatisieren (nutzen Sie einfach ./nuxeoctl mp-install the-plugin-artifact-id - und fertig).
Nach Schritt 9 werden auch unsere verschiedenen Server für Tests durch menschliche Anwender im Rahmen des kontinuierlichen Bereitstellungsprozesses aktualisiert. Dazu verwenden wir Ansible-Skripte, Container und die neuesten und coolsten Tools (na ja, “cool” für totale Geeks wie uns).
Außerdem haben Sie vielleicht bemerkt, dass “Sonar” in der Darstellung erwähnt wurde. Mit Sonar prüfen wir die Qualität und den Leistungsbereich des Codes. Nach Erstellung des Masterzweigs erhält Sonar die Änderungen über GitHub, stimmt sie ab und gibt uns weitere Informationen (zum Leistungsbereich und möglichen Problemen, die Entwickler und Prüfer möglicherweise übersehen haben).
Weitere Informationen zum Verfahren
Wissen Sie was? All das geschieht automatisch!
Na ja. Natürlich geschieht es automatisch … Wer möchte schon Mitarbeiter einstellen, die den ganzen Tag nur auf die Schaltflächen “Aus GitHub herunterladen”, “Sonar informieren” oder “Testen” klicken?
Zugegeben, nicht jeder Schritt ist zu 100 % automatisiert. Für den ersten Schritt benötigen wir beispielsweise das Gehirn eines bzw. einer brillanten Entwicklers/Entwicklerin, um den bestmöglichen Code zu schreiben.
Und wenn etwas schiefgeht, werden natürlich die entsprechenden Personen informiert. Der Entwickler bzw. die Entwicklerin wird (selbstverständlich) benachrichtigt, doch auch andere Entwickler und Manager (ja, wir sind zwar ein supercooles Unternehmen, aber selbst unsere Ingenieure haben Chefs …) erhalten einen entsprechenden Hinweis, damit das Plug-in so schnell wie möglich repariert werden kann.
Zur Durchführung dieser Prozesse starten wir (sowohl automatisch als auch auf Anfrage) Jenkins in Docker-Containern innerhalb unserer Cloud-Infrastruktur auf AWS.
Den gesamten Prozess können Sie unter qa.nuxeo.com, unserer öffentlich zugänglichen QS-Site, verfolgen (hatte ich schon erwähnt, dass wir total transparent sind?). Da wir laufend an der Verbesserung unseres Produkts arbeiten, können Sie sich auch gerne jederzeit an uns wenden: Monatlich, wöchentlich, täglich, stündlich … Wann immer Sie möchten. Sie haben auch jederzeit Zugriff auf die Antworten auf die Fragen was/warum/wer zu unseren QS- und CI-Verfahren. Was wurde erstellt, warum wurde es erstellt (JIRA-Ticket), was wurde am Code geändert und wer hat den Code geändert. Und wenn Tests nicht bestanden wurden, können Sie - wenn Sie möchten - dem Entwickler dafür die Schuld geben (tun Sie das aber nur, wenn Sie gleichzeitig auch ein paar Freibiergutscheine für eine Geek-Bar mitschicken).
Die Zukunft
Am Anfang dieses Beitrags hatte ich erwähnt, dass - abhängig vom bearbeiteten Plug-in - weitere Details benötigt und zusätzliche untergeordnete Prozesse durchgeführt werden. Einer dieser Prozesse heißt Testen und pushen. Im Wesentlichen geschieht das, wenn ein Entwickler oder eine Entwicklerin an einer Funktion arbeitet, deren Änderung sich potenziell auf die gesamte Plattform auswirken könnte.
Nehmen wir also einmal an, ein Entwickler oder eine Entwicklerin ändert die Version der JSON-Parserbibliothek, mit der Nuxeo arbeitet. Dieser Umstand könnte schwerwiegende Folgen für beliebige Plattformelemente haben und somit genügt es nicht, nur ein einziges Plug-in zu testen. Der Entwickler bzw. die Entwicklerin muss einen Test vom Typ Testen und pushen durchführen, in dessen Rahmen die gesamte Plattform angepasst und dann geprüft wird. Obwohl sich dieser Test automatisch auslösen ließe, ist es uns (aktuell) noch am liebsten, den Test größtenteils manuell und auf Anfrage zu erledigen, da die Anpassung und Prüfung der gesamten Plattform viel Zeit und Rechnerkapazitäten in Anspruch nimmt.
Unser Team ist stets auf der Suche nach Möglichkeiten, seine Prozesse anzupassen und zu verbessern. Hintergrund ist, dass wir in der Lage sein möchten, die Aufgaben zu beschleunigen. Das Testen der gesamten Nuxeo Content Services Platform ist deshalb zeitaufwändig, weil alle Tests linear (also einer nach dem anderen) durchgeführt werden müssen. Die meisten der Tests sind jedoch nicht voneinander abhängig. Für nuxeo-platform-renditions ist es also beispielsweise nicht notwendig, erst abzuwarten, bis der Test nuxeo-platform-tag abgeschlossen ist. Aus diesem Grund möchten wir die Jenkins-Pipeline und Docker gerne verwenden, um den starren Testen-und-pushen-Test in kleinere Tests und Prüfungen aufzuteilen, die sich zeitgleich durchführen lassen. Somit wären wir in der Lage, CI-Ressourcen optimal zu nutzen und gleichzeitig schneller Testergebnisse bereitzustellen.
Fazit
Nuxeo nimmt QS und CI sehr ernst.
(Das war doch mal eine kurze Zusammenfassung.)
[1] Das Akronym “ANCSP” wurde vom Marketingteam nicht abgesegnet, ich habe es einfach für diesen Artikel erfunden.
[2] Vielleicht sind Sie gerade auf der Suche nach Informationen über Nuxeo und sind so auf diesen Artikel gestoßen. Ich habe geschrieben, dass Sie Nuxeo bald verwenden werden, da es die beste Content-Services-Plattform im ganzen Universum ist. Also warum um alles in der Welt würden Sie die Plattform nicht nutzen?
[3] Meine erste Idee war eine Art komprimierte Zusammenfassung.
Das war die ursprüngliche Darstellung:
Als ich diesen Vorschlag jedoch Thierry Delprat (CTO von Nuxeo) unterbreitete, machte er ein Gesicht, als wäre er kurz davor, seinen Stuhl nach mir zu werfen… also fügte ich weitere Details ein. CTOs …