Über die Modernisierung Ihrer aktuellen Build-Pipelines

Die dynamischen Geschäftsumgebungen von heute benötigen ausgereifte Testprozesse und -praktiken, die eher den Erfolg garantieren als nur Kosten zu senken. Während das Testen traditionell als kurative Lösung angesehen wurde, ist es in Wirklichkeit eine präventive Maßnahme, die die Produktfähigkeiten verbessern und dazu beitragen kann, Geschäftsziele zu erreichen.

Heute werden fast 40 % des Budgets eines typischen Softwareprojekts für Tests aufgewendet. Obwohl die Vorteile unabhängiger Tests inzwischen allgemein anerkannt sind, stehen Unternehmen immer noch vor Herausforderungen bei der Durchführung von Softwaretests, um ein qualitativ hochwertiges Produkt zu liefern.

Welche Eigenschaften machen eine Pipeline nützlicher als die vorherige?

Geschwindigkeit und Synchronisierung

Prozessgeschwindigkeit: Alle Prozesse sind blitzschnell, und ein schneller und umfassender Feedback-Zyklus hilft Ihnen, schneller auf mögliche Anomalien zu reagieren. Versuchen Sie, eine angemessene Geschwindigkeit und Synchronisierung über alle Ihre Entwicklungs-, Test- und Bereitstellungsprozesse hinweg aufrechtzuerhalten, um die dramatische Veränderung in Ihren Build-Pipelines zu spüren und zu sehen. 

Zuverlässigkeit

Sie können darauf vertrauen, dass die Entwicklungs- und kontinuierlichen Testprozesse sicherstellen, dass sie mit Ihrer Bereitstellungsqualität und Ihren Zeitplänen übereinstimmen. Integrieren Sie strenge Qualitätskontrollen in Ihre Test- und Bereitstellungsprozesse. Dies stellt sicher, dass Ihre Builds zuverlässig sind und eine kontinuierliche Praxis des Erstellens zuverlässiger Versionen des Produkts in Teams und Funktionen verankert wird. 

Wartungsfreundlichkeit

Sie ist wartungsfreundlich. Eine Pipeline sollte ohne großen Aufwand gewartet werden können. Wenn eine Pipeline nicht wartungsfreundlich ist, wird es viele Iterationen des Produkts geben, und es wird für Unternehmen wirtschaftlich nicht tragbar sein, so viele aufeinanderfolgende Verzögerungen und Wiederholungen der Arbeit zu erleiden. Daher sollten Sie die Wartungsfreundlichkeit in Ihren aktuellen Build-Pipelines sicherstellen. 

So transparent wie möglich 

Halten Sie die Zyklen so transparent, dass Abhängigkeiten superleicht zu verstehen sind und Prozesse und Aufgaben entsprechend geplant werden können. Wenn der Prozess nicht transparent ist, kann es schwierig sein, Engpässe zu erkennen und Fehler zu reduzieren. 

Praktiken, die Sie übernehmen können

Verankern Sie Continuous Delivery in Ihrem Denkprozess

Continuous Delivery ist ein sich ständig weiterentwickelnder Prozess, aber auch eine Denkweise. In einer CD-Umgebung sind Anwendungs-Builds immer bereit für die Bereitstellung, was bedeutet, dass DevOps-Teams Folgendes tun sollten:

• Automatisierte Tests für den Build einrichten. 
• Denselben Build der Anwendung über die gesamte Pipeline hinweg verwenden. 
• Probleme im Code gründlich beheben. 
• Einen Build aufgeben, der Probleme hat und als nicht wertvoll erachtet wird.
• Den Code einchecken, die Pipeline arbeiten lassen und den neuen Build durch die Pipeline bewegen.

Verankern Sie eine strikte Continuous Integration in Ihren Prozessen 

Sobald Continuous Integration (CI) eingerichtet ist, erweitert Continuous Delivery (CD) einfach den Integrationsprozess auf die eigentliche Freigabe. Wenn Ihre CD-Pipeline so läuft, wie sie sollte, sind Softwareprodukte nicht an Entwicklungszeitpläne oder Abhängigkeiten gebunden; stattdessen werden sie basierend auf der Nachfrage der Verbraucher und dem Zustand des Marktes geliefert.

Sie können Continuous Integration ohne Continuous Delivery praktizieren, aber Sie können Continuous Delivery nicht ohne Continuous Integration praktizieren. CI beinhaltet das Zusammenführen von Softwarecode in einen automatisierten Build-Prozess und das Ausführen automatisierter Tests, wenn aktualisierter Code zum Quellcode-Repository hinzugefügt wird.

Schaffen Sie einen Halt zwischen Entwicklung und Integration 

Irgendwo zwischen UAT, Staging oder Pre-Production sollten Sie einen Stopp für Ihre Prozesse einlegen, um zurückzublicken. 

Um an den Punkt zu gelangen, an dem sich alle wohlfühlen (und Releases so routinemäßig sind, dass sie betäubend langweilig sind), benötigt die Pipeline mindestens einen Stopp zwischen Entwicklung und Produktion. Sie benötigen mindestens eine vollständig berührungslose Umgebung, um zu validieren, dass das Release produktionsbereit ist und alle im Release enthaltenen Skripte und Mechanismen die Umgebung wie geplant erstellen und die Anwendung wie geplant bereitstellen, jedes Mal.

Führen Sie einheitliche Bereitstellungen über alle Prozesse hinweg durch 

Das Kernkonzept hinter Continuous Delivery ist, dass das gesamte Release-Paket – vom Anwendungs-Build bis zu den Skripten, die die Umgebung erstellen und konfigurieren, in der es ausgeführt wird – solide und bereit für die Produktion ist. Die Produktion sollte einfach eine weitere Umgebung sein, um dieselbe Automatisierung mit denselben Schritten auszuführen.

Machen Sie es einfach, Ihre gesamte Pipeline neu zu starten

Der wahre Wert einer gut funktionierenden Continuous-Delivery-Pipeline liegt darin, wie einfach es ist, von vorne zu beginnen.

Jeder in der Entwicklung oder im Betrieb erinnert sich daran, wie er früher Einstellungen in einer Umgebung angepasst hat, indem er einen oder zwei manuelle Schritte hinzugefügt hat. Diese ganze manuelle Ineffizienz entfällt mit einer Pipeline, die eine unveränderliche Infrastruktur wie Docker-Container verwendet.

Wenn es nicht funktioniert hat, halten Sie an und finden Sie heraus, warum. Beheben Sie es am Anfang und lassen Sie dann die Automatisierung übernehmen und Sie zurück zu dem Punkt bringen, an dem Sie pausiert haben.

Versuchen Sie, jeden möglichen Prozess zu automatisieren 

Wir sehen es öfter, als uns lieb ist: Ein oder zwei Schritte sind immer noch manuell und müssen vor/während/nach der Bereitstellung eines Releases durchgeführt werden, damit alles funktioniert. Sie merken vielleicht nicht, dass es manuell ist, aber das häufigste verräterische Zeichen ist, dass die Pipeline nur dann wie erwartet zu funktionieren scheint, wenn bestimmte Mitarbeiter beteiligt sind. Das ist keine böse Absicht – es ist einfach die menschliche Natur! Wenn etwas Routine ist, denken Sie vielleicht nicht einmal darüber nach. Es ist ihnen vielleicht nicht einmal in den Sinn gekommen, diesen Schritt im richtigen Skript zu automatisieren.

Verwenden Sie unbedingt eine Versionskontrolle für alles 

Verwenden Sie ein Versionskontrollsystem (wie GitHub, SVN oder Team Foundation) für jedes Skript, jede Datenbankänderung und jede Konfigurationsdatei, die Teil des Release-Pakets ist. Binärdateien können und sollten in einem Paket-Repository wie Nexus, Artifactory oder Archiva gespeichert werden. (Andernfalls verursachen sie nur Ärger, wenn sich Binärdateien in einem Code-Versionskontrollsystem befinden.)

Beziehen Sie die Datenbank immer in die Pipeline ein

Um eine wirklich automatisierte und wiederholbare Anwendungsbereitstellung zu haben, sollten Sie alle Änderungen an der Datenbank als Teil von Releases einbeziehen. Dies kann als Teil der Anwendung selbst oder mithilfe eines Drittanbieter-Tools wie FlyWay oder Liquibase erfolgen.

Behalten Sie ein Auge und überwachen Sie 

Egal wie gut Ihr Code getestet ist, ein fehlerhafter Algorithmus, Abhängigkeiten von Diensten und Systemressourcen oder das Versäumnis, unvorhergesehene Bedingungen zu berücksichtigen, können dazu führen, dass sich die Software unvorhersehbar verhält.

Schlusswort

Das Einführen dieser Prozesse in Ihren Entwicklungs- und Bereitstellungslebenszyklus kann Ihnen helfen, qualitativ hochwertigere Produkte zu liefern und Ihre Ressourcenzeitpläne zu erweitern. Es wird Ihre Gesamtproduktivität während des gesamten Softwareentwicklungslebenszyklus verbessern.