Wie man 100 Mal am Tag in die Produktionsumgebung deployed (CI / CD)

Der Erfolg eines Softwareunternehmens hängt von seiner Fähigkeit ab, in kurzer Zeit neue Features bereitzustellen, Fehler zu beheben und Code und Infrastruktur zu verbessern.

Eine kurze Feedbackschleife ist unerlässlich, da sie eine konstante und schnelle Iteration ermöglicht. Dies setzt voraus, dass sich die Codebasis stets in einem einsatzfähigen Zustand befindet, damit neue Funktionen schnell in die Produktion überführt werden können.

Dies zu erreichen, kann schwierig sein, da es viele funktionierende Teile gibt und es bei Auslieferung von Codeänderungen leicht passieren kann, dass neue Bugs eingeführt werden.

Kleine Änderungen scheinen sich kurzfristig nicht auf den Zustand der Software auszuwirken, können langfristig gesehen aber einen großen Effekt haben.

Wenn kleine Softwareunternehmen erfolgreich sein wollen, müssen sie schnell handeln. Wenn sie wachsen, werden sie langsam, und dann wird es knifflig.

Jetzt,

• müssen sie ihre Arbeit besser koordinieren und
• mehr kommunizieren.
• arbeiten mehr Personen an der gleichen Codebasis. Das macht es schwieriger, den Überblick über alles zu behalten, was gerade passiert.

Deshalb ist es wichtig, dass es ein Team gibt, welches sich um den Release von Codeänderungen kümmert. Dieses Team sollte so klein und effizient wie möglich sein, damit es schnell auf Codeänderungen reagieren kann.

Verwende außerdem Feature Flags, um neue Funktionen in der Produktion ein- und auszuschalten. Dies ermöglicht ein schnelles und einfaches Experimentieren und die Möglichkeit, Änderungen bei Bedarf wieder rückgängig zu machen. Richte Alerts ein, um das Team zu benachrichtigen, wenn du neuen Code einführst. Auf diese Weise kann es die Auswirkungen der Änderungen überwachen und bei Bedarf Maßnahmen ergreifen.

Kontinuierliches deployment kleiner Änderungen

Diese Erkenntnis ist zwar nicht neu, aber sie ist ein Kernelement der DevSecOps-Bewegung. Eine weitere Möglichkeit, Risiken zu verringern, besteht darin, den Workflow der Entwickler für eine schnelle Bereitstellung zu optimieren. Dies kannst du erreichen, indem du die Anzahl der Mitarbeiter in der Entwicklungsabteilung erhöhst. Dadurch steigt nicht nur die Zahl der Deployments, sondern auch die Zahl der Deployments pro Entwickler.

Noch bemerkenswerter ist jedoch, dass dadurch die Zahl der Incidents gesunken ist. Während die durchschnittliche Anzahl von Rollbacks gleich geblieben ist.

Doch mit solchen Kennzahlen sollte man vorsichtig sein. Auf dem Papier sind sie großartig. Aber es gibt keine 100%ige Korrelation zwischen Kundenzufriedenheit und negativen Auswirkungen auf die Kunden.

Dein Ziel sollte es sein, viele kleine Verbesserungen einzuführen. Sie sind schneller zu implementieren, schneller zu validieren und natürlich auch schneller wieder rückgängig zu machen.

Außerdem haben kleine Änderungen in der Regel nur geringe Auswirkungen auf dein System im Vergleich zu großen Änderungen.

Generell muss der Prozess von der Entwicklung bis zur Bereitstellung so reibungslos wie möglich sein. Jede Reibung wird dazu führen, dass die Entwickler die Änderungen ausufern lassen und sie alle auf einmal veröffentlichen.

Um die Reibung innerhalb deines Prozesses zu verringern, tue Folgendes:

• Erlaube den Entwicklern, eine Änderung zu implementieren, ohne sie einem Manager zu kommunizieren.
• Automatisiere die Tests und die Bereitstellung in jeder Phase.
• Erlaube es verschiedenen Entwicklern, gleichzeitig und mehrfach zu testen.
• Biete zahlreiche Entwicklungs- und Testsysteme an.

Konzentriere dich neben einem reibungslosen Entwicklungs- und Bereitstellungsprozess auf eine ausgefeilte, aufgeschlossene und tadellose Entwicklungskultur. Nur dann kannst du 100 Mal am Tag (oder noch öfter) in die Produktion deployen.

Unsere Entwicklungs- (und Unternehmens-) Kultur

Wir haben bei XALT ein bestimmtes Bild vor Augen, wenn wir über unsere Entwicklungskultur sprechen.

Für uns ist eine moderne Entwicklungskultur

• eine, die auf Vertrauen basiert.
• die den Kunden in den Mittelpunkt stellt,
• Daten als Entscheidungsgrundlage nutzt,
• sich auf das Lernen konzentriert,
• ergebnis- und teamorientiert ist und
• eine Kultur der kontinuierlichen Verbesserung fördert.

Diese Art von Entwicklungskultur ermöglicht es unserem Entwicklungsteam, schnell zu arbeiten, hochwertigen Code zu liefern und aus Fehlern zu lernen.

Dieser Ansatz geht Hand in Hand mit unserer gesamten Unternehmenskultur. Unabhängig von der Abteilung, dem Team oder der Position. Wir neigen auch dazu, den Status quo in Frage zu stellen.

Ich weiß, das klingt ein bisschen abgedroschen. Aber es ist wahr. Dadurch, dass sich unser Team ohne unnötige Reibungsverluste oder Vorschriften auf das eigentliche Problem konzentrieren kann, sind wir produktiver und schneller.

Unser Entwicklungs-, Test- und Bereitstellungsprozess sieht zum Beispiel folgendermaßen aus.

Er ist ziemlich einfach. Wenn einer unserer Entwickler einen neuen Code-Branch erstellt und getestet hat, muss nur noch eine weitere Person den Code überprüfen, und schon wird er in die Produktionsumgebung integriert.

Aber das wichtigste Kernelement bei XALT ist Vertrauen! Lass mich das genauer erklären.

Wir vertrauen unserem Team

Es ist uns egal, wie du es machst oder welche Tools du benutzt, um einen Task umzusetzen. Wir vertrauen darauf, dass du weißt, was du tust. Wenn etwas schief geht oder etwas nicht funktioniert, ist das nicht schlimm. Wir gehen der Sache auf den Grund, finden die Ursache des Fehlers, beheben ihn und lernen aus unseren Fehlern.

Ich weiß, es geht nicht nur um die Entwicklung, auch das Testen und andere Teile sind genauso wichtig.

Monitoring und Testen

Um besser und schneller zu werden und letztendlich unsere Nutzer (oder Kunden) glücklich zu machen, überwachen und prüfen wir ständig unsere Entwicklungsprozesse.

Im Falle eines Incidents geht es nicht nur darum, das System wieder zum Laufen zu bringen. Sondern auch, um sicherzustellen, dass so etwas nicht noch einmal passiert.

Deshalb haben wir viel in Monitoring und Auditing investiert.

So können wir

• Echtzeit-Einblicke in die Vorgänge zu erhalten,
• Probleme und mögliche Verbesserungen zu erkennen,
• bei Bedarf Korrekturmaßnahmen zu ergreifen und
• uns schneller von Incidents erholen.

Außerdem haben wir eine automatische Backup-Lösung (täglich) für unsere Kernanwendungen und unsere Infrastruktur eingeführt. Wenn also etwas kaputt geht, können wir auf eine frühere Version zurückgreifen und so das Risiko weiter verringern.

Risikominimierung in einer DevOps-Kultur

Um das Risiko im Entwicklungsalltag zu mindern, wenden wir die folgenden Taktiken an:

• Trunk-basierte Entwicklung: Das ist ein sehr einfaches Verzweigungsmodell, bei dem alle Entwickler am Hauptentwicklungszweig oder Trunk arbeiten. Dies ist der Standardzweig in Git. Alle Entwickler übertragen ihre Änderungen in diesen Zweig und pushen ihre Änderungen regelmäßig. Der Hauptvorteil dieses Verzweigungsmodells ist, dass es das Risiko von Merge-Konflikten verringert, weil es nur einen Hauptentwicklungszweig gibt.
• Pull Requests: Mit einer Pull-Anfrage bittest du eine andere Person, deinen Code zu überprüfen und in ihren Zweig einzubinden. Dies wird in der Regel verwendet, wenn du zu einem anderen Projekt beitragen möchtest oder wenn du möchtest, dass jemand anderes deinen Code überprüft.
• Code-Review: Bei der Codeüberprüfung wird der Code manuell auf Fehler überprüft. Dies wird normalerweise von einem Kollegen oder Vorgesetzten durchgeführt. Führe Code-Reviews mit Hilfe von Tools durch, die diesen Prozess automatisieren.
• Continuous Integration (CI): Hierbei handelt es sich um den Prozess der automatischen Erstellung und Prüfung von Codeänderungen. Dies geschieht in der Regel mit einem CI-Server wie Jenkins. CI hilft dabei, Fehler frühzeitig zu finden und zu verhindern, dass sie in die Hauptcodebasis einfließen.
• Continuous Deployment (CD): Hierbei handelt es sich um den Prozess der automatisierten Bereitstellung von Codeänderungen in einer Produktionsumgebung.

Außerdem ist es wichtig, dass wir klare Leitlinien festlegen, an denen sich unser Entwicklungsteam orientieren kann.

Die Leitlinien bei XALT:

• Mindestens ein weiterer Entwickler überprüft alle Codeänderungen, bevor wir sie in die Hauptcodebasis einfügen.
• Um Codeänderungen zu erstellen und zu testen, bevor wir sie in die Hauptcodebasis einbringen, haben wir einen Continuous Integration Server eingerichtet.
• Verwendung von Tools wie Code SonarQube, um die Codequalität sicherzustellen und Feedback zu möglichen Verbesserungen zu geben.
• Implementierung einer umfassenden automatisierten Testsuite, um Fehler zu finden, bevor sie in die Produktion gelangen.

Zusammenfassung

Der Erfolg eines Softwareunternehmens hängt von seiner Fähigkeit ab, regelmäßig neue Funktionen bereitzustellen, Fehler zu beheben sowie Code und Infrastruktur zu verbessern. Das kann schwierig sein, denn es gibt zahlreiche Komponenten, an denen gearbeitet wird, und beim Release von Codeänderungen kann es leicht zu neuen Fehlern kommen. Es gibt ein paar Dinge, die diesen Prozess erleichtern können: Automatisiere den Prozess so weit wie möglich, stelle ein eigenes Team zusammen, das für den Release von Codeänderungen zuständig ist, verwende Feature Flags, um neue Funktionen in der Produktion ein- und auszuschalten, und richte Alerts ein, um das Team zu benachrichtigen, wenn neuer Code bereitgestellt wird.

Wenn du diese Tipps befolgst, solltest du in der Lage sein, 100 Mal am Tag in die Produktion zu gehen und dabei nur minimale Unterbrechungen zu verursachen.