Es ist Zeit für NetOps, sich auf Continuous Deployment einzulassen

Kontinuierliche Bereitstellung muss nicht bedeuten, dass jede Änderung jedes Mal sofort durchgeführt wird. Aber irgendwo muss es anfangen.

CI/CD (Continuous Integration/Continuous Delivery) ist die Domäne der Entwickler. Es handelt sich dabei um das übergreifende Modell zur Verbesserung der Bereitstellungsgeschwindigkeit. Für diejenigen, die es gewohnt sind, es in einem aktiveren, benutzerbezogenen Kontext zu sehen, bedeutet es eigentlich „bereit zur Bereitstellung“.

Das bedeutet nicht, dass NetOps CI/CD ignorieren können. Im Gegenteil. Dies bedeutet jedoch nicht, dass NetOps ein Bereitstellungs-Lieferungs-Verhältnis von 1:1 einhalten muss. Die Häufigkeit, mit der Apps „bereit zur Bereitstellung“ sind, kann überwältigend sein, insbesondere wenn Ihre App-Entwickler die Kunst der kontinuierlichen Bereitstellung perfektioniert haben, insbesondere wenn NetOps die Kunst der kontinuierlichen Bereitstellung noch nicht ganz perfektioniert hat.  Es besteht jedoch die Möglichkeit, eine höhere Bereitstellungshäufigkeit zu ermöglichen, die für Entwickler und Unternehmen in manchen Fällen sicherlich einem kontinuierlichen Einsatz gleichkommt. 

Das Geheimnis liegt im Unterschied zwischen „kleineren Änderungen“ und „großen Änderungen“ an einer App.

Die NetDevOps-Umfrage vom Herbst 2016 ergab, dass kleinere Änderungen viel häufiger in die Produktion gelangen, als uns oft glauben gemacht wird. Fast 51 % der Befragten führen mehrmals täglich kleinere Änderungen in der Produktion durch. Mehr als jeder Dritte drängte auf ein bis fünf größere Änderungen pro Monat, und ein weiteres Drittel gab zu, weniger als einmal pro Monat größere Änderungen vorzunehmen.

Leider ist die Definition von „großen“ und „kleinen“ Änderungen nicht quantifiziert, aber wie das normalerweise der Fall ist, sind solche relativen Beschreibungen oft nicht nur für eine Branche oder Organisation spezifisch, sondern für jede einzelne Anwendung. Dennoch scheint es, dass eine beträchtliche Zahl – etwas mehr als die Hälfte – regelmäßig größere Veränderungen in der Produktion vornimmt.

Das bedeutet, dass wir im Großen und Ganzen kleine Schritte in Richtung kontinuierlicher Bereitstellung unternehmen. Der Punkt ist, dass die Bereitstellung einer brandneuen Anwendung nicht dasselbe ist wie die Bereitstellung von Updates für eine vorhandene Anwendung. Selbst wenn wir neue Netzwerk- oder App-Dienste hinzufügen, ist das Störungspotenzial immer noch etwas ganz anderes als die Bereitstellung einer brandneuen Anwendung.

Nehmen wir also zunächst einmal an, dass schicke neue Apps mehr Koordination und Planung erfordern. Es bleibt immer noch die Mehrheit der Apps in der Produktion, die potenzielle Ziele für die kontinuierliche Bereitstellung sind. Wir können dies unter anderem dadurch fördern, dass wir „kleinere“ und „große“ Änderungen im Hinblick auf ihre Auswirkungen auf die Produktionsumgebungen in einen Kontext setzen.

Kleinere Änderungen können auf solche beschränkt sein, die sich intern auf die App auswirken. Änderungen in der Logik zum Beispiel. Sie können Patches oder Upgrades für den App-Stack (Webserver, App-Server usw.) sowie für die unterstützende App -Infrastruktur enthalten. Kleinere Änderungen wirken sich grundsätzlich nur auf die App aus. Sie erfordern keine Änderungen am Netzwerk oder an den App-Diensten, die die App bei ihrer typischen Verwendung tatsächlich bereitstellen und sichern.

Größere Änderungen wären dann solche, die sich auf alles im Netzwerk oder auf App-Dienste auswirken, die die App unterstützen. Größere Änderungen könnten Anpassungen an einer Übermittlungsrichtlinie erfordern (Komprimierung aktivieren, ja?) oder die Einfügung eines neuen Dienstes, wie URL-Filterung oder Anforderungsprüfung, um die Ausnutzung einer kürzlich entdeckten Sicherheitslücke zu verhindern. Dabei handelt es sich um gravierende Änderungen, da sie sich auf eine größere Anzahl von Produktionssystemen auswirken, die sich wiederum auf andere Anwendungen auswirken können, dies jedoch nicht müssen.

Möglicherweise müssen Sie sogar ein differenzierteres Bewertungssystem erarbeiten, das die Auswirkungen auf externe Dienste berücksichtigt. Ein neuer Dienst verursacht wahrscheinlich größere Umbrüche als die Verbesserung eines bestehenden Dienstes. Bei der Umsetzung einer neuen Richtlinie ist mehr Aufmerksamkeit erforderlich als bei einer bestehenden Richtlinie mit einer kleinen Aktualisierung.

Sobald Sie sich auf das zu verwendende „System“ geeinigt haben, ist es viel einfacher, kleinere Änderungen bei Bedarf zuzulassen. Im Wesentlichen bewegen Sie sich in Richtung kontinuierlicher Bereitstellung, indem Sie die Bereitstellung von Apps in die Produktion einfließen lassen, solange davon ausgegangen wird, dass ein möglicher Fehler nur minimale Auswirkungen hat . Kleine Änderungen, kleines Risiko. Das ist zumindest die Annahme.

Dadurch können kleinere technische Änderungen, die möglicherweise größere geschäftliche Änderungen darstellen, schneller den Benutzern zur Verfügung gestellt werden. Denn diese werden in großen, traditionellen Organisationen oft aufrechterhalten. Sogar eine kleine Änderung der Benutzeroberfläche kann sich aufgrund von Terminkonflikten und Entscheidungen der Änderungskontrollgremien auf der Grundlage von Projektprioritäten oder politischen Vorgaben wochenlang oder länger verzögern. Auch wenn diese kleine Änderung möglicherweise eine bessere Benutzererfahrung bedeutet, die zu höheren Konvertierungs- oder Kundenbindungsraten führt. Wenn diese kleine Änderung nur die App betrifft, es sich also um eine „geringfügige“ Änderung handelt, sind die IT-Politiken dann wirklich ein Grund, sie zurückzuhalten?

Bei kontinuierlicher Bereitstellung geht es nicht nur darum, automatisierte Pushes in die Produktion technisch zu ermöglichen, sondern auch darum, traditionelle Konstrukte niederzureißen, die die Prozesse aufhalten, die bestimmen, wann Anwendungen und Updates in die Produktion gelangen (das ist Kultur).

Durch die Festlegung gemeinsamer Kriterien zur Unterscheidung zwischen „kleineren“ und „größeren“ Updates, also zwischen solchen, die sich potenziell auf Systeme außerhalb der App auswirken, und solchen, bei denen dies nicht der Fall ist, können Unternehmen die kontinuierliche Bereitstellung einiger Änderungen ermöglichen, ohne zusätzliche Risiken einzugehen oder die Produktion zu destabilisieren. Und es könnte durchaus positive Auswirkungen auf das Geschäft haben, sodass alle gewinnen.