Unabhängig davon, ob Agile, Cloud oder DevOps1 der Auslöser sind, oder ob es sich um eine "einfache" Effizienzsteigerung oder eine Initiative zur Prozessverbesserung handelt, suchen zukunftsorientierte Unternehmen derzeit nach Möglichkeiten, ihre Anwendungsfreigabeprozesse durch Automatisierung zu verbessern. In einem Bereich, in dem manuelle Tätigkeiten immer noch allzu häufig vorkommen, ist es nicht überraschend, dass der Schwerpunkt zunächst auf der Automatisierung der Ausführung der Bereitstellung lag, d.h. darauf, alle Teile an die richtigen Stellen zu verschieben. Was die ersten Anwender gelernt haben, ist, dass die Automatisierung der Release-Ausführung auf Unternehmensebene in den dynamischen IT-Umgebungen von heute schnell einen neuen Engpass mit sich bringt: die kontinuierliche Verwaltung der Definition des Bereitstellungsplans. Eine neue Generation von Tools zur Automatisierung von Anwendungsreleases (ARA) umgeht diesen Engpass, indem sie Intelligenz einsetzt, um sowohl die Planung als auch die Ausführung der Bereitstellung zu automatisieren.
Wenn man bedenkt, wie sehr sich unsere IT-Branche der Automatisierung von Prozessen verschrieben hat, ist es geradezu erstaunlich, wie sehr der Einsatz unserer eigenen Lösungen von manuellen Aktionen abhängt, die mehr oder weniger effektiv zwischen großen Gruppen von Menschen koordiniert werden.
Einem kürzlich erschienenen Analystenbericht zufolge verlässt sich die Mehrheit der großen Unternehmen immer noch auf manuelle Prozesse zur Anwendungsfreigabe oder auf interne Skripte, die nur von wenigen Spezialisten verstanden werden und als Blackbox betrieben werden, die - hoffentlich - ihre Aufgabe erfüllt, und die höchstwahrscheinlich eine schmerzhafte Fehlersuche nach sich zieht, wenn dies nicht der Fall ist.
Angesichts wichtiger IT-Trends wie Agile, Cloud und DevOps, die die Häufigkeit von Anwendungsreleases drastisch erhöhen, um die Reaktionsfähigkeit auf geschäftliche Anforderungen zu erhöhen und den Kunden mehr und bessere Dienste anzubieten, ist es klar, dass diese Situation nicht so bleiben kann.
Wenn man an die heute üblichen Release-Prozesse denkt, ist es auch nicht verwunderlich, dass der ursprüngliche Antrieb darin bestand, das eigentliche Rollout der Anwendung selbst zu automatisieren: Kopieren der Dateien auf die Zielrechner, Neustart der Server, Ausführen von SQL gegen die DB usw. Die Verwendung eines definierten Workflows zur Organisation dieser Aktivitäten ist sehr sinnvoll: weniger Fehler, keine fehlenden oder in der falschen Reihenfolge ausgeführten Schritte mehr, keine Tippfehler mehr, bessere Visualisierung usw.
Ironischerweise wurde bei der Verwendung eines dieser ARA-Tools der ersten Generation im Unternehmensmaßstab den frühen Anwendern schnell klar, wie viel Aufwand für die Pflege der beträchtlichen Anzahl von Workflow-Definitionen erforderlich ist, die sich schnell ansammeln, um vollständige Implementierungen, partielle Upgrades, Rollbacks, Umgebungs-Scale-Outs usw. in einem Unternehmensanwendungsportfolio zu unterstützen.
Natürlich ist dies keine neue Herausforderung: Fragen Sie jeden, der schon einmal 100 Build-Job-Definitionen in einem Continuous-Integration-Tool aktualisieren musste, um einen Kompilierungsparameter zu ändern, oder 100 Testpläne in einer automatisierten Testumgebung, um einen anderen Zielbrowser zu berücksichtigen, wie zeitaufwändig und fehleranfällig diese Art der Wartung ist.
Es ist nicht so, dass diese Änderungen pro Prozess einmalig sind. In der Regel handelt es sich um systematische Änderungen, die Änderungen an der gesamten Bereitstellungsstrategie und/oder am Kontext widerspiegeln. Das Problem ist, dass diese Tools der ersten Generation, bei denen die gesamte Verteilungsintelligenz im Gehirn des Power-Users gespeichert ist, einfach nicht genug internes Wissen über die Struktur der Verteilung haben, um effektiv zu helfen.
Eine neue Generation von Application Release Automation beinhaltet diese Intelligenz. Diese fortschrittlichen Tools2 erfordern nicht mehr, dass Sie Ihre Power-User bei jedem Schritt an die Hand nehmen. Sie kodieren das Wissen über bewährte Verfahren und Strategien zur Automatisierung der Planung und Ausführung von Implementierungen. 3
Keine vorgefertigte Strategie kann zu 100% in eine Unternehmensumgebung passen, daher müssen die Strategien natürlich konfigurierbar sein. Sobald Ihre Power-User sie jedoch feinabgestimmt haben, werden alle individuellen Bereitstellungspläne - Erstinstallationen, vollständige und partielle Upgrades, Downgrades, Aufhebung von Bereitstellungen, Scale-Outs usw. - einfach Hunderte über ein Anwendungsportfolio hinweg - automatisch auf Ihr Szenario zugeschnitten.
Dies wird umso effizienter, je weniger Bereitstellungsstrategien im Spiel sind. Daher motivieren und belohnen diese Tools auch eine stärkere Standardisierung der Bereitstellungsverfahren, was an sich schon ein wertvolles Geschäftsziel ist. Mit einer geeigneten Schnittstelle und Integrationen in die Entwicklungspipeline haben Sie im Grunde eine Unternehmensplattform als Service, möglicherweise in einer privaten oder hybriden Cloud.
Der Stand der ARA

Lektionen der ersten Generation

Die nächste Stufe der Anwendungs-Release-Automatisierung

Schlussfolgerungen
Mit der rasant zunehmenden Verbreitung von Application Release Automation erscheint eine neue Generation von Lösungen, die sowohl die Planung als auch die Ausführung der Bereitstellung automatisieren. Basierend auf den Herausforderungen, die bei der Skalierung der ersten Generation von ARA-Tools auf Unternehmensebene aufgetreten sind, wurden diese Lösungen der nächsten Generation so konzipiert, dass sie das ständige Eingreifen von Experten überflüssig machen, die Standardisierung fördern und es Unternehmen ermöglichen, eine "Software-Fabrik" zu schaffen, die kontinuierlich Geschäftswerte liefert.Fußnoten
- Ich bevorzuge nach wie vor die Schreibweise "Devops", denn schließlich geht es ja darum, dass Dev und Ops nicht mehr als getrennt betrachtet werden, aber hey... ;-)
- wie XebiaLabs' Deployit
- Dieser Fortschritt spiegelt die Entwicklung von Build-Frameworks wider, von Tools wie Ant zu den heutigen Industriestandards wie Maven und weiter zur nächsten Generation von Gradle, SBT und anderen.
Verfasst von
Andrew Phillips
Unsere Ideen
Weitere Blogs
Contact
Let’s discuss how we can support your journey.



