So verbindet ihr DevOps mit eurem Design System

Gestern Abend habe ich in einem Moment der Inspiration eine Anwendung entwickelt. Ich begann um sechs Uhr abends, und um ein Uhr war sie bereits mit allem Drum und Dran deployed – inklusive Unit- und Akzeptanztests, SSL-Zertifikaten und Betrieb in Kubernetes.

Mit anderen Worten: Von der Idee bis zur Produktion dauerte es nur sieben Stunden. Und noch bevor alles fertig war, hatte ich bereits mehrere erfolgreiche Lieferungen.

Wie ist das möglich, fragt ihr euch vielleicht?

Die Antwort lautet: eine Continuous-Delivery-Pipeline, die mit einem Design System verbunden ist. Tatsächlich beginnt DevOps schon vor der Designphase. Indem ihr DevOps in das Design System integriert, schafft ihr eine solide Ausgangsbasis für eure Delivery-Pipeline und könnt neue Innovationen schneller voranbringen.

Ein Design System ist die Stimme eines Unternehmens

Design Systems sind schon seit einiger Zeit ein wichtiges Thema. Sie entstanden aus dem Bedarf an einheitlichen Stilen und helfen Organisationen dabei, ihren Auftritt in grafischer Form zu harmonisieren.

Für den Begriff gibt es verschiedene Definitionen. Im Kern ist ein Design System jedoch eine Sammlung von Elementen, mit denen Teams ein Produkt gestalten und entwickeln können, ohne von der einheitlichen Stimme und Identität einer Organisation oder eines Unternehmens abzuweichen. Heute wird es immer wichtiger, eine stimmige Bibliothek aus Stilen und Komponenten zu haben, die bei der Entwicklung neuer Services oder bei Änderungen an bestehenden Anwendungen genutzt werden kann. Einfach gesagt ist ein Design System eine Bibliothek aus gemeinsam genutzten, weiterentwickelten und wiederverwendbaren Komponenten.

Design Systems: Open Source und selbst entwickelt

Es gibt grob zwei verschiedene Arten von Design Systems:

1. Open-Source-Design-Systems, die von der Community entwickelt werden und allen zur Verfügung stehen, etwa Google Material Design, Carbon oder Polaris.

2. Design Systems, die ausschließlich für eine Organisation oder von der Organisation selbst entwickelt wurden, wie https://unity.com/design-portal oder https://www.eficode.com/cases/vaisala

Eines meiner liebsten offenen Design Systems ist das Australian Government Design System. Es umfasst das Design, HTML- und CSS-Beispiele sowie React-Komponenten. React gehört zu den beliebtesten JavaScript-Frameworks für Benutzeroberflächen und wurde von Facebook entwickelt, das es auch weiterhin pflegt.

Ein gutes Design System sollte nicht nur das Design, sondern auch den Code dahinter enthalten. Für einen Button stehen Entwicklern beispielsweise bereits JavaScript-/React-, HTML- und CSS-Code zur Verfügung, um diesen Button und sein Verhalten abzubilden.

DevOps beginnt in der Designphase

Traditionell besteht eine Lücke zwischen Design- und Entwicklungsphase. Das liegt daran, dass das Design von UI-Spezialisten geprägt wird, die gerne mit Benutzeroberflächen arbeiten, während DevOps traditionell in der Verantwortung von Operations- und Backend-Entwicklern liegt.

Ein durchdachtes Design System, das DevOps einschließt, ist eine effiziente Möglichkeit, diese Lücke zu schließen.

Bei der Gestaltung der User Experience (UX) – also der eigentlichen grafischen Gestaltung einer Anwendung oder eines Services – müsst ihr das Ergebnis letztlich in ein digitales Format überführen. Verschiedene Designanwendungen wie InVision, Figma oder ähnliche Tools übernehmen bereits vor der Entwicklungsphase einen Teil der Arbeit für Designer und Entwickler. Die Verbindung beginnt, sobald sie das Design implementieren. Das bedeutet: DevOps beginnt bereits in der Designphase.

Unterstützen gute Design Systems Entwicklung und Deployment?

Vielleicht fragt ihr euch nun, wie ein gut implementiertes Design System aussieht, wenn es reibungslos in DevOps-Praktiken und -Tools integriert ist. Ein durchdachtes Design System, das DevOps effizient unterstützt, umfasst:

• Als React-Komponenten geschriebene Komponenten, einschließlich passendem Styling und Interaktionen.

• Unit-Tests, beispielsweise UI-Komponententests in Jest.

• Beispiele dafür, wie die Benutzeroberfläche mit dem eigentlichen Backend oder Kern der Anwendung verbunden ist.

• Eine Verbindung zur Infrastruktur / Infrastructure as Code.

• Die Delivery-Pipeline sowie die Einbindung eurer Anwendung in das gesamte Automatisierungs-Framework.

Sobald ihr in einem gut implementierten Design System an einer Anwendung arbeitet, befindet sich die Anwendung genau in dem Moment in der Produktionsumgebung, in dem ihr mit der Arbeit beginnt. Das nennen wir bei Eficode Zero-Day Delivery – und genau das habe ich gestern Abend ausprobiert, als ich meine Anwendung in nur wenigen Stunden entwickelte.

Ihr startet die Anwendung mit einer Vorlage, die auf dem Design System basiert. Nach dem ersten Commit ist sie bereits mit eurer Continuous-Delivery-Pipeline verbunden und in die Produktionsumgebung ausgeliefert.

Delivery und Release sind nicht dasselbe

Diese Arbeitsweise nimmt Situationen die Anspannung, die traditionell als die beängstigenden Momente der Wahrheit gelten – ihr kennt den Moment: Ihr drückt den Button, veröffentlicht eure Anwendung für eure Nutzer, drückt die Daumen und hofft, dass alles gut geht.

Ich empfehle, die Begriffe „Delivery“ und „Release“ voneinander zu trennen. Delivery sollte der unspektakuläre Teil sein, da ihr die implementierten Features kontinuierlich ausliefern solltet.

Mit Continuous Delivery (oder Deployment) liefert ihr eine funktionierende Anwendung mit noch nicht fertigen Features in die Produktionsumgebung aus. Anschließend blendet ihr die Funktionen entweder für eure Nutzer aus oder lasst sie im Hintergrund laufen. Ein Release erfolgt, wenn ihr diese Features tatsächlich für eure Nutzer freischaltet.

Bei dieser Arbeitsweise ist ein Fehler kein großes Problem, denn ihr könnt schnell zurückrollen oder Fehler beheben. Und am Tag des Releases wisst ihr bereits, dass alles funktioniert, weil ihr die Fehler schon früher gemacht habt.

Gute Design Systems können die Unternehmenskultur verändern

Diese moderne und flüssige Arbeitsweise muss durch einen Kulturwandel im Unternehmen unterstützt werden. Menschen aus verschiedenen Bereichen müssen zusammenarbeiten, damit DevOps und Design Systems integriert werden können. Ihr müsst eine Feedbackschleife zwischen den Menschen schaffen, die das Design System entwickeln, und denen, die es einsetzen.

Es gibt nicht den einen Weg, sondern eine Reihe von Fragen, die ihr beantworten müsst, bevor ihr entscheidet, wie ihr vorgeht:

• Welche Praktiken braucht ihr, um das Design System und seine Komponenten tatsächlich zu entwickeln, zu implementieren und zu teilen?

• Habt ihr ein zentrales Team, das für das Design System verantwortlich ist?

• Habt ihr eine eigene Continuous-Delivery-Pipeline für das Design System, in der ihr beispielsweise über Pull Requests von Entwicklern zusammenarbeiten könnt?

Welche Praktiken braucht ihr, um das Design System und seine Komponenten tatsächlich zu entwickeln, zu implementieren und zu teilen?

Habt ihr ein zentrales Team, das für das Design System verantwortlich ist?

Habt ihr eine eigene Continuous-Delivery-Pipeline für das Design System, in der ihr beispielsweise über Pull Requests von Entwicklern zusammenarbeiten könnt?

Ihr müsst außerdem entscheiden, ob ihr das Design System community-getrieben gestalten möchtet, wie etwa das Design System der australischen Regierung. Dort kann jeder einen Pull Request erstellen. Anschließend entscheiden einige wenige Personen, ob dieser genehmigt und in das Design System übernommen wird oder nicht.

Startet mit einer Practice Community oder einer Pilotgruppe

DevOps in das Design System zu integrieren, muss kein großes Vorhaben sein. Die meisten Unternehmen, zumindest die größeren, haben bereits ein Design System. Vielleicht besteht es nur aus Gestaltungsrichtlinien, oder ihre HTML- und CSS-Bibliotheken sind bereits verbunden. Wahrscheinlich gibt es auch schon Anwendungen, die entsprechend dem Design System entwickelt wurden. Ihr müsst also nicht bei null anfangen.

Eine Möglichkeit, das Design System weiterzuentwickeln, besteht darin, eine Practice Community aus Gleichgesinnten aufzubauen, die sich für eine gemeinsame Aufgabe zusammenschließen.

Eine weitere Möglichkeit ist, einfach mit einem eurer aktuellen Projekte zu starten, in dem es Menschen gibt, die daran interessiert und in der Lage sind, es auszuprobieren.

In der Regel lassen sich diese Dinge relativ einfach ausprobieren und umsetzen. Der schwierige Teil besteht darin, die Unternehmenskultur und Arbeitsweisen zu verändern. Deshalb setzen wir bei Eficode bevorzugt auf Pilotprojekte. Wenn ihr gerade eine neue Anwendung entwickelt, würde ich das Design System rund um diese Anwendung aufbauen.

Wenn eure Continuous-Delivery-Pipeline steht, könnt ihr erreichen, was wir Zero-Day Delivery nennen. Mit anderen Worten: Sobald ihr mit dem Design eines neuen Services beginnt, seid ihr bereits in Produktion.