Ein wichtiger Baustein sind dabei nachvollziehbare und wiederholbare Abl\u00e4ufe. Eine neue Version sollte m\u00f6glichst nach einem festgelegten Verfahren erstellt, getestet und bereitgestellt werden. Wiederkehrende Schritte lassen sich automatisieren. Dadurch h\u00e4ngt weniger davon ab, ob jemand gerade an jede Kleinigkeit denkt oder eine Anleitung fehlerfrei von Hand abarbeitet.<\/p>\n
Genauso wichtig ist die R\u00fcckmeldung aus dem laufenden Betrieb. Wird die Anwendung nach einer \u00c4nderung langsamer oder treten bestimmte Fehler h\u00e4ufiger auf, braucht das Entwicklungsteam diese Informationen. So lassen sich Ursachen untersuchen und Verbesserungen gezielt angehen. Die Arbeit endet also nicht mit der Ver\u00f6ffentlichung einer neuen Version: Was im Betrieb passiert, hilft dabei, die Software weiterzuentwickeln.<\/p>\n
DevOps ist deshalb vor allem eine Frage der Zusammenarbeit und der gemeinsamen Verantwortung. Die passenden Werkzeuge k\u00f6nnen viel erleichtern: Sie f\u00fchren Tests aus, unterst\u00fctzen die Bereitstellung oder machen Probleme sichtbar. Ihren Nutzen entfalten sie aber erst, wenn das Team wei\u00df, was es damit erreichen m\u00f6chte und wer auf die Ergebnisse reagiert. Ziel ist, Probleme fr\u00fcher zu erkennen, vermeidbare Fehler zu reduzieren und \u00c4nderungen mit mehr Sicherheit zu ver\u00f6ffentlichen.<\/p>\n
Git: \u00c4nderungen nachvollziehbar festhalten<\/h2>\n
Daf\u00fcr werden zusammengeh\u00f6rige \u00c4nderungen als Commit<\/strong> festgehalten. Einen Commit kannst du dir wie einen bewusst gesetzten Zwischenstand vorstellen, den du mit einer kurzen Beschreibung versiehst \u2013 beispielsweise \u201eFehlermeldung bei falschem Passwort erg\u00e4nzt\u201c. Das normale Speichern einer Datei im Editor reicht daf\u00fcr noch nicht aus: Zun\u00e4chst speicherst du deine Arbeit, anschlie\u00dfend entscheidest du, welche \u00c4nderungen du in den n\u00e4chsten Commit aufnehmen m\u00f6chtest. So entsteht nach und nach eine verst\u00e4ndliche Geschichte deines Projekts.<\/p>\n Besonders praktisch sind die sogenannten Branches<\/strong>, also Entwicklungszweige. Stell dir vor, die Anmeldung deiner Anwendung funktioniert und du m\u00f6chtest eine neue Funktion ausprobieren. Daf\u00fcr kannst du einen eigenen Branch anlegen. Dort bearbeitest du deine \u00c4nderungen, w\u00e4hrend der Hauptentwicklungszweig zun\u00e4chst unver\u00e4ndert bleibt. Auch mehrere Personen k\u00f6nnen auf diese Weise parallel an unterschiedlichen Aufgaben arbeiten.<\/p>\n Ist die neue Funktion fertig und gepr\u00fcft, k\u00f6nnen ihre \u00c4nderungen wieder in den Hauptentwicklungszweig \u00fcbernommen werden. Dieses Zusammenf\u00fchren nennt man Merge<\/em>. Git kann dabei vieles automatisch erledigen. Haben aber beispielsweise zwei Personen dieselbe Textstelle unterschiedlich bearbeitet, kann ein Konflikt<\/em> entstehen. Dann muss jemand entscheiden, wie die gemeinsame Fassung aussehen soll. Git zeigt die betroffenen Stellen an \u2013 welche L\u00f6sung fachlich richtig ist, beurteilt das Team.<\/p>\n Das Wort \u201everteilt\u201c<\/strong> bedeutet bei Git, dass die Versionsgeschichte nicht ausschlie\u00dflich auf einem zentralen Server liegt. Bei einer vollst\u00e4ndigen Kopie eines Projekts hast du auch dessen bisherige Historie auf deinem Rechner. Deshalb kannst du viele Aufgaben ohne Internet erledigen: \u00c4nderungen bearbeiten, Commits erstellen, Entwicklungszweige anlegen oder fr\u00fchere St\u00e4nde vergleichen. Erst wenn du \u00c4nderungen mit anderen austauschen m\u00f6chtest, brauchst du eine Verbindung zum jeweiligen Gegen\u00fcber oder zu einer gemeinsamen Ablage.<\/p>\n Eine solche Projektablage hei\u00dft Repository<\/strong>. F\u00fcr die Zusammenarbeit wird h\u00e4ufig zus\u00e4tzlich ein entferntes Repository verwendet, auf das das Team zugreifen kann. Daf\u00fcr braucht es nicht zwingend GitHub oder GitLab: Auch ein eigener Git-Server ist m\u00f6glich. Was diese Plattformen dar\u00fcber hinaus bieten, schauen wir uns im n\u00e4chsten Abschnitt an.<\/p>\n Praxisbeispiel:<\/strong> Du m\u00f6chtest die Anmeldung deiner Anwendung um verst\u00e4ndlichere Fehlermeldungen erg\u00e4nzen. Daf\u00fcr legst du einen eigenen Branch an. In einem ersten Commit h\u00e4ltst du die neuen Meldungen fest, in einem weiteren die dazugeh\u00f6rigen Tests. Nach der gemeinsamen Pr\u00fcfung werden die \u00c4nderungen \u00fcbernommen. F\u00e4llt sp\u00e4ter ein Problem auf, l\u00e4sst sich gezielt nachvollziehen, was an der Anmeldung ver\u00e4ndert wurde. Genau diese Nachvollziehbarkeit macht Git f\u00fcr die Zusammenarbeit und die Fehlersuche so wertvoll.<\/p>\n Der Vorteil ist, dass sich dort auch die Arbeit rund um den Code organisieren l\u00e4sst. Hat jemand einen Fehler entdeckt oder eine Idee f\u00fcr eine neue Funktion, kann daf\u00fcr eine Aufgabe angelegt werden \u2013 ein sogenanntes Issue<\/em>. Darin l\u00e4sst sich beschreiben, was zu tun ist, wer sich darum k\u00fcmmert und welche Fragen noch offen sind. So bleiben Informationen direkt beim Projekt und verteilen sich nicht auf E-Mails, Chatnachrichten und pers\u00f6nliche Notizzettel.<\/p>\n Besonders hilfreich finde ich die M\u00f6glichkeit, \u00c4nderungen gemeinsam anzuschauen, bevor sie in den Hauptentwicklungsstand \u00fcbernommen werden. Stell dir vor, du hast die Anmeldung einer Anwendung erweitert. Deine \u00c4nderungen hast du zun\u00e4chst in einem eigenen Entwicklungszweig, einem Branch<\/em>, umgesetzt. Jetzt m\u00f6chtest du sie dem Team vorstellen. Dazu er\u00f6ffnest du auf GitHub einen Pull Request<\/em> oder auf GitLab einen Merge Request<\/em>. Die Bezeichnungen unterscheiden sich, die Grundidee ist dieselbe: \u201eMeine \u00c4nderungen sind bereit. Schaut bitte einmal dr\u00fcber, bevor wir sie \u00fcbernehmen.\u201c<\/p>\n Die anderen k\u00f6nnen dann genau sehen, welche Stellen du ver\u00e4ndert hast. Sie k\u00f6nnen Fragen stellen, Hinweise geben oder Verbesserungen vorschlagen. Diese gemeinsame Durchsicht nennt man Code-Review<\/em>. Gerade in der Ausbildung ist das eine sch\u00f6ne Gelegenheit, voneinander zu lernen: Warum wurde etwas auf diese Weise gel\u00f6st? Gibt es eine verst\u00e4ndlichere Variante? Wurde ein m\u00f6glicher Fehlerfall ber\u00fccksichtigt? Ob vor der \u00dcbernahme zwingend jemand zustimmen muss, l\u00e4sst sich \u00fcber die Regeln des Projekts festlegen.<\/p>\n Beide Plattformen k\u00f6nnen au\u00dferdem wiederkehrende Arbeitsschritte automatisch ausf\u00fchren. Bei GitHub \u00fcbernimmt das GitHub Actions<\/em>, bei GitLab GitLab CI\/CD<\/em>. Beispielsweise kann nach einer \u00c4nderung automatisch gepr\u00fcft werden, ob sich die Anwendung noch erstellen l\u00e4sst und die vorhandenen automatisierten Tests erfolgreich durchlaufen. Das Team bekommt dadurch fr\u00fch eine R\u00fcckmeldung, ob die \u00c4nderung m\u00f6glicherweise etwas besch\u00e4digt hat.<\/p>\n Welche Plattform besser passt, h\u00e4ngt deshalb vor allem davon ab, wie das Team arbeitet: Welche Werkzeuge sind schon vorhanden? Was soll automatisiert werden? Und m\u00f6chte man die Plattform als Dienst nutzen oder selbst betreiben? F\u00fcr den Einstieg ist mir vor allem wichtig, dass die Rollen klar sind: Git h\u00e4lt die \u00c4nderungen fest. GitHub und GitLab helfen dabei, gemeinsam an diesen \u00c4nderungen zu arbeiten und die Abl\u00e4ufe drumherum zu organisieren.<\/strong><\/p>\n Zwischen einer \u00c4nderung am Programmcode und einer neuen Version, die von den Nutzern verwendet werden kann, liegen mehrere Arbeitsschritte. Die Anwendung muss erstellt, gepr\u00fcft und schlie\u00dflich in der vorgesehenen Umgebung bereitgestellt werden. Damit diese Aufgaben nachvollziehbar und m\u00f6glichst automatisch ablaufen, werden sie h\u00e4ufig in einer Pipeline<\/strong> organisiert. Du kannst dir eine Pipeline wie einen festgelegten Arbeitsablauf mit mehreren Stationen vorstellen. An einer Station wird aus dem Quellcode eine ausf\u00fchrbare Anwendung oder ein Softwarepaket erstellt. Diesen Vorgang nennt man Build<\/em>. An weiteren Stationen laufen beispielsweise automatisierte Tests oder eine Codeanalyse. Sind die vorgesehenen Pr\u00fcfungen erfolgreich, kann die Anwendung auf einer Testumgebung bereitgestellt werden. Schl\u00e4gt eine wichtige Pr\u00fcfung fehl, wird der weitere Ablauf entsprechend den eingerichteten Regeln gestoppt.<\/p>\n In diesem Zusammenhang begegnet dir h\u00e4ufig die Abk\u00fcrzung CI\/CD<\/strong>. Dahinter stehen eng miteinander verbundene Vorgehensweisen. Gerade bei \u201eCD\u201c lohnt es sich, genauer hinzuschauen, denn das kann sowohl Continuous Delivery<\/em> als auch Continuous Deployment<\/em> bedeuten.<\/p>\n Continuous Integration (CI): \u00c4nderungen regelm\u00e4\u00dfig zusammenf\u00fchren und pr\u00fcfen<\/strong><\/p>\n Wenn mehrere Personen an einer Anwendung arbeiten, m\u00fcssen ihre \u00c4nderungen irgendwann zusammenpassen. Bei Continuous Integration werden \u00c4nderungen deshalb h\u00e4ufig und m\u00f6glichst in kleinen Schritten in einen gemeinsamen Entwicklungsstand integriert. Automatisierte Builds und Tests liefern dazu fr\u00fch eine R\u00fcckmeldung.<\/p>\n Stell dir vor, du ver\u00e4nderst die Anmeldung, w\u00e4hrend ein Kollege an der Benutzerverwaltung arbeitet. F\u00fcr sich genommen k\u00f6nnen beide \u00c4nderungen funktionieren. Ob sie auch gemeinsam funktionieren, zeigt sich erst beim Zusammenf\u00fchren und Pr\u00fcfen. Je fr\u00fcher das passiert, desto leichter l\u00e4sst sich ein auftretendes Problem meist eingrenzen. F\u00fcr mich liegt darin ein wesentlicher Vorteil von CI: Das Team bekommt zeitnah Hinweise, solange die \u00c4nderungen noch \u00fcberschaubar und gedanklich pr\u00e4sent sind.<\/p>\n Continuous Delivery: Eine ver\u00f6ffentlichungsf\u00e4hige Version bereithalten<\/strong><\/p>\n Continuous Delivery f\u00fchrt diesen Gedanken weiter. Die Software durchl\u00e4uft einen wiederholbaren Ablauf, der sie erstellt, pr\u00fcft und f\u00fcr eine Ver\u00f6ffentlichung vorbereitet. Ziel ist, eine Version bereitzuhalten, die bei Bedarf zuverl\u00e4ssig in den Produktivbetrieb \u00fcbernommen werden kann \u2013 also in die Umgebung, mit der die tats\u00e4chlichen Nutzer arbeiten.<\/p>\n Die Ver\u00f6ffentlichung kann dabei weiterhin eine bewusste Entscheidung sein. Beispielsweise pr\u00fcft das Team die Version zus\u00e4tzlich auf einer Testumgebung und gibt sie anschlie\u00dfend frei. Die technischen Schritte sind weitgehend automatisiert, aber der Zeitpunkt der Ver\u00f6ffentlichung wird gezielt festgelegt.<\/p>\n Continuous Deployment: Erfolgreich gepr\u00fcfte \u00c4nderungen automatisch ver\u00f6ffentlichen<\/strong><\/p>\n Bei Continuous Deployment entf\u00e4llt diese zus\u00e4tzliche manuelle Freigabe vor jeder Ver\u00f6ffentlichung. Eine \u00c4nderung, die alle vorgesehenen automatisierten Pr\u00fcfungen erfolgreich durchl\u00e4uft, wird automatisch in den Produktivbetrieb \u00fcbernommen.<\/p>\n Das setzt gro\u00dfes Vertrauen in die Pr\u00fcfungen und den Bereitstellungsprozess voraus. Auch die \u00dcberwachung nach der Ver\u00f6ffentlichung und ein geeigneter Umgang mit Problemen m\u00fcssen mitgedacht werden. Automatisierte Tests k\u00f6nnen schlie\u00dflich nur die F\u00e4lle \u00fcberpr\u00fcfen, f\u00fcr die sie eingerichtet wurden.<\/p>\n Praxisbeispiel:<\/strong> Du erg\u00e4nzt eine verst\u00e4ndlichere Fehlermeldung bei der Anmeldung. Im Rahmen von CI wird die \u00c4nderung mit dem gemeinsamen Entwicklungsstand zusammengef\u00fchrt und automatisch gepr\u00fcft. Bei Continuous Delivery wird daraus eine ver\u00f6ffentlichungsf\u00e4hige Version vorbereitet, deren Produktivsetzung noch freigegeben werden kann. Bei Continuous Deployment erfolgt auch dieser letzte Schritt automatisch, sobald alle vorgesehenen Pr\u00fcfungen bestanden sind.<\/p>\n Dieser Arbeitsplan wird in einer Textdatei im Format YAML<\/em> festgehalten. Die Dateien liegen im Projektverzeichnis unter Die eigentliche Arbeit \u00fcbernehmen sogenannte Runner<\/strong>. Das sind die Ausf\u00fchrungsumgebungen, auf denen die festgelegten Schritte abgearbeitet werden. Du kannst sie dir wie einen zus\u00e4tzlichen Rechner vorstellen, der deinen Arbeitsplan ausf\u00fchrt. Ein Workflow beschreibt also die Aufgaben \u2013 der Runner erledigt sie. Damit l\u00e4sst sich weit mehr als ein Testlauf automatisieren. Ein Workflow kann beispielsweise die Anwendung erstellen, sie als Container-Image verpacken oder auf einer Testumgebung bereitstellen. Welche Schritte sinnvoll sind und aufeinander folgen, legst du passend zu deinem Projekt fest.<\/p>\n Praxisbeispiel:<\/strong> Du hast die Anmeldung deiner Anwendung erweitert und er\u00f6ffnest einen Pull Request. Daraufhin startet GitHub Actions automatisch die daf\u00fcr eingerichteten Tests. Schl\u00e4gt einer davon fehl, wird das Ergebnis beim Pull Request sichtbar. Du kannst dir die Ausgabe ansehen und die Ursache untersuchen, bevor die \u00c4nderung \u00fcbernommen wird. Gerade im Team finde ich diese fr\u00fche R\u00fcckmeldung hilfreich: Alle Beteiligten k\u00f6nnen sehen, welche Pr\u00fcfungen bereits erfolgreich waren und wo noch etwas gekl\u00e4rt werden muss.<\/p>\n Den Arbeitsplan daf\u00fcr hinterlegst du normalerweise in der Datei Au\u00dferdem kannst du Regeln festlegen: Welche Aufgaben sollen bei jeder \u00c4nderung ausgef\u00fchrt werden? Welche nur dann, wenn eine neue Version ver\u00f6ffentlicht werden soll? Und an welcher Stelle m\u00f6chtest du eine manuelle Freigabe einbauen? Bei gr\u00f6\u00dferen Projekten l\u00e4sst sich die Konfiguration auf mehrere Dateien verteilen oder um wiederverwendbare Vorlagen erg\u00e4nzen. So muss nicht jedes Team denselben Ablauf von Grund auf neu beschreiben.<\/p>\n Die eigentliche Arbeit \u00fcbernehmen GitLab Runner.<\/strong> Sie nehmen die Jobs entgegen und f\u00fchren die darin beschriebenen Anweisungen in einer passenden Umgebung aus. Daf\u00fcr m\u00fcssen die ben\u00f6tigten Voraussetzungen vorhanden sein: Ein Testlauf braucht beispielsweise die passende Programmiersprache und die verwendeten Testwerkzeuge. Soll die Anwendung auf einen Server \u00fcbertragen werden, werden zus\u00e4tzlich eine erreichbare Zielumgebung und die erforderlichen Zugriffsrechte ben\u00f6tigt. Die Pipeline-Datei ist also der Arbeitsplan; Runner und Ausf\u00fchrungsumgebung sorgen daf\u00fcr, dass er umgesetzt werden kann.<\/p>\n Praxisbeispiel:<\/strong> Du hast die Anmeldung deiner Anwendung \u00fcberarbeitet und \u00fcbertr\u00e4gst deine \u00c4nderungen zu GitLab. Die Pipeline erstellt zun\u00e4chst die Anwendung und f\u00fchrt anschlie\u00dfend die automatisierten Tests aus. Sind diese erfolgreich, kann die neue Version auf einer Testumgebung bereitgestellt werden. Dort l\u00e4sst sie sich zus\u00e4tzlich ausprobieren und pr\u00fcfen. Die Ver\u00f6ffentlichung im Produktivbetrieb kann weiterhin eine bewusste Freigabe erfordern. Gerade diese Verbindung aus automatischen Pr\u00fcfungen und gezielten Entscheidungen finde ich hilfreich: Wiederkehrende Arbeit wird abgenommen, w\u00e4hrend das Team die Kontrolle \u00fcber die Ver\u00f6ffentlichung beh\u00e4lt.<\/p>\n Ein solcher Ablauf l\u00e4sst sich als Pipeline<\/em> in einer Datei namens Viel von seiner Flexibilit\u00e4t erh\u00e4lt Jenkins durch Erweiterungen, sogenannte Plugins. Sie erm\u00f6glichen die Anbindung weiterer Werkzeuge und Dienste. So kann Jenkins beispielsweise mit einer Codeverwaltung zusammenarbeiten, Testergebnisse aufbereiten oder Benachrichtigungen versenden. Die einzelnen Aufgaben k\u00f6nnen au\u00dferdem auf zus\u00e4tzlichen Ausf\u00fchrungsrechnern erledigt werden, den sogenannten Agents<\/em>. Das ist praktisch, wenn unterschiedliche Aufgaben verschiedene Umgebungen ben\u00f6tigen oder mehrere Arbeiten parallel laufen sollen. Dieser Gestaltungsspielraum bringt allerdings auch Verantwortung mit sich. Wer Jenkins selbst betreibt, muss sich um Updates, die verwendeten Plugins, Zugriffsrechte und die Ausf\u00fchrungsumgebungen k\u00fcmmern. Auch die Automatisierung braucht also Pflege, damit sie dauerhaft zuverl\u00e4ssig funktioniert. Bei der Auswahl w\u00fcrde ich deshalb immer mit betrachten, wer diese Aufgaben \u00fcbernimmt und wie viel Aufwand das Team daf\u00fcr einplanen kann.<\/p>\n Praxisbeispiel:<\/strong> Ein Team m\u00f6chte seine Webanwendung nach jeder \u00c4nderung automatisch pr\u00fcfen. Jenkins holt sich daf\u00fcr den aktuellen Code, erstellt die Anwendung und startet die vorgesehenen Tests. Schl\u00e4gt ein Test fehl, kann das Team die Ergebnisse und Protokolle einsehen und die Ursache untersuchen. Sind alle Pr\u00fcfungen erfolgreich, kann die Pipeline die Anwendung anschlie\u00dfend auf einer Testumgebung bereitstellen. Der Vorteil liegt f\u00fcr mich vor allem darin, dass dieser festgelegte Ablauf wiederholbar ausgef\u00fchrt wird und seine Ergebnisse f\u00fcr das Team nachvollziehbar bleiben.<\/p>\n Dieses Paket hei\u00dft Image<\/strong>. Darin stecken beispielsweise der Anwendungscode, ben\u00f6tigte Bibliotheken und die passende Laufzeitumgebung \u2013 also die Software, die zum Ausf\u00fchren der Anwendung erforderlich ist. Du kannst dir das Image wie eine vorbereitete Vorlage vorstellen, aus der sich immer wieder dieselbe Ausgangsumgebung erzeugen l\u00e4sst. Wie diese Vorlage entsteht, beschreibt eine Datei namens Ein Container ist eine aus diesem Image erzeugte Instanz, in der die Anwendung ausgef\u00fchrt werden kann. Der Unterschied l\u00e4sst sich gut merken: Das Image ist die Vorlage, der Container die daraus erzeugte Umgebung. Aus demselben Image k\u00f6nnen mehrere Container entstehen, beispielsweise f\u00fcr verschiedene Testl\u00e4ufe. Jeder davon besitzt seine eigene beschreibbare Schicht. Daten, die dauerhaft erhalten bleiben sollen, etwa Datenbankinhalte, m\u00fcssen deshalb gezielt au\u00dferhalb dieser austauschbaren Schicht gespeichert werden. Der gro\u00dfe Vorteil ist, dass sich ein einmal erstelltes Image auf dem Entwicklungsrechner, in der Testumgebung und sp\u00e4ter im Produktivbetrieb verwenden l\u00e4sst \u2013 vorausgesetzt, die jeweilige Umgebung ist daf\u00fcr geeignet. Viele Unterschiede durch manuelle Installationen entfallen dadurch. Das macht die Bereitstellung einer Anwendung besser nachvollziehbar und wiederholbar.<\/p>\n Ganz verschwinden die Unterschiede zwischen den Umgebungen allerdings nicht. Eine Anwendung braucht m\u00f6glicherweise weiterhin eine erreichbare Datenbank, passende Zugangsdaten oder bestimmte Netzwerkeinstellungen. Auch die Prozessorarchitektur kann eine Rolle spielen. Docker schafft also eine einheitlichere Grundlage, ersetzt aber weder die richtige Konfiguration noch die Pr\u00fcfung unter den tats\u00e4chlichen Einsatzbedingungen.<\/p>\n H\u00e4ufig kommt an dieser Stelle die Frage auf: Ist ein Container nicht einfach eine kleine virtuelle Maschine? Der Vergleich ist verst\u00e4ndlich, technisch gibt es aber einen wichtigen Unterschied. Eine virtuelle Maschine<\/strong> betreibt ein eigenes Betriebssystem mit einem eigenen Kernel<\/em>, also dem zentralen Betriebssystemkern. Container teilen sich dagegen den Kernel der Umgebung, in der sie laufen. Dadurch ben\u00f6tigen sie h\u00e4ufig weniger Ressourcen und k\u00f6nnen schnell gestartet werden. Auf manchen Systemen stellt eine virtuelle Maschine im Hintergrund erst die passende Umgebung f\u00fcr diese Container bereit. Container und virtuelle Maschinen lassen sich deshalb gut miteinander kombinieren. Beispielsweise kann auf einem Server eine virtuelle Maschine laufen, in der wiederum mehrere Container betrieben werden. Welche Aufteilung sinnvoll ist, h\u00e4ngt unter anderem von den Anforderungen an Betrieb, Sicherheit und Wartung ab.<\/p>\n Praxisbeispiel:<\/strong> Das Team hat die Anmeldung seiner Webanwendung erweitert. Die Pipeline erstellt daraus ein neues Image und stellt es zun\u00e4chst in der Testumgebung bereit. Dort wird die Anwendung gepr\u00fcft. Sind die vorgesehenen Pr\u00fcfungen erfolgreich, wird genau dieselbe Image-Version f\u00fcr die Ver\u00f6ffentlichung verwendet. F\u00fcr mich liegt darin ein wichtiger Vorteil: Die Anwendung wird zwischen Test und Ver\u00f6ffentlichung nicht noch einmal neu zusammengestellt. Die gepr\u00fcfte Grundlage bleibt erhalten \u2013 auch wenn beispielsweise die Verbindung zur Datenbank f\u00fcr den Produktivbetrieb anders konfiguriert wird.<\/p>\n Kubernetes verwaltet containerisierte Anwendungen in einem sogenannten Cluster<\/strong>. Damit ist eine Gruppe von Rechnern gemeint, die zusammenarbeiten. Das k\u00f6nnen physische Server oder virtuelle Maschinen sein. Du kannst dir Kubernetes dabei wie eine Betriebskoordination vorstellen: Es verteilt die vorgesehenen Anwendungen auf geeignete Rechner und \u00fcberpr\u00fcft regelm\u00e4\u00dfig, ob der tats\u00e4chliche Zustand noch zu den Vorgaben passt.<\/p>\n Die kleinste Einheit, die Kubernetes dabei bereitstellt und verwaltet, hei\u00dft Pod<\/strong>. In einem Pod l\u00e4uft ein Container oder eine kleine Gruppe eng zusammengeh\u00f6riger Container. Das k\u00f6nnte beispielsweise deine Webanwendung zusammen mit einem zus\u00e4tzlichen Hilfsdienst sein. Die Container innerhalb eines Pods teilen sich bestimmte Ressourcen, etwa die Netzwerkumgebung, und werden gemeinsam auf einem Rechner untergebracht. F\u00fcr den Einstieg reicht zun\u00e4chst die Vorstellung: Ein Pod ist die gemeinsame H\u00fclle, in der Kubernetes diese Container betreibt.<\/p>\n Besonders wichtig ist das Prinzip des gew\u00fcnschten Zustands. Du beschreibst beispielsweise: \u201eVon meiner Webanwendung sollen dauerhaft drei Exemplare laufen.\u201c Kubernetes versucht dann, diese Vorgabe einzuhalten. F\u00e4llt ein entsprechend verwalteter Pod aus, kann ein neuer als Ersatz angelegt werden. F\u00e4llt ein ganzer Rechner aus, k\u00f6nnen betroffene Anwendungen auf anderen geeigneten Rechnern neu gestartet werden \u2013 sofern dort gen\u00fcgend Ressourcen zur Verf\u00fcgung stehen und die \u00fcbrigen Voraussetzungen erf\u00fcllt sind. Auch bei Aktualisierungen hilft dieses Prinzip. Statt alle laufenden Exemplare einer Anwendung gleichzeitig zu beenden, kann Kubernetes sie schrittweise durch die neue Version ersetzen. Das nennt man ein Rolling Update<\/em>. W\u00e4hrend ein Teil bereits aktualisiert wird, bedienen andere Exemplare weiterhin Anfragen. Damit das zuverl\u00e4ssig funktioniert, muss unter anderem gepr\u00fcft werden k\u00f6nnen, ob die neuen Exemplare tats\u00e4chlich bereit sind, Anfragen zu \u00fcbernehmen. Eine unterbrechungsfreie Aktualisierung ergibt sich also nicht allein daraus, dass Kubernetes eingesetzt wird.<\/p>\n Ein weiterer Begriff, dem du dabei begegnen wirst, ist Skalierung. Gemeint ist, die verf\u00fcgbare Kapazit\u00e4t an den Bedarf anzupassen. Wird deine Anwendung st\u00e4rker genutzt, k\u00f6nnen beispielsweise zus\u00e4tzliche Exemplare gestartet werden. Sinkt die Auslastung wieder, l\u00e4sst sich deren Anzahl reduzieren. Das kann mit passenden Messwerten und Regeln automatisch erfolgen. Die daf\u00fcr ben\u00f6tigte Rechenleistung muss allerdings vorhanden sein oder zus\u00e4tzlich bereitgestellt werden k\u00f6nnen. Auch muss die Anwendung daf\u00fcr geeignet sein, mit mehreren parallel laufenden Exemplaren zu arbeiten.<\/p>\n Praxisbeispiel:<\/strong> Ein Onlineshop erwartet w\u00e4hrend einer Rabattaktion deutlich mehr Besucher. Mit einer entsprechend eingerichteten automatischen Skalierung k\u00f6nnen zus\u00e4tzliche Exemplare der Webanwendung gestartet werden, um mehr Anfragen zu bearbeiten. F\u00e4llt eines aus, sorgt Kubernetes f\u00fcr Ersatz. Eine langsame Datenbank oder einen Fehler im Bestellprozess behebt das allerdings nicht automatisch. Deshalb bleiben eine durchdachte Architektur, aussagekr\u00e4ftige Tests und die \u00dcberwachung der gesamten Anwendung wichtig.<\/p>\n F\u00fcr mich ist Kubernetes deshalb vor allem dann interessant, wenn die Anforderungen an den Betrieb diesen zus\u00e4tzlichen Aufwand rechtfertigen. Der Cluster selbst muss schlie\u00dflich ebenfalls eingerichtet, abgesichert und gepflegt werden. Wer Docker nutzt, braucht also nicht automatisch auch Kubernetes. F\u00fcr eine kleine Anwendung kann eine einfachere Betriebsumgebung v\u00f6llig ausreichen. Entscheidend ist, welche Probleme tats\u00e4chlich gel\u00f6st werden sollen und ob das Team die gew\u00e4hlte L\u00f6sung zuverl\u00e4ssig betreiben kann.<\/p>\n Welche Rechner bearbeitet werden sollen, wird in einer \u00dcbersicht festgelegt, dem sogenannten Inventory<\/em>. Dort k\u00f6nnen Systeme auch zu Gruppen zusammengefasst werden, beispielsweise Entwicklungsserver und Testserver. So l\u00e4sst sich dieselbe Grundkonfiguration auf mehrere Rechner anwenden, w\u00e4hrend einzelne Einstellungen je nach Umgebung unterschiedlich bleiben d\u00fcrfen.<\/p>\n F\u00fcr die einzelnen Aufgaben verwendet Ansible Module<\/strong>. Das sind spezialisierte Bausteine, etwa zum Installieren von Softwarepaketen, zum Kopieren von Dateien oder zum Verwalten von Diensten. Du musst damit nicht jeden Arbeitsschritt selbst als Folge einzelner Systembefehle formulieren, sondern kannst h\u00e4ufig direkt beschreiben, welches Ergebnis du erreichen m\u00f6chtest.<\/p>\n Besonders hilfreich finde ich dabei ein Prinzip mit einem zun\u00e4chst etwas sperrigen Namen: Idempotenz<\/strong>. Gemeint ist, dass eine erneute Ausf\u00fchrung den bereits erreichten Zustand nicht unn\u00f6tig ver\u00e4ndert. Soll ein bestimmtes Softwarepaket installiert sein und ist es bereits vorhanden, muss nichts weiter passieren. Entspricht eine Konfigurationsdatei schon der vorgesehenen Fassung, braucht sie nicht erneut ge\u00e4ndert zu werden. Stell es dir wie eine Checkliste vor: Ansible pr\u00fcft bei entsprechend aufgebauten Aufgaben, welche Punkte bereits erf\u00fcllt sind, und erledigt die noch offenen Arbeiten. Dadurch kann ein Playbook wiederholt ausgef\u00fchrt werden, beispielsweise nachdem ein neuer Server hinzugekommen ist oder die gew\u00fcnschte Konfiguration angepasst wurde.<\/p>\n Dieses Verhalten ist allerdings nicht automatisch bei jeder Aufgabe gegeben. Wenn du in einem Playbook einen eigenen Shell-Befehl hinterlegst, der eine Zeile an eine Datei anh\u00e4ngt, k\u00f6nnte diese Zeile bei jedem Durchlauf erneut erg\u00e4nzt werden. Deshalb kommt es darauf an, geeignete Module zu verwenden und die Aufgaben sorgf\u00e4ltig zu formulieren. Auch ein automatisierter Ablauf muss gepr\u00fcft werden, bevor er auf wichtigen Systemen eingesetzt wird.<\/p>\n Praxisbeispiel:<\/strong> F\u00fcr eine Webanwendung werden ein Entwicklungs- und ein Testserver ben\u00f6tigt. Beide sollen denselben Webserver und eine vergleichbare Grundkonfiguration erhalten. Statt die Einrichtung zweimal von Hand durchzuf\u00fchren, beschreibt das Team sie in einem Ansible-Playbook. Unterschiede, etwa die jeweiligen Servernamen, werden gezielt als Werte f\u00fcr die passende Umgebung hinterlegt. Kommt sp\u00e4ter ein weiterer Testserver hinzu, l\u00e4sst sich dieselbe Arbeitsanweisung wiederverwenden. Das spart Arbeit und macht zugleich nachvollziehbar, wie die Systeme eingerichtet wurden.<\/p>\n Die Ergebnisse k\u00f6nnen unterschiedliche Bereiche betreffen. Manche Hinweise deuten auf m\u00f6gliche Programmfehler hin, andere auf Sicherheitsprobleme oder auf Code, der schwer verst\u00e4ndlich und aufwendig zu pflegen ist. Gerade diese Wartbarkeit wird leicht untersch\u00e4tzt. Schlie\u00dflich soll sich auch jemand im Code zurechtfinden, der die betreffende Funktion nicht selbst geschrieben hat \u2013 oder der nach einem Jahr wieder daran arbeiten muss. Welche Pr\u00fcfungen konkret m\u00f6glich sind, h\u00e4ngt unter anderem von der Programmiersprache sowie vom verwendeten SonarQube-Produkt und dessen Edition ab. Au\u00dferdem m\u00fcssen die Ergebnisse sinnvoll eingeordnet werden: Ein Hinweis ist ein Anlass, genauer hinzusehen. Er bedeutet nicht automatisch, dass die Anwendung an dieser Stelle tats\u00e4chlich einen Fehler verursacht.<\/p>\n Damit das Team aus den Ergebnissen klare Entscheidungen ableiten kann, gibt es sogenannte Quality Gates<\/strong>. Dahinter stehen festgelegte Qualit\u00e4tsbedingungen, die erf\u00fcllt sein sollen, bevor eine \u00c4nderung weitergegeben wird. Stell dir das wie einen vereinbarten Pr\u00fcfpunkt vor: Sind die Anforderungen erf\u00fcllt, kann der n\u00e4chste Schritt folgen. Sind sie nicht erf\u00fcllt, muss das Team zun\u00e4chst nacharbeiten oder den Befund kl\u00e4ren.<\/p>\n SonarQube l\u00e4sst sich daf\u00fcr in eine automatisierte Pipeline einbinden. Bei entsprechender Einrichtung kann ein nicht bestandenes Quality Gate verhindern, dass die Pipeline mit der Ver\u00f6ffentlichung fortf\u00e4hrt oder eine \u00c4nderung in den Hauptentwicklungszweig \u00fcbernommen wird. Diese Wirkung muss allerdings bewusst eingerichtet werden \u2013 allein durch die Installation von SonarQube wird noch keine Ver\u00f6ffentlichung blockiert.<\/p>\n Praxisbeispiel:<\/strong> Ein Team erweitert die Anmeldung seiner Webanwendung. Die automatisierten Funktionstests laufen erfolgreich durch. SonarQube weist jedoch darauf hin, dass eine neue Funktion sehr komplex geworden ist und sich dadurch nur schwer nachvollziehen l\u00e4sst. Das Team schaut sich die Stelle an und teilt sie in kleinere, verst\u00e4ndlichere Funktionen auf. Die Anmeldung verh\u00e4lt sich anschlie\u00dfend weiterhin wie vorgesehen, ihr Code l\u00e4sst sich aber leichter pr\u00fcfen und sp\u00e4ter \u00e4ndern.<\/p>\n Aus Sicht der Qualit\u00e4tssicherung finde ich diese zus\u00e4tzliche R\u00fcckmeldung wertvoll. Ein unauff\u00e4lliges Analyseergebnis ist allerdings kein Beweis daf\u00fcr, dass die Anwendung insgesamt fehlerfrei oder sicher ist. Ob sie die fachlichen Anforderungen erf\u00fcllt, verst\u00e4ndlich bedienbar ist oder bei vielen gleichzeitigen Zugriffen zuverl\u00e4ssig arbeitet, muss mit weiteren geeigneten Pr\u00fcfungen untersucht werden. SonarQube erg\u00e4nzt deshalb die Tests und das gemeinsame Code-Review um einen zus\u00e4tzlichen Blick auf den Quellcode.<\/p>\n Damit Prometheus an diese Informationen kommt, fragt es in regelm\u00e4\u00dfigen Abst\u00e4nden daf\u00fcr vorgesehene Schnittstellen ab. Manche Anwendungen stellen ihre Messwerte selbst bereit. In anderen F\u00e4llen \u00fcbernehmen kleine Hilfsprogramme diese Aufgabe, die sogenannten Exporter<\/strong>. Du kannst sie dir wie Messf\u00fchler vorstellen: Sie lesen Informationen \u00fcber ein System aus und stellen sie in einer Form bereit, die Prometheus verarbeiten kann.<\/p>\n Mit der Abfragesprache PromQL<\/strong> lassen sich die gesammelten Daten anschlie\u00dfend gezielt auswerten. Damit kann man beispielsweise untersuchen, wie hoch die durchschnittliche Auslastung in einem bestimmten Zeitraum war oder wie sich die Fehlerrate einer Anwendung entwickelt hat. F\u00fcr den Einstieg musst du diese Sprache noch nicht beherrschen. Wichtig ist zun\u00e4chst die Idee: Aus vielen einzelnen Messwerten werden Informationen, mit denen sich der Zustand eines Systems besser beurteilen l\u00e4sst.<\/p>\n Die Aufgabenverteilung l\u00e4sst sich deshalb gut merken: Prometheus sammelt die Messwerte und bewahrt ihren zeitlichen Verlauf auf. Grafana bereitet sie so auf, dass du Ver\u00e4nderungen und Auff\u00e4lligkeiten leichter erkennst. Grafana kann dabei auch andere Datenquellen nutzen; Prometheus ist eine h\u00e4ufig eingesetzte Kombination. Nat\u00fcrlich m\u00f6chte niemand den ganzen Tag auf ein Dashboard schauen. Deshalb lassen sich Alarmregeln<\/strong> einrichten. Sie legen fest, unter welchen Bedingungen eine Benachrichtigung ausgel\u00f6st werden soll \u2013 beispielsweise, wenn der freie Speicherplatz einen bestimmten Wert unterschreitet oder eine Anwendung \u00fcber l\u00e4ngere Zeit ungew\u00f6hnlich langsam antwortet. Daf\u00fcr k\u00f6nnen unter anderem Prometheus-Regeln zusammen mit dem Alertmanager<\/em> oder die Alarmierungsfunktionen von Grafana verwendet werden. Dabei lohnt es sich, die Regeln bewusst zu gestalten. Eine kurze Auslastungsspitze ist nicht unbedingt ein Problem. Bleibt die Belastung dagegen l\u00e4ngere Zeit hoch, kann eine Meldung sinnvoll sein. Ebenso sollte klar sein, welches Werkzeug f\u00fcr welche Benachrichtigung zust\u00e4ndig ist, damit dieselbe St\u00f6rung nicht mehrfach gemeldet wird. F\u00fcr mich ist ein Alarm dann hilfreich, wenn er auf etwas hinweist, bei dem ich tats\u00e4chlich nachsehen oder handeln sollte.<\/p>\n Ich nutze Prometheus zusammen mit Grafana selbst zur \u00dcberwachung meines Homeservers und meiner externen Server. F\u00fcr jedes \u00fcberwachte System habe ich ein eigenes Dashboard eingerichtet. Dort kann ich mir mit einem Blick einen ersten Eindruck verschaffen: Wie stark ist der Server ausgelastet? Ist noch gen\u00fcgend Speicherplatz vorhanden? Gibt es auff\u00e4llige Ver\u00e4nderungen? Das hilft mir, den Zustand der Systeme einzusch\u00e4tzen, ohne mich daf\u00fcr auf jedem Server einzeln anmelden zu m\u00fcssen. Die eingerichteten Alarmregeln informieren mich per E-Mail, wenn etwas nicht ganz rund l\u00e4uft. So muss ich die Dashboards nicht st\u00e4ndig ge\u00f6ffnet haben. Kommt eine Meldung, kann ich mir den zeitlichen Verlauf genauer ansehen und gezielt nach der Ursache suchen.<\/p>\n Praxisbeispiel:<\/strong> Nach der Ver\u00f6ffentlichung einer neuen Version dauert die Anmeldung an einer Webanwendung pl\u00f6tzlich deutlich l\u00e4nger. Wenn die entsprechenden Antwortzeiten erfasst werden, wird die Ver\u00e4nderung im Grafana-Dashboard sichtbar. Ein passend eingerichteter Alarm informiert das Team, sobald die festgelegte Grenze ausreichend lange \u00fcberschritten wird. Anschlie\u00dfend l\u00e4sst sich untersuchen, ob beispielsweise die Serverauslastung ebenfalls gestiegen ist oder eine andere Ursache dahintersteckt. Das Monitoring liefert damit einen wichtigen Hinweis \u2013 die eigentliche Ursachenanalyse folgt danach.<\/p>\n Die Abk\u00fcrzung ELK<\/strong> steht f\u00fcr drei Bestandteile mit unterschiedlichen Aufgaben:<\/p>\n Du kannst dir die Zusammenarbeit also so vorstellen: Logstash bereitet eingehende Protokolldaten auf, Elasticsearch macht sie durchsuchbar, und Kibana gibt dir die passende Oberfl\u00e4che, um damit zu arbeiten. Heute begegnet dir daf\u00fcr h\u00e4ufig die Bezeichnung Elastic Stack<\/strong>, weil inzwischen weitere Komponenten dazugeh\u00f6ren. Ein Beispiel ist Elastic Agent<\/em>, das Daten von Systemen erfassen und weiterleiten kann. Welche Bausteine ben\u00f6tigt werden, h\u00e4ngt vom jeweiligen Aufbau ab. Logstash muss deshalb nicht zwangsl\u00e4ufig in jeder Installation eingesetzt werden.<\/p>\n Besonders hilfreich finde ich das Zusammenspiel mit dem Monitoring: Messwerte zeigen h\u00e4ufig, dass etwas auff\u00e4llig ist; Protokolle liefern weitere Hinweise darauf, was passiert ist. Eine Kurve kann beispielsweise zeigen, dass seit 14 Uhr mehr Anfragen fehlschlagen. In den Logs l\u00e4sst sich anschlie\u00dfend nachsehen, welche Fehlermeldungen in diesem Zeitraum aufgetreten sind und welche Dienste betroffen waren. Die Ursache steht damit nicht automatisch fest, aber die Suche l\u00e4sst sich deutlich gezielter angehen.<\/p>\n Praxisbeispiel:<\/strong> Nach einer Aktualisierung melden mehrere Nutzer, dass sie sich nicht mehr anmelden k\u00f6nnen. Das Monitoring best\u00e4tigt eine erh\u00f6hte Fehlerrate. In Kibana grenzt das Team die Suche auf den Zeitraum seit der Ver\u00f6ffentlichung und den Anmeldedienst ein. Dabei fallen wiederholte Meldungen auf, dass keine Verbindung zur Datenbank hergestellt werden konnte. Das ist ein konkreter Ansatzpunkt: Nun l\u00e4sst sich pr\u00fcfen, ob sich etwa die Verbindungseinstellungen ge\u00e4ndert haben oder die Datenbank nicht erreichbar ist.<\/p>\n Bei der zentralen Protokollierung lohnt sich allerdings etwas Planung. Viele Dienste k\u00f6nnen in kurzer Zeit gro\u00dfe Datenmengen erzeugen. Deshalb sollte das Team festlegen, welche Informationen wirklich gebraucht werden und wie lange sie aufbewahrt werden sollen. Auch sensible Inhalte wie Passw\u00f6rter oder Zugriffsschl\u00fcssel geh\u00f6ren nicht in die Protokolle. Ziel ist eine hilfreiche Grundlage f\u00fcr die Fehlersuche, die \u00fcbersichtlich bleibt und deren Speicherbedarf zum tats\u00e4chlichen Nutzen passt.<\/p>\n Angenommen, ein Team erweitert die Anmeldung einer Webanwendung. Ein m\u00f6glicher Ablauf sieht so aus:<\/p>\n Das ist lediglich eine m\u00f6gliche Kombination von vielen verschiedenen Varianten. Die verwendeten Werkzeuge k\u00f6nnen nat\u00fcrlich auch anders aussehen – entscheidend sind nachvollziehbare \u00dcberg\u00e4nge und verl\u00e4ssliche R\u00fcckmeldungen.<\/p>\n Ich hoffe, ich konnte hier den Nicht-Nerds einen kleinen \u00dcberblick geben, was 2026 im Softwareentwicklungsprozess bzw. als DevOps eingesetzt wird, sofern einem diese Tools\/Frameworks zur Verf\u00fcgung stehen. Nat\u00fcrlich muss man dann immer auch noch abw\u00e4gen, ob man dabei nicht mit Kanonen auf Spatzen schie\u00dft. \ud83d\ude42<\/p>\n Du m\u00f6chtest mehr erfahren? Hier findest du die offiziellen Dokumentationen zum Weiterlesen und Ausprobieren.<\/p>\n Meine Inspiration:<\/strong> Das Video Every Major DevOps Tool Explained in 11 Minutes!<\/a> hat mich zu diesem Beitrag angeregt.<\/p>\n Versionsverwaltung & Zusammenarbeit<\/strong> Automatisierung & CI\/CD<\/strong> Container & Systemkonfiguration<\/strong> Codequalit\u00e4t<\/strong> Monitoring & Protokollauswertung<\/strong>![\"\"](\"https:\/\/www.marcelcuvelier.de\/wp-content\/uploads\/2026\/10\/git.png\")
<\/a>Wer schon einmal Dateien mit Namen wie \u201eProjekt_final\u201c, \u201eProjekt_final_neu\u201c oder \u201eProjekt_final_wirklich_fertig\u201c angelegt hat, kennt das Problem: Man m\u00f6chte verschiedene Arbeitsst\u00e4nde behalten, verliert dabei aber schnell den \u00dcberblick. Welcher Stand ist aktuell? Was wurde ge\u00e4ndert? Und wie komme ich zur\u00fcck zu der Version, in der noch alles funktioniert hat? Genau hier hilft Git. Git ist ein sogenanntes Versionsverwaltungssystem<\/em>. Es h\u00e4lt nachvollziehbar fest, wie sich die Dateien eines Projekts ver\u00e4ndern. Dadurch l\u00e4sst sich sp\u00e4ter nachsehen, welche \u00c4nderungen vorgenommen wurden, von wem sie stammen und welche Erkl\u00e4rung dazu hinterlegt wurde. Bei Bedarf k\u00f6nnen fr\u00fchere St\u00e4nde wiederhergestellt oder einzelne \u00c4nderungen r\u00fcckg\u00e4ngig gemacht werden.<\/p>\nGitHub und GitLab: Zusammenarbeit rund um den Code<\/h2>\n
<\/a>GitHub und GitLab kannst du dir als gemeinsame Arbeitsplattformen f\u00fcr Softwareprojekte vorstellen. Die Grundlage bildet dabei Git, das \u00c4nderungen am Code nachvollziehbar festh\u00e4lt. GitHub und GitLab geben dem Projekt zus\u00e4tzlich einen zentralen Platz, an dem das Team zusammenarbeiten kann. Dort liegt das sogenannte Repository<\/em>: vereinfacht gesagt der Projektordner mit dem Quellcode und seiner \u00c4nderungshistorie.<\/p>\nCI\/CD: \u00c4nderungen automatisch bauen, pr\u00fcfen und bereitstellen<\/h2>\n
GitHub Actions<\/h3>\n
<\/a>Wenn du an einer Anwendung arbeitest, wiederholen sich viele Aufgaben: Nach einer \u00c4nderung m\u00f6chtest du beispielsweise pr\u00fcfen, ob die automatisierten Tests noch erfolgreich durchlaufen und sich die Anwendung weiterhin fehlerfrei erstellen l\u00e4sst. Diese Schritte jedes Mal von Hand anzusto\u00dfen, kostet Zeit \u2013 und im Alltag wird auch schnell einmal etwas vergessen. GitHub Actions hilft dir dabei, solche Abl\u00e4ufe direkt in deinem GitHub-Projekt zu automatisieren. Dazu legst du einen sogenannten Workflow<\/em> an. Den kannst du dir wie einen Arbeitsplan vorstellen: Er beschreibt, wann etwas passieren soll und welche Schritte anschlie\u00dfend ausgef\u00fchrt werden. Ein Ausl\u00f6ser kann beispielsweise sein, dass du neue \u00c4nderungen zu GitHub \u00fcbertr\u00e4gst \u2013 das nennt man Push<\/em>. Auch ein Pull Request, also eine Anfrage zur \u00dcbernahme von \u00c4nderungen, kann einen Workflow starten. Ebenso sind zeitgesteuerte Abl\u00e4ufe m\u00f6glich, etwa ein Testlauf in jeder Nacht.<\/p>\n.github\/workflows\/<\/code>. Auch wenn das zun\u00e4chst technisch klingt: Im Grunde stehen darin strukturierte Anweisungen wie \u201eHole den aktuellen Code, bereite die ben\u00f6tigte Umgebung vor und f\u00fchre anschlie\u00dfend die Tests aus\u201c. Weil die Dateien zum Projekt geh\u00f6ren, werden \u00c4nderungen an diesen Abl\u00e4ufen ebenfalls mit Git dokumentiert.<\/p>\nGitLab CI\/CD<\/h3>\n
<\/a>Was GitHub mit GitHub Actions erm\u00f6glicht, bietet GitLab mit GitLab CI\/CD<\/strong>: Du kannst wiederkehrende Aufgaben rund um deine Anwendung automatisieren und direkt mit deinem Projekt verbinden. Beispielsweise l\u00e4sst sich nach einer Code\u00e4nderung automatisch pr\u00fcfen, ob die Anwendung noch erstellt werden kann und die vorgesehenen Tests erfolgreich durchlaufen. Der gesamte Ablauf wird als Pipeline<\/strong> bezeichnet. Stell sie dir wie eine Reihe von Arbeitsstationen vor: Zuerst wird die Anwendung erstellt, anschlie\u00dfend gepr\u00fcft und danach beispielsweise auf einer Testumgebung bereitgestellt. Jede Station hat eine bestimmte Aufgabe. Schl\u00e4gt eine wichtige Pr\u00fcfung fehl, k\u00f6nnen die nachfolgenden Schritte gestoppt werden. So l\u00e4sst sich verhindern, dass eine als fehlerhaft erkannte Version einfach weitergereicht wird.<\/p>\n.gitlab-ci.yml<\/code> im Hauptverzeichnis deines Projekts. Darin beschreibst du einzelne Aufgaben, sogenannte Jobs<\/em>. Ein Job k\u00f6nnte beispielsweise die automatisierten Tests starten, ein anderer die Anwendung f\u00fcr die Ver\u00f6ffentlichung vorbereiten. Zusammengeh\u00f6rige Jobs lassen sich in Ablaufstufen, sogenannten Stages<\/em>, organisieren \u2013 etwa \u201eErstellen\u201c, \u201eTesten\u201c und \u201eBereitstellen\u201c. Jobs derselben Stufe k\u00f6nnen parallel laufen, sofern gen\u00fcgend Ausf\u00fchrungskapazit\u00e4t vorhanden ist.<\/p>\nJenkins<\/h3>\n
<\/a>Jenkins hilft dabei, wiederkehrende Aufgaben in der Softwareentwicklung automatisch auszuf\u00fchren. Dazu geh\u00f6ren beispielsweise das Erstellen einer Anwendung, das Ausf\u00fchren von Tests oder die Bereitstellung einer neuen Version. Du kannst dir Jenkins wie eine zentrale Arbeitsorganisation vorstellen: Es st\u00f6\u00dft die vorgesehenen Aufgaben an, koordiniert ihre Ausf\u00fchrung und zeigt anschlie\u00dfend, welche Schritte erfolgreich waren und wo Probleme aufgetreten sind. Im Unterschied zu den direkt in GitHub oder GitLab eingebauten Automatisierungsfunktionen ist Jenkins ein eigenst\u00e4ndiger Automatisierungsserver. Damit ist zun\u00e4chst eine Software gemeint, die auf einem geeigneten Rechner oder in einer entsprechenden Serverumgebung betrieben wird. Jenkins l\u00e4sst sich mit verschiedenen Werkzeugen und Projektablagen verbinden. Das ist beispielsweise dann interessant, wenn in einem Unternehmen bereits unterschiedliche Systeme genutzt werden, die in einem gemeinsamen Ablauf zusammenarbeiten sollen.<\/p>\nJenkinsfile<\/code> beschreiben. Darin steht beispielsweise: \u201eHole den aktuellen Programmcode, erstelle die Anwendung, f\u00fchre die Tests aus und stelle die gepr\u00fcfte Version auf dem Testserver bereit.\u201c Das Jenkinsfile kann gemeinsam mit dem Anwendungscode in Git gespeichert werden. Dadurch bleibt nachvollziehbar, wer den Ablauf wann ver\u00e4ndert hat. Auch \u00c4nderungen an der Automatisierung k\u00f6nnen so vom Team gemeinsam gepr\u00fcft werden.<\/p>\nDocker: Anwendungen reproduzierbar verpacken<\/h2>\n
<\/a>\u201eBei mir funktioniert es!\u201c \u2013 dieser Satz beschreibt ein bekanntes Problem in der Softwareentwicklung. Auf dem Rechner des Entwicklers l\u00e4uft eine Anwendung problemlos. Auf dem Testserver fehlt pl\u00f6tzlich eine ben\u00f6tigte Bibliothek oder es ist eine andere Version der Programmiersprache installiert. Der Code ist derselbe, aber die Umgebung unterscheidet sich. Genau hier hilft Docker: Es erm\u00f6glicht, eine Anwendung zusammen mit vielen ihrer ben\u00f6tigten Bestandteile in einem definierten Paket bereitzustellen.<\/p>\nDockerfile<\/code>. Sie ist gewisserma\u00dfen das Rezept: Welche Grundlage verwenden wir? Welche zus\u00e4tzlichen Pakete werden installiert? Wohin wird der Anwendungscode kopiert? Und mit welchem Befehl soll die Anwendung starten? Docker arbeitet diese Anweisungen beim Erstellen des Images ab.<\/p>\nKubernetes: Container \u00fcber mehrere Systeme betreiben<\/h2>\n
<\/a>Mit Docker l\u00e4sst sich eine Anwendung in Containern bereitstellen. Doch was passiert, wenn viele solcher Container betrieben werden sollen \u2013 vielleicht sogar verteilt auf mehrere Server? Wer entscheidet, wo sie laufen? Was passiert bei einem Ausfall? Und wie wird eine neue Version eingespielt, w\u00e4hrend die Anwendung weiterhin genutzt wird? Bei diesen Aufgaben unterst\u00fctzt Kubernetes.<\/p>\nAnsible: Infrastruktur nachvollziehbar verwalten<\/h2>\n
<\/a>Wer schon einmal mehrere Server eingerichtet hat, kennt die wiederkehrenden Aufgaben: Software installieren, Benutzer anlegen, Konfigurationsdateien anpassen und Dienste starten. Auf einem einzelnen System l\u00e4sst sich das noch gut von Hand erledigen. Bei mehreren Rechnern wird es schnell aufwendig. Au\u00dferdem kann es passieren, dass eine Einstellung vergessen oder auf einem Server etwas anders umgesetzt wird. Ansible hilft dabei, solche administrativen Aufgaben nachvollziehbar zu automatisieren. Daf\u00fcr beschreibst du die erforderlichen Schritte in einem sogenannten Playbook<\/strong>. Du kannst dir das wie eine Arbeitsanweisung vorstellen, die Ansible f\u00fcr dich abarbeitet. Darin steht beispielsweise: \u201eInstalliere den Webserver, \u00fcbertrage diese Konfigurationsdatei und stelle sicher, dass der Dienst l\u00e4uft.\u201c Die Playbooks werden im Textformat YAML<\/em> geschrieben. Dadurch lassen sie sich auch mit Git verwalten, gemeinsam pr\u00fcfen und bei Bedarf anpassen.<\/p>\nSonarQube: Codequalit\u00e4t fr\u00fchzeitig pr\u00fcfen<\/h2>\n
<\/a>Eine Anwendung kann auf den ersten Blick funktionieren und trotzdem problematische Stellen im Programmcode enthalten. Vielleicht wurde ein m\u00f6glicher Fehlerfall \u00fcbersehen, eine Funktion ist unn\u00f6tig kompliziert geworden oder dieselbe Logik wurde an mehreren Stellen kopiert. Solche Dinge fallen beim Ausprobieren nicht unbedingt auf, k\u00f6nnen sp\u00e4tere \u00c4nderungen aber erschweren. SonarQube hilft dabei, den Quellcode automatisiert auf solche Auff\u00e4lligkeiten zu untersuchen. Dabei kommt unter anderem die sogenannte statische Codeanalyse<\/strong> zum Einsatz. \u201eStatisch\u201c bedeutet hier, dass der Code untersucht wird, ohne die Anwendung daf\u00fcr wie ein Nutzer auszuf\u00fchren. SonarQube pr\u00fcft ihn anhand von Regeln und sucht nach auff\u00e4lligen Mustern. Du kannst dir das ein wenig wie eine Rechtschreib- und Stilpr\u00fcfung f\u00fcr Programmcode vorstellen: Sie liefert Hinweise auf m\u00f6gliche Probleme und erkl\u00e4rt, warum eine Stelle genauer betrachtet werden sollte.<\/p>\nPrometheus und Grafana: Messwerte sammeln und sichtbar machen<\/h2>\n
<\/a>Eine Anwendung ist ver\u00f6ffentlicht und der Server l\u00e4uft \u2013 aber l\u00e4uft auch alles so, wie es soll? Werden Anfragen z\u00fcgig beantwortet? Reicht der verf\u00fcgbare Arbeitsspeicher aus? Und nimmt die Auslastung vielleicht schon seit Tagen zu, ohne dass es bisher jemand bemerkt hat? Prometheus und Grafana helfen dabei, solche Entwicklungen sichtbar zu machen. Die beiden Werkzeuge werden h\u00e4ufig gemeinsam eingesetzt, \u00fcbernehmen aber unterschiedliche Aufgaben. Prometheus sammelt und speichert Messwerte. Dazu geh\u00f6ren beispielsweise die CPU-Auslastung, der belegte Arbeitsspeicher oder die Anzahl der Anfragen an eine Anwendung. Jeder Messwert wird zusammen mit einem Zeitpunkt gespeichert. So entstehen sogenannte Zeitreihen<\/em>. Du siehst dadurch nicht nur, wie stark ein Server gerade besch\u00e4ftigt ist, sondern kannst auch nachvollziehen, wie sich seine Auslastung \u00fcber Minuten, Stunden oder Tage ver\u00e4ndert hat.<\/p>\n<\/a>Grafana <\/strong>macht diese Informationen anschaulich. Es greift auf angebundene Datenquellen wie Prometheus zu und stellt deren Daten in sogenannten Dashboards<\/em> dar. Das sind \u00dcbersichtsseiten mit Diagrammen, Kennzahlen und Statusanzeigen. Statt lange Zahlenlisten durchzugehen, kannst du beispielsweise anhand einer Kurve erkennen, wann die CPU-Auslastung gestiegen ist oder ob der freie Speicherplatz langsam knapp wird. <\/p>\nELK-Stack: Protokolle zentral durchsuchen<\/h2>\n
<\/a>Ein Dashboard zeigt dir, dass die Fehlerrate einer Anwendung gestiegen ist. Aber was ist genau passiert? Welche Anfrage ist fehlgeschlagen, und welche Fehlermeldung wurde dabei ausgegeben? F\u00fcr solche Fragen lohnt sich ein Blick in die Protokolle, auch Logs<\/em> genannt. Darin halten Anwendungen und Systeme Ereignisse fest \u2013 beispielsweise einen fehlgeschlagenen Verbindungsaufbau oder einen Fehler beim Verarbeiten einer Bestellung. Auf einem einzelnen Server lassen sich solche Protokolle noch recht gut direkt durchsuchen. Wenn eine Anwendung aber aus mehreren Diensten besteht, die auf unterschiedlichen Rechnern laufen, wird das schnell un\u00fcbersichtlich. Der ELK-Stack hilft dabei, diese Informationen zentral zusammenzuf\u00fchren und durchsuchbar zu machen. \u201eStack\u201c bezeichnet hier eine Kombination von Werkzeugen, die zusammenarbeiten.<\/p>\n\n
Die genannten DevOps-Tools im \u00dcberblick<\/h2>\n
\n
\n \nWerkzeug<\/th>\n Schwerpunkt<\/th>\n Typischer Einsatz<\/th>\n<\/tr>\n<\/thead>\n \n Git<\/td>\n Versionsverwaltung<\/td>\n \u00c4nderungen dokumentieren und zusammenf\u00fchren<\/td>\n<\/tr>\n \n GitHub \/ GitLab<\/td>\n Codehosting und Zusammenarbeit<\/td>\n Repositories, Reviews und Aufgaben verwalten<\/td>\n<\/tr>\n \n GitHub Actions \/ GitLab CI\/CD<\/td>\n Integrierte Automatisierung<\/td>\n Builds, Tests und Deployments ausf\u00fchren<\/td>\n<\/tr>\n \n Jenkins<\/td>\n CI\/CD<\/td>\n Automatisierte Pipelines organisieren<\/td>\n<\/tr>\n \n Docker<\/td>\n Containerisierung<\/td>\n Images bauen und Container ausf\u00fchren<\/td>\n<\/tr>\n \n Kubernetes<\/td>\n Containerverwaltung<\/td>\n Anwendungen im Cluster betreiben<\/td>\n<\/tr>\n \n Ansible<\/td>\n Konfigurationsautomatisierung<\/td>\n Systeme wiederholbar konfigurieren<\/td>\n<\/tr>\n \n SonarQube<\/td>\n Statische Codeanalyse<\/td>\n Codequalit\u00e4t pr\u00fcfen und Quality Gates auswerten<\/td>\n<\/tr>\n \n Prometheus<\/td>\n Metriken und Alarmregeln<\/td>\n Messwerte erfassen und auswerten<\/td>\n<\/tr>\n \n Grafana<\/td>\n Visualisierung und Alerting<\/td>\n Dashboards und Benachrichtigungen erstellen<\/td>\n<\/tr>\n \n Elastic Stack \/ ELK<\/td>\n Datensuche und Logauswertung<\/td>\n Protokolle zentral analysieren<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Praxisbeispiel: Von der Code\u00e4nderung bis zum Betrieb<\/h2>\n
\n
Quellen & weiterf\u00fchrende Links<\/h2>\n
\nGit-Handbuch<\/a> \u00b7 GitHub<\/a><\/p>\n
\nGitHub Actions<\/a> \u00b7 GitLab CI\/CD<\/a> \u00b7 Jenkins<\/a><\/p>\n
\nDocker<\/a> \u00b7 Kubernetes<\/a> \u00b7 Ansible<\/a><\/p>\n
\nSonarQube: Quality Gates<\/a><\/p>\n
\nPrometheus<\/a> \u00b7 Grafana<\/a> \u00b7 Elastic Stack<\/a><\/p>\n<\/div>\n