Die Deployment Pipeline in der Praxis
Die verschiedenen Schritte einer Deployment Pipeline werden angestoßen, sobald ein Entwickler Code in ein Software Repository des Versionskontrollsystems eincheckt. Anschließend startet der Build Automation Server als Kontrollzentrum eine Abfolge von Schritten. Der Code durchläuft hierbei diverse Phasen - darunter auch Tests die meist automatisiert ausgefüht werden. Er stoppt diesen Prozess jedoch sofort bei einem Fehler. Nur wenn ein Build alle Prüfungen erfolgreich besteht, besitzt er die nötige Qualität für den produktiven Einsatz.
Foto: Dynatrace
Schritt 1: Eingabe
Der Build Automation Server verschiebt die neue Version im ersten Schritt aus dem Software Repository in ein temporäres Verzeichnis, kompiliert den Code und führt erste umgebungsunabhängige Unit-Tests durch. Anschließend werden Release-Artefakte wie Installer Packages assembliert und eine Dokumentation erzeugt.
Schritt 2: Akzeptanztests
Zur Vorbereitung auf die Akzeptanztests werden Deployment-Automatisierungsskripts ausgeführt, die eine produktionsähnliche oder -identische Umgebung erzeugen. Nach Installation der Release-Artefakte prüfen Smoke-Tests, ob die Applikation und damit verbundene Services laufen. Schließlich verifizieren automatische Akzeptanztests, dass die Applikation Business-Niveau entspricht.
Foto: Dynatrace
Schritt 3: Kapazitätstests
Automatische Kapazitätstests zeigen, ob das System ein definiertes Service-Niveau unter produktionsähnlichen Lastbedingungen erreichen kann. Zudem werden nicht-funktionale Anforderungen untersucht, meist in Bezug auf Antwortzeit und Durchsatz.
Schritt 4: Nutzerakzeptanztests
Anwender führen dann manuelle Nutzerakzeptanztests durch, um die einzelnen Funktionen zu beurteilen.
Schritt 5: Release Stage
Nach dem erfolgreichen Bestehen dieser vier Schritte wird der Build in einem binären Repository bereitgestellt. Sobald die Fachabteilung ihn freigibt, geht er in den produktiven Einsatz. Bei Continuous Delivery ist - im Gegensatz zu Continuous Deployment - der Release eines Builds in die Produktion immer noch ein halbautomatischer Prozess, der zwei Dinge erfordert: die Auswahl eines Builds auf einer Liste und das Drücken des Freigabeknopfes.
Continuous Delivery Deployment
Derzeit tendieren immer mehr Unternehmen dazu, auch diesen letzten manuellen Freigabeschritt zu automatisieren. Dann spricht man von Continuous Deployment.
Deployment-Automatisierung bildet eine wichtige Basis für die automatische Bereitstellung produktionsähnlicher Umgebungen. Das Konzept ist analog zu Lean Manufacturing: Bei Erkennung eines Fehlers wird die Produktionslinie sofort angehalten und das Problem mit der größten Aufmerksamkeit gelöst. Nach der Korrektur wird die Wahrscheinlichkeit minimiert, dass sich dieser Fehler wiederholt. Dieses Prinzip des Continuous Improvement ist auch bei der agilen Softwareentwicklung wichtig.
Infrastruktur als Code
Nach der Freigabe werden für die Produktionsumgebung die gleichen Deployment-Automatisierungsskripts ausgeführt wie in der produktionsähnlichen Test-Umgebung. Aufgrund der engen Beziehung zwischen Applikation und Infrastruktur sollte dabei der Quellcode der Anwendung gemeinsam mit den Umgebungsspezifikationen gewartet und in einem einheitlichen Repository verwaltet werden. Die Behandlung der Infrastruktur als Code erfordert sicher eine gewisse Umgewöhnung, doch sie bietet eine große Chance: die Etablierung einer Kultur der Veränderung sowie der engen Zusammenarbeit zwischen Development- und Operations-Teams gemäß der DevOps-Methodik.
- Software-Entwicklung in Europa
Eine Umfrage zum Status quo in der Software-Entwicklung weist auf deutliche Unterschiede zwischen europäischen Regionen hin. Übereinstimmung herrscht indes darin, dass Individualentwicklung wichtig bleibt, Cloud-Enabling auch für Legacy-Anwendungen Pflicht wird und Entwickler zu stark von Nebensächlichkeiten abgelenkt werden. - IT-Chefs in Ländern ...
... der Regionen Benelux und DACH möchten durch gezielten IT-Einsatz vor allem die Kosten senken. Die Briten sehen darin eher ein Instrument zur Umsatzsteigerung. Und die Skandinavier wollen ihre Kunden besser bedienen. - In allen Regionen ...
... sollen sowohl bestehende Anwendungen "cloudifiziert" als auch neue Anwendungen native für die Cloud entwickelt werden. - Dramatische Unterschiede gibt es in Sachen Self-Service:
Nur in der DACH-Region haben Entwickler mehrheitlich keinen Self-Service-Zugriff auf IT-Infrastruktur. - Gefragt nach den strategischen IT-Initiativen, ...
... legen Skandinavien, die DACH-Region und die Benelux-Staaten größten Wert auf standardisierte Deployment-Architekturen und –Prozesse. Den Briten ist das nicht so wichtig. Ihnen geht es vorrangig um mehr Produktivität in der Software-Entwicklung. - Deutliche Unterschiede in der Akzeptanz von Cloud Computing:
Für ein Drittel der befragten Briten ist die Cloud "kritisch" für strategische IT-Initiativen. In allen anderen Regionen ist die Sogwirkung nicht so stark. - Jenseits der DACH-Region spielt die Public Cloud eine deutlich wichtigere Rolle.
In der deutschsprachigen Region ist die Hybrid Cloud besonders populär. - Offenbar sind die Deutschen, Österreicher und Schweizer ...
... besonders effizient, wenn es um die Auslastung ihrer Data Centers geht. - Die Briten und die Benelux-Länder haben noch reichlich Legacy-Systeme im Einsatz.
In Ländern aus Skandinavien und der DACH-Region wurde schon kräftig ausgemistet.
Kontinuierliche Performance-Validierung
Obwohl die meisten Unternehmen heute wissen, wie wichtig eine hohe Performance ihrer Website oder Anwendung ist, erstaunt es, wie lange die Nutzer trotzdem meist auf eine angeforderte Seite oder das Öffnen der App warten müssen. Dabei sind die häufigsten Problemmuster bereits seit langem bekannt, diese reichen vom Front-End bis zur Server-Seite. Zudem ist bekannt, dass es umso teurer und aufwädiger ist, einen Fehler zu beseitigen, je weiter zurück er in der Entwicklung oder im Lebenszyklus des Produkts liegt. Daher sollten sie so früh wie möglich entdeckt und behoben werden, damit sie keinesfalls in die Produktivphase mitgeschleppt werden.
Einer der Gründe ist das Fehlen geeigneter Testverfahren vor der Produktivphase. Dies liegt meist an den engen Deadlines. So muss eine neue Website oder Anwendung häufig bis zu einem bestimmten Datum fertiggestellt werden. Gerät das Projekt in Verzug, wird häufig an den notwendigen Tests gespart, da die Seite auf jeden Fall online geschaltet oder die Anwendung bereitgestellt werden muss. So werden nur die Fehler notdürftig behoben, die den Entwicklern selbst oder ersten internen Testanwendern aufgefallen sind. Dabei ist jedoch häufig zu beachten, dass die Geschwindigkeit nur auf internen Servern im Unternehmensnetzwerk getestet wird und nicht über eine externe Verbindung von zu Hause oder unterwegs. Die Unterschiede in der Customer Experience sind hier aber meist sehr groß. (bw)