Die Bereitstellung ist der neue Build (Teil 1)

Anfang dieses Jahres wurde ich eingeladen, auf den Devopsdays Boston einen Vortrag über die Bereitstellung als neues Buildzu halten : wie Bereitstellungen heute durchgeführt werden, wie sie sich in einer stärker virtualisierten, bedarfsorientierten Anwendungslandschaft anpassen müssen und welche grundlegenden Verbesserungen notwendig sind, bevor die Bereitstellung zu der unsichtbaren, einfach funktionierenden™ Erfahrung reift , die Build heute ist. In diesem ersten Beitrag werden wir uns auf einige der Veränderungen und Trends in der Branche konzentrieren, die dazu geführt haben, dass der Bereich der Freigabe, Bereitstellung und Verwaltung von Anwendungen bei den Unternehmen so viel Aufmerksamkeit erhält.

Da sich Unternehmen darauf konzentrieren, ihre IT-Umgebung auf die schnelle Bereitstellung von Geschäftswerten abzustimmen, befassen sich immer mehr Projekte und Initiativen in Unternehmen mit der gesamten Wertschöpfungskette der Softwareproduktion. Ob unter dem Banner von Devops, über integrierte Projektteams oder im Rahmen der Einführung neuer Entwicklungsmethoden wie ^Agile1 oder Infrastrukturtechnologien wie ^Cloud2, das Bewusstsein für den Bedarf an automatisierten, zuverlässigen und flexiblen Bereitstellungsverfahren wächst. Es ist zwar klar, dass die Generierung von Kundenfunktionen in den Entwicklungs-, Test- und QA-Teams stattfindet, aber der mit diesen Funktionen verbundene Geschäftswert wird erst dann erschlossen, wenn die Anwendung tatsächlich in einer Zielumgebung läuft und für die Benutzer zugänglich ist. Und nicht nur die endgültige Freigabe für die Produktion erfordert eine Bereitstellung: Jeder UAT-, Performance- oder Integrationstest erfordert in der Regel eine Anwendung, die in einer "echten" Umgebung läuft, nicht auf dem lokalen Rechner eines Entwicklers. Ein Test, eine Bereitstellung.Angesichts der bekannten Kosten und negativen Auswirkungen fehlerhafter Software in der Produktion stellt die Möglichkeit, die Qualität, Benutzerfreundlichkeit und Leistung durch eine wesentlich höhere Anzahl von Testzyklen zu verbessern, an sich schon einen bedeutenden Mehrwert dar.Eine der Folgen dieser erhöhten Aufmerksamkeit ist, dass die Bedeutung von Build-, Release- und Deployment-Experten als Lieferanten von Geschäftswerten immer mehr erkannt wird. Der verstärkte Fokus bedeutet aber auch, dass viele Unternehmen erkennen, dass die Effektivität, die Einfachheit und der Aufwand ihrer Release- und Deployment-Prozesse weit hinter denen von Build und Continuous Integration zurückbleiben.Da meine Aufgabe bei XebiaLabs darin besteht, die Deployment-Prozesse in der gesamten Branche zu untersuchen, zu automatisieren und zu verbessern und dabei zu helfen, unsere Vision für das Deployment in der Zukunft zu entwickeln, musste früher oder später die Frage auftauchen, warum sich das Deployment in den Unternehmen von heute so sehr von Build unterscheidet. Die daraus resultierenden Diskussionen und Überlegungen bildeten die Grundlage für diese Serie.

Was ist in einem Wort enthalten?

Eine der Herausforderungen bei der Diskussion über die Bereitstellung im Zusammenhang mit Build, Release, Provisioning und anderen Aufgaben im ALM-Bereich ist der - glücklicherweise abnehmende - Mangel an einer klaren gemeinsamen Definition für die Bereitstellung. Ohne dies als die richtige Definition verkünden zu wollen, möchte ich im Rahmen dieser Diskussion die Bereitstellung als den Prozess betrachten, der

nimmt die Komponenten, aus denen ein Release besteht (in der Regel eine bestimmte Version einer Anwendung) und richtet sie in einer Infrastrukturumgebung korrekt ein, so dass das Release für (End-)Benutzer zugänglich ist

Dies unterscheidet sie von Build und Release, da hier davon ausgegangen wird, dass die Anwendungskomponenten bereits erstellt wurden, und von der Bereitstellung und anderen Infrastrukturaufgaben, da davon ausgegangen wird, dass die Zielinfrastruktur bereits vorhanden ist. Virtuelle On-Demand- oder Cloud-Umgebungen oder virtuelle Appliances sind ein etwas anderes Thema und werden in einem späteren Blog behandelt.

Ein Blick in die Vergangenheit

Wenn wir die obige Definition als Arbeitsgrundlage nehmen, ergibt sich das ernüchternde Bild, dass die Bereitstellung mit wenigen Ausnahmen heute so ziemlich das Stadium erreicht hat, in dem sich Build in den Tagen des Make-Gurus befand: eine Blackbox, die von einem Spezialisten zusammengebaut und bedient wird und irgendwie funktioniert. Wenn Sie Glück haben, ist diese wertvolle Ressource noch im Einsatz und in der Nähe, um bei Bedarf Dinge zu reparieren oder zu erweitern, aber wenn er oder sie nicht da ist, haben Sie einfach Pech gehabt. Fairerweise muss man sagen, dass es einige Stellen gibt, an denen zumindest Tools oder Automatisierungen vorhanden sind, die versuchen, die Abfolge der Schritte oder Aktionen, die für die Durchführung einer Bereitstellung erforderlich sind, abzubilden, um zumindest eine gewisse Transparenz und Nachvollziehbarkeit zu schaffen und die "Magie" zu beleuchten. Aber das ist noch weit entfernt von der Push-Button-Erfahrung, die Build heutzutage ist. Einen Prozess mühsam zu visualisieren und Schritt für Schritt zu durchlaufen, ist letztlich immer noch ein Zeichen für mangelndes Vertrauen. Ein wirklich ausgereifter Prozess zeigt seine Interna nicht mehr an, er "funktioniert einfach". Ähnlich wie Build heute.

Der Weg zu "just works"

Natürlich war auch Build nicht von Anfang an ein Prozess, der "einfach funktioniert". Was waren also die Schritte, die diesen Übergang möglich gemacht haben? Wenn man sich die Entwicklung der Java-Build-Tools in den letzten zehn Jahren ansieht, gibt es mindestens drei wesentliche Entwicklungen:

1. Wiederverwendbare Befehle
2. Modelle
3. Konventionen++

Im nächsten Blog werden wir die Details dieser drei Konzepte näher erläutern...

• Deployment ist das neue Build Teil 1
• Deployment ist das neue Build Teil 2
• Deployment ist das neue Build Teil 3