DE112016005867T5

DE112016005867T5 - Live-Pipeline-Vorlagen - Erstellung und Erweiterbarkeit der Vorlagen

Info

Publication number: DE112016005867T5
Application number: DE112016005867.5T
Authority: DE
Inventors: Martin Robert Frank; Ian Aird Mosher; Felix Walter Blue JODOIN; Mark Sidney James MANSOUR; Sixiang GU
Original assignee: Amazon Technologies Inc
Current assignee: Amazon Technologies Inc
Priority date: 2015-12-21
Filing date: 2016-12-21
Publication date: 2018-09-20
Also published as: CN108701057A; CN108701057B; WO2017112801A1

Abstract

Techniken zum Verwalten einer Deployment-Pipeline unter Verwendung einer vererbbaren und erweiterbaren Vorlage für den Quellcode sind vorgesehen - allgemein als eine Live-Pipeline-Vorlage (LPT) bezeichnet. Wie beschrieben, können Live-Pipeline-Vorlagen verwendet werden, um Deployment-Pipelines zu verwalten, die wiederum verwendet werden, um die Dienste und Systeme einzuführen, zu warten und zu aktualisieren, die verwendet werden, um Rechendienste zu hosten und bereitzustellen.

Description

ALLGEMEINER STAND DER TECHNIK
Cloud-Computing ist zu einem weithin angenommenen Ansatz geworden, durch den ein Unternehmen Zugriff auf große Mengen an Rechenressourcen erhält. Eine der Haupttechnologien, auf denen Cloud-Computing basiert, ist die Virtualisierung. Durch Virtualisierung kann ein physischer Rechenserver mehrere Instanzen einer virtuellen Maschine hosten, von denen jede als ein unabhängiges Rechensystem mit virtuellen Hardwarekomponenten ausgeführt wird, wie etwa ein CPU und ein Speicher, verwaltet durch ein Betriebssystem. Nach der Einführung kann ein Unternehmen Anwendungen auf einer Instanz einer virtuellen Maschine so ausführen wie Anwendungen, die auf einem physischen Rechensystem oder Server ausgeführt werden, das/der durch das Unternehmen verwendet wird. Da zusätzliche Instanzen einer virtuellen Maschine bei Bedarf eingeführt werden können, kann ein Unternehmen durch Cloud-Computing nach Bedarf auf Rechenressourcen zugreifen, ohne in eine darunterliegende physische Recheninfrastruktur investieren und diese warten zu müssen.
Neben der Bereitstellung von Rechendiensten (z. B. Instanzen einer virtuellen Maschine), kann ein Cloud-Computing-Anbieter Unternehmenskunden eine Vielzahl anderer Rechenressourcen und -dienste anbieten. Beispielsweise kann der Dienstleister Datenbankdienste, dauerhafte Speicherdienste, Netzwerkdienste, Lastverteilungsdienste, automatische Skalierungsdienste, Messaging-Dienste, Cloud-Bildungsdienste, Überwachungsdienste usw. als Teil eines cloudbasierten Dienstangebots anbieten.
Egal ob sich ein Unternehmen entscheidet, einen Rechendienst auf einer Recheninfrastruktur des Unternehmens oder unter Verwendung virtualisierter Dienste von einem Cloud-Computing-Anbieter zu hosten, kann die Konfiguration der darunterliegenden Systeme und Dienste, die zum Hosten eines Rechendienstes verwendet werden, eine anspruchsvolle Aufgabe sein. Folglich können Techniker mehrere Tage damit zubringen, die Systeme und Dienste zu konfigurieren, die erforderlich sind, um selbst einen einfachen Dienst zu hosten. Zudem können nach der Bereitstellung das Aktualisieren der Anwendung, das Ändern der Konfiguration der darunterliegenden Systeme und Dienste oder die Verwendung der Anwendung auf zusätzlichen Systemen oder an zusätzlichen Standorten ebenfalls erhebliche Mengen der Zeit der Techniker in Anspruch nehmen. Nehmen wir beispielsweise an, ein Unternehmen möchte eine Einkaufswebseite im Bereich Einzelhandel bereitstellen, wobei die Webseite durch Webserver, Anwendungsserver und Datenbankanwendungen unterstützt wird, die unter Verwendung von Diensten eingesetzt werden, die durch einen Cloud-Computing-Anbieter angeboten werden. Dadurch müssen Techniker unter anderem eine Vielzahl von Instanzen einer virtuellen Maschine (oder Klassen von Instanzen) mit den gewünschten Web- und Anwendungsserveranwendungen konfigurieren und bereitstellen, den Content für diese Systeme bereitstellen, Netzwerkadressen konfigurieren, Datenbank- und Speicherdienste konfigurieren, Sicherheitsmechanismen bereitstellen (z. B. Bereitstellen von SSL-Zertifikaten auf allen Systemen zur Öffentlichkeit), administrative und rollenbasierte Zugriffskontrollen konfigurieren, Lastverteilungssysteme konfigurieren und einführen, Gruppen skalieren, sowie Anwendungen zur Überwachung, zur Protokollierung und zur Berichtslegung konfigurieren. Einmal bereitgestellt, kann das Hinzufügen von Funktionen oder das Aktualisieren der Software, die verwendet wird, um einen Dienst für die Öffentlichkeit bereitzustellen (z. B. die Einzelhandelswebseite), einen ähnlichen Konfigurations- und Bereitstellungsumfang erfordern.
Ähnliche Anforderungen gelten für den Cloud-Computing-Anbieter im Hinblick auf die Exponierung der darunterliegenden Cloud-Computing-Dienste, die durch das die Einzelhandelswebseite bereitstellende Unternehmen verwendet werden. Beispielsweise müssen die Techniker beim Cloud-Computing-Anbieter durch das Einführen eines Rechendienstes, eines automatischen Skalierungsdienstes, eines Datenbankdienstes, eines Speicherdienstes usw. die darunterliegenden Rechensysteme und -anwendungen separat konfigurieren und bereitstellen, die verwendet werden, um den jeweiligen Cloud-Computing-Dienst bereitzustellen.
In Anbetracht der Komplexität selbst bei Bereitstellung eines relativ einfachen Rechendienstes, wird ein Unternehmen häufig ein Bereitstellungs- oder Einführungsverfahren entwickeln, um festzulegen, wie ein neuer Dienst eingeführt (oder an einem neuen Standort eingeführt) wird. Das Bereitstellungsverfahren kann im Allgemeinen eine Konfiguration für den bereitgestellten Dienst vorgeben. In einigen Fällen kann das Bereitstellungsverfahren zudem einen Satz Teststufen vorgeben - oftmals als eine Deployment-Pipeline bezeichnet - die verwendet werden, um einen Dienst für die Öffentlichkeit einzurichten (z. B. Integrationstests, gefolgt von den Stufen alpha, beta und gamma), neben Erfolgs-, Misserfolgs- oder Ausrollbedingungen für jede Stufe. Dieselbe Deployment-Pipeline kann verwendet werden, um die Anwendungen, Systeme oder Dienste zu aktualisieren, die verwendet werden, um den Dienst für die Öffentlichkeit bereitzustellen, oder, wenn die darunterliegenden Systeme oder Dienste, die verwendet werden, um einen derartigen Dienst bereitzustellen, geändert werden. Gleichermaßen kann der Dienstleister eine Deployment-Pipeline definieren, die verwendet wird, um Änderungen am Quellcode der Anwendung (z. B. Fehlerbehebungen oder neue Funktionen) auf die Produktionssysteme zu übertragen, die einen bestimmten Dienst hosten. Eine derartige Pipeline kann Integrationstests, alpha-, beta- und gamma-Teststufen und Arbeitsabläufe zum Freigeben oder Abschließen jeder Stufe oder Zurückrollen einer Anwendung auf einen vorhergehenden Zustand vorgeben, wenn eine neue Version der Anwendung, die auf das Produktionssystem übertragen wird, eine Freigabeanforderung nicht erfüllt oder es sich herausstellt, dass dadurch der Dienst unterbrochen wird.
Dieser Ansatz überlässt jedoch den Technikern, die eine bestimmte Deployment-Pipeline verwalten, die korrekte Konfiguration und Bereitstellung jedes Systems und Dienstes, sowie die Einhaltung der besten Vorgehensweisen eines beliebigen Unternehmens hinsichtlich der Erstellung einer Deployment-Pipeline. Dies kann zu widersprüchlichen Ergebnissen über verschiedene Deployment-Pipelines für ansonsten ähnliche Dienste oder Anwendungen führen. Zudem wird durch diesen Ansatz die Fähigkeit eines Unternehmens eingeschränkt, ein Bereitstellungsverfahren erneut zu verwenden oder zu standardisieren. Anstelle dessen schneiden Techniker oftmals Elemente einer vorhandenen Deployment-Pipeline aus, fügen diese ein und passen diese kundenindividuell an, um diese bei einem neuen Dienst zu verwenden (oder bei neuen Instanzen eines vorhandenen Dienstes). Ein ähnlicher Ansatz tritt auf, wenn ein Unternehmen auf einen Änderungsverwaltungsprozess zurückgreift, um die Funktionen oder Anforderungen einer Anwendung oder eines Dienstes zu aktualisieren. In derartigen Fällen müssen Techniker einen erheblichen Zeitaufwand betreiben, um zu planen, wie ein Update für die Systeme und Anwendungen bereitgestellt und getestet werden soll, die einen Dienst für die Öffentlichkeit bieten. Dementsprechend können für ein Unternehmen, das eine Handvoll Deployment-Pipelines selbst verwaltet, die Wartung, Aktualisierung oder Änderung des Satzes Deployment-Pipelines im Rahmen der Entwicklung bester Vorgehensweisen oder des Aufbaus neuer Deployment-Pipelines für neue Rechendienste erhebliche Technikerressourcen binden. Folglich kann das Verwalten eines Satzes Deployment-Pipelines zu einer Ablenkung für das Unternehmen im Hinblick auf die Verbesserung der Qualität oder Funktionen der eigentlichen Anwendungen oder Dienste werden, die durch eine Deployment-Pipeline bereitgestellt werden.
Figurenliste
Verschiedene Ausführungsformen gemäß der vorliegenden Offenlegung werden unter Bezugnahme auf die Zeichnungen beschrieben, wobei:

1 ein Beispiel einer Cloud-Computing-Umgebung mit mehreren Regionen veranschaulicht, von denen jede eine regionale Instanz eines Produktionsrechendienstes hostet, die über eine kontinuierliche Deployment-Pipeline bereitgestellt wird, entsprechend einer Ausführungsform.
2 ein Beispiel einer „Meta-Pipeline“ veranschaulicht, die verwendet wird, um eine kontinuierliche Deployment-Pipeline für einen Produktionsrechendienst aufzubauen und zu konfigurieren, entsprechend einer Ausführungsform.
4 beispielsweise ein Beispiel eines Quellcodes für eine Vorlageninstanz einer Live-Pipeline-Vorlage veranschaulicht, entsprechend einer Ausführungsform.
4 ein Beispiel eines Quellcodes für eine Instanz einer Live-Pipeline-Vorlage veranschaulicht, die zuerst in 3 veranschaulicht wurde, entsprechend einer Ausführungsform.
5 ein konzeptionelles Diagramm ist, das den Datenfluss für ein Syntheseverfahren einer Live-Pipeline-Vorlage veranschaulicht, die verwendet wird, um eine Deployment-Pipeline zu konfigurieren, entsprechend einer Ausführungsform.
6 ein Beispiel einer kontinuierlichen Deployment-Pipeline veranschaulicht, die auf der Grundlage der Anwendungsdefinition und der LPT-Instanz erzeugt wurde, die in 5 dargestellt ist, entsprechend einer Ausführungsform.
7 ein Verfahren zum Erzeugen, auf der Grundlage einer Live-Pipeline-Vorlage, einer Deployment-Pipeline veranschaulicht, die verwendet wird, um einen Produktionsrechendienst bereitzustellen, entsprechend einer Ausführungsform.
8 ein Verfahren veranschaulicht, mit dem eine Meta-Pipeline eine Deployment-Pipeline modifiziert, die selbst verwendet wird, um einen Produktionsrechendienst auf der Grundlage von Änderungen an einer Live-Pipeline-Vorlage bereitzustellen, entsprechend einer Ausführungsform.
9 ein Verfahren zum Ermitteln veranschaulicht, ob Änderungen an einer Live-Pipeline-Vorlage auf die Blattsysteme einer kontinuierlichen Deployment-Pipeline verbreitet werden können, entsprechend einer Ausführungsform.
10 ein Verfahren zum automatischen Konfigurieren und Bereitstellen einer Deployment-Pipeline in einer neu verfügbaren Cloud-Computing-Region auf der Grundlage einer vorhandenen Live-Pipeline-Vorlage veranschaulicht, entsprechend einer Ausführungsform.
11 ein Beispiel für Komponenten von Blattsystemtreibern veranschaulicht, die verwendet werden, um Rechenressourcen als Teil der Bereitstellung eines Produktionsdienstes zu konfigurieren, bereitzustellen und zu prüfen, entsprechend einer Ausführungsform.
12 ein konzeptionelles Diagramm ist, das ein Analyseverfahren einer Live-Pipeline-Vorlage veranschaulicht, das verwendet wird, um die Konfiguration eines bereitgestellten Rechendienstes zu bewerten, entsprechend einer Ausführungsform.
13 Komponenten eines Pipeline-Analysetools veranschaulicht, das verwendet wird, um eine Analyse der Live-Pipeline-Vorlage durchzuführen, entsprechend einer Ausführungsform.
14 eine beispielhafte Schnittstelle veranschaulicht, die Probleme in einer Produktions-Pipeline erkennt, die durch die Analyse der Live-Pipeline-Vorlage zu Tage getreten sind, entsprechend einer Ausführungsform.
15 ein konzeptionelles Diagramm ist, das einen Datenstrom für ein LPT-Analyseverfahren veranschaulicht, das verwendet wird, um eine Deployment-Pipeline zu bewerten, die verwendet wird, um einen Produktionsrechendienst bereitzustellen, entsprechend einer Ausführungsform.
16 ein Verfahren zum Überwachen einer Deployment-Pipeline unter Anwendung des LPT-Analyseverfahrens veranschaulicht, entsprechend einer Ausführungsform.
17 ein Verfahren veranschaulicht, mit dem die Konfiguration und Bereitstellung einer kontinuierlichen Bereitstellungs-Pipeline für einen vorhandenen Rechendienst unter die Kontrolle einer Live-Pipeline-Vorlage gestellt werden soll, entsprechend einer Ausführungsform.
18 ein beispielhaftes Rechensystem veranschaulicht, das verwendet wird, um Komponenten des Live-Pipeline-Vorlagendienstes zu hosten, entsprechend einer Ausführungsform.

DETAILLIERTE BESCHREIBUNG
Die Verfügbarkeit und Verschiedenartigkeit von durch Cloud-Computing-Anbieter angebotenen Rechendiensten ist weiter im Wachstum begriffen. Für einen Cloud-Computing-Anbieter stellt es jedoch eine Herausforderung dar, eine Sammlung von Rechendiensten bereitzustellen und zu warten, die Kunden angeboten (oder intern verwendet) werden. Unternehmen, die eine Sammlung von Anwendungen oder Diensten für einen Cloud-Anbieter bereitstellen und warten oder die Anwendungen oder Dienste auf ihrer eigenen Recheninfrastruktur hosten, sehen sich ähnlichen Herausforderungen gegenüber.
In der vorliegenden Schrift dargestellte Ausführungsformen sehen Techniken zum Verwalten einer Deployment-Pipeline unter Verwendung einer vererbbaren und erweiterbaren Vorlage für den Quellcode vor - allgemein als eine Live-Pipeline-Vorlage (LPT) bezeichnet. Wie in der vorliegenden Schrift näher beschrieben, können sowohl der Unternehmenskunde als auch der Cloud-Computing-Anbieter durch Live-Pipeline-Vorlagen Deployment-Pipelines definieren und verwalten, die wiederum verwendet werden, um die Dienste und Systeme einzuführen, zu warten und zu aktualisieren, die verwendet werden, um Rechendienste zu hosten und bereitzustellen. Anders ausgedrückt, kann eine Live-Pipeline-Vorlage im Allgemeinen verwendet werden, um ein umfassendes Modell einer Deployment-Pipeline und eine Produktionskonfiguration für eine bestimmte Art von Anwendung oder Dienst einzukapseln. Deployment-Pipelines, die unter Verwendung einer Live-Pipeline-Vorlage erstellt wurden, werden manchmal als eine „kontinuierliche Deployment-Pipeline“ bezeichnet, da Änderungen an der über eine derartige Pipeline bereitgestellten Anwendung oder an dem über eine derartige Pipeline bereitgestellten Dienst durch Pipeline-Stufen automatisch auf eine Produktionsbereitstellung verteilt werden können (oder zurückgerollt, wenn Fehler oder Konflikte erkannt werden).
Bei einer Ausführungsform kann ein Entwickler, anstatt ein Bereitstellungsverfahren oder eine Bereitstellungsstrategie für die Entwicklung einer neuen Anwendung oder eines neuen Dienstes von Null an zu entwickeln (oder um eine vorhandene Anwendung oder einen vorhandenen Dienst an einem neuen Standort bereitzustellen), eine kleine Menge an Informationen über den bestimmten Dienst oder die bestimmte Anwendung im Quellcode einer Live-Pipeline-Vorlage vorgeben. Die Informationen werden anschließend verwendet, um eine neue Instanz dieser Live-Pipeline-Vorlage zu erzeugen, die unter Verwendung des durch den Entwickler vorgegebenen Quellcodes kundenspezifisch angepasst wird. Beispielsweise kann der Entwickler hochrangige Einzelheiten über die Anwendung oder den Dienst in der Live-Pipeline-Vorlage vorgeben, wie etwa einen Dienstnamen, (einen) administrative(n) Kontakt(e) und wo die Pipeline bereitgestellt werden sollte (oder nicht), wie etwa ein bestimmter Satz Cloud-Computing-Regionen, die durch einen Cloud-Dienste-Anbieter angeboten werden. Zudem sorgt die Modellierung des Bereitstellungsverfahrens für einen bestimmten Anwendungs- oder Diensttyp unter Verwendung einer Live-Pipeline-Vorlage dafür, dass die Konfiguration der Deployment-Pipeline unter die Kontrolle des Quellcodes gestellt wird. Das heißt, anstatt ein Bereitstellungsverfahren unter Verwendung von Änderungsverwaltungsbefehlen oder ad-hoc-Abläufen vorzugeben, wird eine Deployment-Pipeline unter Verwendung von Quellcode einer Live-Pipeline-Vorlage vorgegeben, die im Anschluss durch einen Entwickler für jede Instanz dieser Live-Pipeline-Vorlage lokalisiert werden kann.
Die übrige Live-Pipeline-Vorlage umfasst beste Vorgehensweisen zum Konfigurieren, Bereitstellen und Warten einer Instanz des Diensttyps, der der Live-Pipeline-Vorlage entspricht. Beispielsweise kann die Live-Pipeline-Vorlage eine Vielzahl von Software oder anderen Artefakten vorgeben, die durch die Deployment-Pipeline benötigt werden, einschließlich beispielsweise eine Bereitstellungssystemkonfiguration, Bereitstellungsnutzer, Pipeline-Stufen zum Bereitstellen oder Aktualisieren der Anwendung, Hostklassen, Quellcodearchive, Abbilder oder Konfigurationen von virtuellen Maschinen, Netzwerkanforderungen (z. B. virtuelle IP-Adressen für zu verwendende Instanzen einer virtuellen Maschine), SSL-Zertifikate, Benutzernamen, Informationen zur Identitäts- und Zugriffskontrolle, Content für Berichtsübersichtsseiten, Performanzmetrikkriterien, Rollback- und Dauerzustandsüberwachungseinheiten, Überwachungsalarme usw.
Das bedarfsgerechte Überschreiben nur spezifischer Elemente einer Live-Pipeline-Vorlage erlaubt die Verwendung der Live-Pipeline-Vorlage im Rahmen der Erstellung einer dienstspezifischen Instanz einer kontinuierlichen Deployment-Pipeline, ohne dass ein Entwickler eine Deployment-Pipeline korrekt konfigurieren muss, was allen besten Vorgehensweisen bei der Bereitstellung einer Anwendung eines bestimmten Diensttyps entspricht. Anstelle dessen kapselt die Live-Pipeline-Vorlage die besten Vorgehensweisen ein, die für den Diensttyp erforderlich sind, und kann verwendet werden, um derartige Vorgehensweisen automatisch in der dienstspezifischen Instanz der Deployment-Pipeline zu erstellen und zu konfigurieren. Dementsprechend kann die Zeit, die zum Konfigurieren und Erstellen einer Deployment-Pipeline für einen komplexen Produktionsdienst erforderlich ist, von Tagen (oder sogar Wochen) auf Stunden verkürzt werden.
Bei einer Ausführungsform wird, sobald die hochrangigen Einzelheiten, die verwendet werden, um eine Instanz einer neuen Anwendung oder eines neuen Dienstes auf der Grundlage der Live-Pipeline-Vorlage zu definieren, vorgegeben sind, die Instanz verwendet, um ein umfassendes Modell der Deployment-Pipeline zu erzeugen. Das umfassende Modell kann eine vollständig vorgegebene Konfiguration für eine Deployment-Pipeline bereitstellen, die im Rahmen der Bereitstellung dieser Anwendung oder dieses Dienstes zu verwenden ist. Das umfassende Modell, im Allgemeinen als eine Anwendungsdefinition bezeichnet, kann während eines LPT-Syntheseverfahrens verwendet werden, um die Systeme und Dienste zu konfigurieren, die erforderlich sind, um die Deployment-Pipeline zu instanziieren. Die Anwendungsdefinition kann unter Verwendung eines maschinenlesbaren Austauschformates vorgegeben sein, z. B. als JSON- oder XML-Dokument. Während dem Syntheseverfahren wird jedes System und jeder Dienst, das/der durch die Deployment-Pipeline benötigt wird, eingeführt, konfiguriert oder anderweitig für eine Verwendung vorbereitet. Im Anschluss an die LPT-Synthese kann die resultierende Deployment-Pipeline verwendet werden, um eine Instanz einer Produktionsanwendung oder eines Produktionsdienstes bereitzustellen und zu warten. Das heißt, die Deployment-Pipeline kann verwendet werden, um die Anwendung oder den Dienst auf den Empfang von Kundenverkehr vorzubereiten und Aktualisierungen oder neue Funktionen des Dienstes durch die Pipeline in das Produktionssystem zu übertragen.
Bei einer Ausführungsform kann zu einem LPT-Tool ein Satz Blattsystemtreiber gehören, die verwendet werden, um einen Satz Dienste oder Systeme entsprechend der Vorgabe durch die Anwendungsdefinition zu konfigurieren. Beispielsweise kann jeder Blattsystemtreiber eine Softwareanwendung bereitstellen, die einem bestimmten Blattsystem entspricht, das in der Deployment-Pipeline enthalten ist, die durch eine Anwendungsdefinition modelliert wurde, wie etwa ein Überwachungsdienst, ein Alarmdienst, ein Bereitstellungsdienst usw. Jeder Blattsystemtreiber kann vorgeben, welche Teile der Anwendungsdefinition vor der Ausführung durch andere Treiber umgesetzt werden sollten. Beispielsweise kann ein Blattsystemtreiber, der einen Alarmdienst konfiguriert, erfordern, dass ein Überwachungsdienst konfiguriert wird und betriebsbereit ist, bevor der Alarmdienst konfiguriert und eingeführt wird. Das heißt, jeder Blattsystemtreiber kann beliebige Abhängigkeiten durchsetzen, die erforderlich sind, damit das entsprechende Blattsystem ordnungsgemäß funktioniert. Hierfür kann das LPT-Tool ermitteln, welche Elemente der Anwendungsdefinition instanziiert wurden, und, wenn die Abhängigkeiten befriedigt sind, einen oder mehrere der Blattsystemtreiber starten. Die Blattsystemtreiber führen wiederum API-Aufrufe durch, um ein entsprechendes Blattsystem konform mit der Anwendungsdefinition zu machen, wodurch zusätzliche Blattsystemtreiber ausgeführt werden können, bis die Deployment-Pipeline vollständig umgesetzt ist.
Durch Live-Pipeline-Vorlagen kann das Unternehmen automatisch durchgesetzte Mindeststandards für die Bereitstellung von Anwendungen eines bestimmten Diensttyps einstellen. Zudem können Vererbungsmechanismen, die durch eine bestimmte Quellcodesprache unterstützt werden, verwendet werden, um eine Basis-Live-Pipeline-Vorlage um dienst- oder domänenspezifische Informationen zu erweitern. Beispielsweise kann ein Unternehmen einen Mindestsatz von besten Vorgehensweisen vorgeben, die eine beliebige Deployment-Pipeline einhalten sollte, ungeachtet eines Anwendungsdiensttyps. Eine Live-Pipeline-Vorlage für einen bestimmten Diensttyp kann von der unternehmensweiten Vorlage vererbt werden und Aspekte der unternehmensweiten Live-Pipeline-Vorlage hinzufügen (oder überschreiben), die den spezifischen Diensttyp kennzeichnen. Darüber hinaus könnte ein bestimmter Unternehmensbereich von der dienstspezifischen Vorlage erben und Informationen zum Unternehmensbereich vorgeben (z. B. Benutzernamen oder Zugriffsrechte). Letztlich kann ein Entwickler für eine spezifische Instanz einer Live-Pipeline-Vorlage die Vorlage des Unternehmensbereiches abstufen und muss nur die instanzspezifischen Einzelheiten eines bestimmten Dienstes angeben, wie etwa einen Diensttyp, einen Dienstnamen, (einen) administrative(n) Kontakt(e) und in welchen Cloud-Computing-Regionen der Dienst bereitgestellt werden soll.
Steht die Konfiguration für eine Deployment-Pipeline unter der Kontrolle des Quellcodes, können jedwede Änderungen an den besten Vorgehensweisen im Zusammenhang mit dieser Deployment-Pipeline durch Fachleute geprüft und bewertet werden, bevor sie eingecheckt und in Instanzen dieser Pipeline umgesetzt werden. Bei einer Ausführungsform kann, wenn Änderungen an der Bereitstellungskonfiguration, die in einer Live-Pipeline-Vorlage vorgegeben sind, eingecheckt werden, das LPT-Tool die Konfiguration von beliebigen Deployment-Pipelines aktualisieren, die auf dieser Live-Pipeline-Vorlage basieren. Das heißt, eine Deployment-Pipeline (die verwendet wird, um Aktualisierungen oder Änderungen an einer Anwendung oder einem Dienst in die Produktion zu übertragen) kann selbst das Ziel einer „Schatten-“ oder „Meta-Pipeline“ sein, die verwendet wird, um Änderungen an der Deployment-Pipeline in die Produktion zu übertragen.
Zusätzlich zum Bereitstellen beliebiger Änderungen für eine Prüfung durch Fachleute, bevor diese eingecheckt werden, kann die Meta-Pipeline überwachen, ob eine bestimmte Änderung an einer Deployment-Pipeline, die in die Produktion übertragen wird, zu Fehlern oder Konflikten führt und zurückgerollt werden sollte. Zudem kann eine Meta-Pipeline neben der Reaktion auf Änderungen an einer Live-Pipeline-Vorlage eine Deployment-Pipeline überwachen und auf Änderungen an der Cloud-Computing-Umgebung reagieren. Beispielsweise kann das LPT-Tool so konfiguriert sein, dass es automatisch eine Deployment-Pipeline aus einer Live-Pipeline-Vorlage (die anschließend den darunterliegenden Dienst oder die darunterliegende Anwendung konfigurieren und bereitstellen kann) in neuen (oder zusätzlichen) Rechenregionen, Rechenzonen usw. erstellt, wenn diese von einem Cloud-Computing-Anbieter bereitgestellt werden (unter der Annahme, dass alle in derartigen Regionen, Zonen usw. geltenden notwendigen Dienstabhängigkeiten erfüllt sind).
Zusätzlich zum vorstehend beschriebenen LPT-Syntheseverfahren kann das LPT-Tool zudem ein LPT-Analyseverfahren durchführen, um die Konfiguration einer Deployment-Pipeline für eine bestimmte Anwendung oder einen bestimmten Dienst zu bewerten, egal ob diese Anwendung oder dieser Dienst auf der Grundlage einer Live-Pipeline-Vorlage oder unter Verwendung des LPT-Syntheseverfahrens bereitgestellt wurde. Beispielsweise können die Blattsystemtreiber bei einer Ausführungsform so konfiguriert sein, dass sie die Konfiguration einer Deployment-Pipeline prüfen und eine Anwendungsdefinition erstellen, die mit der eigentlichen Konfiguration dieser Deployment-Pipeline übereinstimmt oder mit dieser kompatibel ist. Beispielsweise könnten die Blattsystemtreiber erkennen, welche Stufen in einer Deployment-Pipeline enthalten sind, welche Alarme und Überwachungseinheiten für jede Stufe konfiguriert sind, welche Blattsysteme in jeder Stufe konfiguriert oder bereitgestellt sind (z. B. welche Instanzen einer virtuellen Maschine bereitgestellt, eingeführt und in die Produktion übertragen sind), welche Hostklassen definiert sind usw., und wie die Blattsysteme konfiguriert sind. Das LPT-Tool erzeugt dann eine Anwendungsdefinition, mit der die erkannte Konfiguration unter Verwendung desselben maschinenlesbaren Austauschformates beschrieben wird, das durch das LPT-Syntheseverfahren erzeugt wird, z. B. ein JSON- oder XML-Dokument.
Bei einer Ausführungsform kann das LPT-Tool die „Ground-Truth“-Anwendungsdefinition gegen einen Regelsatz bewerten, um Aspekte der Deployment-Pipeline zu ermitteln, die die Anforderungen einer bestimmten Regel nicht erfüllen. Die Regeln können verwendet werden, um sicherzustellen, dass eine Deployment-Pipeline die durch ein Unternehmen eingerichteten besten Vorgehensweisen einhält. Beispielsweise kann eine Regel bestimmen, ob eine Deployment-Pipeline gamma- und One-Box-Teststufen umfasst, die jeder Produktionsstufe vorgeschaltet sind, oder die Existenz einer Überwachungseinheit für das automatische Rollback für ein Bereitstellungssystem bestätigen, das die One-Box- und Produktionsstufen in der Deployment-Pipeline durchführt. Allgemeiner ausgedrückt, die Regeln können unter Verwendung bedingter Anweisungen oder bedingungsloser Anforderungen oder Attribute vorgegeben werden, die eingehalten werden oder vorhanden sein sollten. In einigen Fällen verhindert das LPT-Tool die Aktivierung einer Deployment-Pipeline, bis diese eine oder mehrere der Regeln erfüllt. Zusätzlich zum Erkennen von Aspekten einer Deployment-Pipeline, die eine oder mehrere Regeln nicht erfüllen, kann das LPT-Analyseverfahren jedoch zudem Maßnahmen vorschlagen, die erforderlich sind, um eine Deployment-Pipeline zu „heilen“ oder diese mit den besten Vorgehensweisen in Einklang zu bringen. Das heißt, das LPT-Tool kann einen bestimmten Regelverstoß mit einer Lösung zusammenführen, die eine Übereinstimmung mit der Regel sicherstellen soll. Dementsprechend kann das LPT-Tool ein Bereitstellungs- oder Entwicklungsteam bieten, das über die Ausbildung und die Werkzeuge verfügt, um die durch das Unternehmen als Ganzes übernommenen besten Vorgehensweisen einzuhalten (wie in den Regeln zum Ausdruck gebracht).
Zudem kann der relevante Unternehmensbereich vorgeben, welche Regeln anwendbar sind und wie (oder ob) eine bestimmte LPT-Regel in diesem Unternehmensbereich durchgesetzt werden sollte, z. B., ob eine Deployment-Pipeline blockiert oder ein Entwickler lediglich darauf hingewiesen werden soll, dass einige Aspekte nicht konform sind. Bei einer Ausführungsform kann das LPT-Tool die Ergebnisse verwenden, um die Konfiguration einer Deployment-Pipeline automatisch dahingehend zu verändern, dass diese eine oder mehrere der Regeln erfüllt. Natürlich können jedwede Änderungen ebenso an einen Entwickler oder Administrator weitergeleitet werden, bevor diese umgesetzt werden. Das LPT-Analyseverfahren kann in bestimmten Intervallen wiederholt werden, um jedwede Änderungen zu erkennen, die unter Umständen durch einen Techniker manuell vorgenommen wurden (d.h. Änderungen, die eine Meta-Pipeline umgehen, die verwendet wird, um eine kontinuierliche Deployment-Pipeline zu verwalten).
In anderen Fällen könnte das LPT-Tool eine Anwendungsdefinition aus einer Live-Pipeline-Vorlage erstellen und diese mit der „Ground-Truth“-Anwendungsdefinition vergleichen, die durch das LPT-Analyseverfahren erstellt wurde. Derartige Unterschiede könnten einem Entwickler als Vorschläge für eine Änderung der eigentlich bereitgestellten Pipeline vorgelegt werden, damit diese der in der Live-Pipeline-Vorlage vorgegebenen Konfiguration entspricht. Durch diesen Ansatz kann das LPT-Analyseverfahren die bereitgestellte Pipeline unter die Kontrolle des Quellcodes einer Live-Pipeline-Vorlage stellen. Das heißt, die eigentlich bereitgestellte Pipeline kann das Ziel einer Meta-Pipeline werden, nachdem beliebige Änderungen an der bereitgestellten Pipeline durchgeführt wurden, die auf der Grundlage von Unterschieden zwischen der Anwendungsdefinition der Live-Pipeline-Vorlage und der „Ground-Truth“-Anwendungsdefinition durchgeführt wurden. Zudem kann ein Vergleich der „Ground-Truth“-Anwendungsdefinition, die durch die LPT-Analyse erstellt wurde, mit verschiedenen Anwendungsdefinition, die auf der Grundlage eines Satzes LPT-Vorlagen erstellt wurden, verwendet werden, um einem Entwickler einen Vorschlag zu unterbreiten, welche LPT-Vorlage die höchste Kompatibilität mit einer eigentlichen Deployment-Pipeline aufweist.
Zudem kann das LPT-Analyseverfahren bei einer Ausführungsform verwendet werden, um dabei zu helfen, die besten Vorgehensweisen zu erkennen, die für eine Deployment-Pipeline verwendet werden sollten, die mit einem bestimmten Anwendungs- oder Diensttyp assoziiert ist. Beispielsweise kann ein Cloud-Computing-Anbieter, der Deployment-Pipelines für eine große Anzahl an Anwendungen oder Diensten verwaltet, das LPT-Analyseverfahren verwenden, um Muster oder häufig angewendete Praktiken in „Ground-Truth“-Anwendungsdefinitionen für eine Gruppe von Pipelines zu erkennen, denen ein Diensttypmuster gemein ist. Dadurch kann der Cloud-Computing-Anbieter Live-Pipeline-Vorlagen erstellen, die einen Satz bester Vorgehensweisen widerspiegeln, die im Laufe der Zeit in eine Sammlung von kontinuierlichen Deployment-Pipelines aufgenommen wurden.
Vorteilhafterweise kann ein Unternehmen durch Live-Pipeline-Vorlagen sicherstellen, dass betriebliche beste Vorgehensweisen in den Bereichen Verfügbarkeit, Sicherheit, Test, Performanz, Bereitstellung und Überwachung in kontinuierlichen Deployment-Pipelines eingehalten werden, die verwendet werden, um Anwendungen, Dienste und Upgrades in die Produktion zu übertragen. Zusätzlich können Live-Pipeline-Vorlagen die Durchsetzung und Validierung mit Tools kombinieren, um Anwendungen oder Dienste in Einklang mit besten Vorgehensweisen im Bereich der Bereitstellung zu bringen, Deployment-Pipelines für Anwendungen oder Dienste auf dem neusten Stand zu halten, wenn sich betriebliche Richtlinien oder beste Vorgehensweisen entwickeln, und Entwicklern dabei helfen, neue Dienste korrekt einzurichten. Dadurch können durch Mängel im Bereitstellungsverfahren verursachte Ausfallzeiten, die sich ohne Weiteres verhindern lassen, und die Zeit drastisch verringert werden, die Entwickler in den Bereichen betriebliche Einrichtung und Konfiguration aufwenden.
Es ist anzumerken, dass einige Ausführungsformen in der vorliegenden Schrift in Relation zu einem Beispiel eines Cloud-Computing-Anbieters beschrieben sind, der Live-Pipeline-Vorlagen verwendet, um eine Sammlung von Produktionsdiensten bereitzustellen und zu verwalten, die Unternehmenskunden angeboten werden. Ein Fachmann wird jedoch ohne Weiteres erkennen, dass unter Bezugnahme auf den Cloud-Computing-Anbieter beschriebene Ausführungsformen an ein Unternehmen angepasst oder diesem angeboten werden können, das die Dienste des Cloud-Anbieters verwendet, um eine Sammlung von Anwendungen oder Diensten zu warten, die durch den Cloud-Anbieter gehostet werden, sowie für Deployment-Pipelines angepasst werden können, die Anwendungen oder Dienste verwalten, die unter Verwendung der Recheninfrastruktur des Unternehmens Anwendungen oder Dienste verwalten.
1 veranschaulicht ein Beispiel einer Cloud-Computing-Umgebung mit mehreren Regionen, von denen jede eine regionale Instanz eines Produktionsrechendienstes hostet, die über eine kontinuierliche Deployment-Pipeline bereitgestellt wird, entsprechend einer Ausführungsform. Wie dargestellt, gehören zur Rechenumgebung 100 ein Client-Rechensystem 105 und drei Cloud-Computing-Regionen - Region A 120, Region B 130 und Region C 140, die mit öffentlichen Rechennetzen 150 verbunden sind (z. B. mit dem Internet). Der Begriff Client-System 105 steht für ein Universalrechensystem, wie etwa ein Desktop-Computer und Laptop-Computersysteme, sowie für mobile Rechenvorrichtungen, wie etwa Tablets und Smartphones, die mit Dienstkonsolenanwendungen oder Webbrowsersoftware konfiguriert sind.
Die Cloud-Computing-Regionen 120, 130 und 140 entsprechen im Allgemeinen einer durch einen Dienstleister im Rahmen des Anbietens von Webdiensten für Client-Systeme definierten Region (z. B. die Dienste, die verwendet wurden, um einen Produktionsdienst 125 zu erstellen). Entwickler können virtualisierte Rechenressourcen in jeder Cloud-Computing-Region 120, 130 und 140 bereitstellen, einführen und verwalten. Während Cloud-Computing-Regionen entlang willkürlicher Grenzen gezogen werden können, entsprechen Cloud-Computing-Regionen oftmals geografischen, nationalen oder Fehlertoleranzgrenzen, wobei Rechenressourcen in einer Region auf eine Art und Weise bereitgestellt und verwaltet werden, die allgemein von anderen Regionen isoliert ist. Insbesondere können die Cloud-Computing-Regionen 120, 130 und 140 jeweils einem Rechenzentrum (oder Rechenzentren) entsprechen, das (die) sich in einem bestimmten geografischen Bereich befindet (befinden). Rechenzentren in verschiedenen Regionen können bei der Bereitstellung fehlertoleranter Webdienste behilflich sein, z. B. sollte ein Rechenzentrum in einer Region nicht mehr verfügbar sein, können andere Rechenzentren in dieser Region (oder in anderen Regionen) weiter arbeiten, ohne die Webdienste selbst zu unterbrechen bzw. bei geringer Unterbrechung der Webdienste. Zudem kann der Anbieter mehrere physische oder logische Zonen in einer bestimmten Cloud-Computing-Region aktivieren. Beispielsweise kann ein einzelnes Rechenzentrum, das für die Bereitstellung einer Cloud-Computing-Region verwendet wird, mehrere, fehlertolerante Verfügbarkeitszonen bieten, wobei eine Unterbrechung eines Dienstes in einer Verfügbarkeitszone keinerlei Auswirkungen auf andere Verfügbarkeitszonen in derselben Cloud-Computing-Region (oder anderen Regionen) hat und die Verfügbarkeitszonen in einer Region eine kostengünstige Netzwerkkonnektivität mit niedriger Latenzzeit für andere Verfügbarkeitszonen in derselben Region bieten können.
In dem Beispiel aus 1 wird angenommen, dass ein Unternehmenskunde einen Produktionsdienst 125 in Region 120, einen Produktionsdienst 135 in Region 130 und einen Produktionsdienst 145 in Region 140 unter Verwendung der Cloud-Computing-Dienste bereitgestellt hat, die durch einen Cloud-Anbieter angeboten werden. Wie dargestellt, gehören zum 125 ein Satz Instanzen einer virtuellen Maschine (VM) 123, eine Datenbank 126 und ein dauerhafter Speicher 128. Zusätzlich gehört zum Produktionsdienst 125 ein Lastverteiler 124, der verwendet wird, um durch den Produktionsdienst 125 empfangene Anfragen auf eine Client-Anwendung 127 auf einer der Instanzen der VM 123 zu verteilen. Erneut Bezug nehmend auf das Beispiel einer Einzelhandelswebseite wird angenommen, dass die Client-Anwendung 127 auf jeder Instanz der VM 123 Web- und Anwendungsserver bereitstellt, die so konfiguriert sind, dass sie nach Bedarf auf die Datenbank 126 und den Speicher 128 zugreifen, um HTTP-Anfragen zu bearbeiten, die von Client-Browsern eingegangen sind. Wenn Anfragen empfangen werden, verteilt der Lastverteiler 124 die HTTP-Anfragen an die Anwendung 127 auf einer der Instanzen der VM 123. Wenn Benutzer Informationen abfragen und Produkte bestellen, kann die Anwendung 127 Daten im Zusammenhang mit Kundenanfragen oder Einkäufen lesen und in die Datenbank 126 und den Speicher 128 schreiben. Zudem könnte der Produktionsdienst 125 eine Vielzahl von anderen Rechendiensten umfassen, die durch den Cloud-Anbieter angeboten werden. Beispielsweise könnte die Anzahl der Instanzen der VM 123, die durch den Produktionsdienst 125 verwendet werden, auf der Grundlage der Nachfrage unter Verwendung eines automatischen Skalierungsdienstes erhöht oder verringert werden. Gleichermaßen könnte ein Cloud-Überwachungsdienst die Gesundheit der Instanzen der VM 123 überwachen und Leistungsmetriken im Zusammenhang mit dem Produktionsdienst 125 sammeln. Wenngleich nicht mit derselben Detailliertheit dargestellt, könnten der Produktionsdienst 135 in Region 130 und der Produktionsdienst 145 in Region 140 eine bereitgestellte Konfiguration aufweisen, die der Konfiguration von Produktionsdienst 125 in Region 120 entspricht.
Wie dargestellt, weisen die Produktionsdienste 125, 135 und 145 jeweils ein entsprechendes Pipeline-Bereitstellungsprogramm 129, 139 und 149 auf. Das Pipeline-Bereitstellungsprogramm 129 umfasst im Allgemeinen Softwareanwendungen, die verwendet werden, um die Bereitstellung von Software (z. B. Anwendung 127) für den Produktionsdienst 125 zu automatisieren. Die Pipeline-Bereitstellungsprogramme 139 und 149 bieten im Allgemeinen dieselbe Funktion für die Produktionsdienste 135 bzw. 145. Insbesondere können die Pipeline-Bereitstellungsprogramme 129, 139 und 149 so konfiguriert sein, dass sie Software, damit zusammenhängende Skripte, Artefakte oder Konfigurationszustände usw. kontinuierlich in den Produktionsdienst 125, 135 und 145 integrieren. Beispielsweise kann das Pipeline-Bereitstellungsprogramm 129 ausführbare Programme der Anwendung 127 aus einem Quellcodearchiv erstellen, automatisierte Testfolgen auf den ausführbaren Programmen ausführen, um Fehler oder Konflikte zu ermitteln. Unter der Annahme, dass das automatische Testen erfolgreich ist, kann das Pipeline-Bereitstellungsprogramm 129 damit beginnen, die ausführbaren Programme in immer breiter gefasste Produktionsumgebungen zu übertragen. Auf jeder Stufe kann das Pipeline-Bereitstellungsprogramm 129 den Produktionsdienst 125 überwachen, um sicherzustellen, dass die bereitgestellte Software weiterhin korrekt oder innerhalb jedweder Grenzen für Leistungsmetriken im gesamten Bereitstellungsverfahren funktioniert.
Das Pipeline-Bereitstellungsprogramm 129 kann den Produktionsdienst 127 gegen Ausfallzeiten während der Bereitstellung schützen, indem es Updates auf die Anwendung 127 auf Instanzen der VM 123 in Stufen ausrollt und bei jeder Stufe eine Überprüfung auf Fehler oder Konflikte durchführt. Wenn Fehler oder unerwartete Konflikte oder Integrationsprobleme auftreten, während die Software auf den Produktionsdienst 125 übertragen wird, kann das Pipeline-Bereitstellungsprogramm 129 die Anwendung 127 auf beliebige aktualisierte Instanzen der VM auf eine vorherige Version zurückrollen und den Entwicklern Protokolle und Daten im Zusammenhang mit einer unterbrochenen Bereitstellung liefern.
Wie angemerkt, kann eine Deployment-Pipeline einen Satz Stufen umfassen, der verwendet wird, um Software und damit verbundene Artefakte zu erstellen, zu testen und diese in den Produktionsdiensten 125, 135 und 145 freizugeben. Beispielsweise kann die Deployment-Pipeline, die durch die Pipeline-Bereitstellungsprogramme 129, 139 und 149 verwendet wird, Teststufen vor der Produktion umfassen, wie etwa eine alpha- oder Integrationsteststufe und eine beta-Teststufe, in der die Anwendung unter Verwendung automatisierter Tests überprüft wird. Sobald die Stufen vor der Produktion erfolgreich abgeschlossen sind, kann ein gamma- oder Bereitstellungsintegrationstest durchgeführt werden, bei dem die Anwendung in einer Produktionsumgebung bereitgestellt ist, jedoch vor dem Übergang zu Bereitstellungsstufen, in denen eigentlicher Kundenverkehr oder eigentliche Kundendaten verarbeitet werden. Im Anschluss an den gamma-Test können Stufen, in denen der Kundenverkehr erfasst wird, eine One-Box-Stufe umfassen, um eine einzelne Produktionsinstanz einer Anwendung zu testen (z. B. durch Aktualisieren der Anwendung 127 auf einer einzelnen Instanz der VM 123). Nach einem durch die Deployment-Pipeline für den One-Box-Test vorgegebenen Zeitraum kann das Pipeline-Bereitstellungsprogramm 129 die Anwendung vollständig für den Produktionsdienst 125 bereitstellen. Die Deployment-Pipeline kann Zurückrollüberwachungseinheiten für jede Bereitstellungsstufe umfassen, sowie Alarme für Dienstmetriken, wie etwa Alarme für VIP-Metriken oder JMX-Metriken. Derartige Alarme können verwendet werden, um eine Bereitstellung automatisch zu erkennen (und zurückzurollen), die darauf hindeutet, dass sie den Produktionsdienst 125 unterbricht. Eine Deployment-Pipeline für die Produktionsdienste 135 und 145 kann ähnliche Test- und Bereitstellungsstufen umfassen, um Software kontinuierlich für die Produktion bereitzustellen.
Die Konfiguration einer Deployment-Pipeline kann erheblichen Einfluss darauf haben, wie erfolgreich Softwareupdates getestet und in der Produktion verwendet (oder blockiert oder nach einer fehlgeschlagenen Bereitstellungsstufe zurückgerollt) werden können. Zudem können, wie vorstehend erwähnt, das Erstellen und Konfigurieren einer Deployment-Pipeline einen erheblichen Zeitaufwand auf Seiten der Entwickler erfordern. Um diese (und andere) Probleme anzugehen, können bei einer Ausführungsform die Deployment-Pipelines 142 selbst unter Verwendung eines Tools für eine Live-Pipeline-Vorlage (LPT) 155 erstellt und bereitgestellt werden. Der Einfachheit halber ist das LPT-Tool 155 in der Region 140 dargestellt. Die Regionen 120 und 130 können jedoch auch eine Instanz des LPT-Tools 155 enthalten.
Bei einer Ausführungsform stellt die Live-Pipeline-Vorlage 109 Quellcode bereit, der im Allgemeinen eine Deployment-Pipeline für einen bestimmten Anwendungs- oder Diensttyp definiert. Während die verwendete Programmiersprache aufgrund einer Präferenz vorgegeben sein kann, kann eine beliebige Sprache verwendet werden, die im Allgemeinen objektorientierte Klassen und Vererbung unterstützt. Wie dargestellt, gehört zum Client-System 105 eine integrierte Entwicklungsumgebung (IDE) 107, die verwendet werden kann, um eine dienstspezifische Instanz einer Live-Pipeline-Vorlage 109 zu erstellen, d.h. um eine LPT-Instanz 103 zu erstellen, die den Quellcode der Live-Pipeline-Vorlage 109 erbt. Beispielsweise kann die Live-Pipeline-Vorlage 109 eine grundlegende Klasse definieren, die einen bestimmten Produktionsdiensttyp modelliert, wie etwa einen Ablaufdienst, einen Anfrageantwortdienst usw. Ein Entwickler kann die Live-Pipeline-Vorlage 109 dahingehend konkretisieren, dass eine LPT-Instanz 103 dadurch erzeugt wird, dass instanzspezifische Details für einen Produktionsdienst vorgegeben werden, der unter Verwendung einer Deployment-Pipeline bereitgestellt werden soll, die der LPT-Instanz 103 der Live-Pipeline-Vorlage 109 entspricht. Nachdem die instanzspezifischen Einzelheiten vorgegeben wurden, kann der Quellcode der LPT-Instanz 103 zusammengestellt und ausgeführt werden (oder interpretiert), um eine genaue Konfiguration für eine Deployment-Pipeline zu erstellen, zu der der Dienst oder instanzspezifische Einzelheiten des Produktionsdienstes gehören, die durch die LPT-Instanz 103 vorgegeben sind, zusammen mit allen besten Vorgehensweisen, Sicherheitsmechanismen, Bereitstellungsstufen usw. in der Live-Pipeline-Vorlage 109, die nicht ausdrücklich durch den Entwickler vorgegeben waren.
Bei einer Ausführungsform ist das LPT-Tool 155 so konfiguriert, dass es die Deployment-Pipelines 142 erstellt, aktualisiert und analysiert. Hierfür kann der LPT-Dienst 155 die LPT-Instanz 103 verwenden, um eine vollständige (und korrekte) Konfiguration für eine Deployment-Pipeline zu erstellen, die der LPT-Instanz 103 entspricht. Zudem können die Pipeline-Bereitstellungsprogramme 129, 139 und 149 die resultierende Deployment-Pipeline 142 verwenden, um Deployment-Pipelines in den Cloud-Computing-Regionen 120, 130, 140 zu erstellen und zu konfigurieren.
Zudem kann bei einer Ausführungsform das LPT-Tool 155 so konfiguriert sein, dass es Änderungen an einer Deployment-Pipeline verbreitet, die unter Verwendung einer Meta-Pipeline aus der LPT-Instanz 103 erstellt wurde. Das heißt, genauso wie die Deployment-Pipelines verwendet werden können, um Änderungen für die Produktionsdienste 125, 135 und 145 bereitzustellen, kann eine Meta-Pipeline verwendet werden, um Änderungen an den Deployment-Pipelines auf der Grundlage von Änderungen an der Live-Pipeline-Vorlage 109 oder der LPT-Instanz 103 zu verbreiten. Beispielsweise können Entwickler die Inhalte der Live-Pipeline-Vorlage 109 dahingehend ändern, dass diese Änderungen an den besten Vorgehensweisen zum Bereitstellen eines bestimmten Diensttyps widerspiegeln, wenn sich derartige Vorgehensweisen entwickeln oder ändern. Beispielsweise könnte die Live-Pipeline-Vorlage 109 so aktualisiert werden, dass sie eine Konfiguration für neue Dienste enthält, die von einem Cloud-Anbieter angeboten werden, durch die sich eine Deployment-Pipeline verbessern ließe, die unter Verwendung der Live-Pipeline-Vorlage 109 erstellt wurde. Gleichermaßen könnte, wenn sich die besten Vorgehensweisen für einen bestimmten Diensttyp in einem Unternehmen ändern, die Live-Pipeline-Vorlage 109 dahingehend aktualisiert werden, dass sie die sich ändernden Anforderungen des Unternehmens widerspiegelt. Beispielsweise könnten Änderungen an den dienstspezifischen Informationen (d.h. an der LPT-Instanz 103) ebenfalls unter Verwendung der Meta-Pipeline auf eine Deployment-Pipeline verbreitet werden. Beispielsweise könnte ein Entwickler ändern, welche Regionen das LPT-Tool 155 erstellt und in welchen davon es eine Deployment-Pipeline konfiguriert, indem der Quellcode der LPT-Instanz 103 aktualisiert wird oder administrative Kontakte geändert oder andere Aspekte der Grundkonfiguration so überschrieben werden, dass der Bedarf für einen bestimmten Fall gedeckt ist. In jedem dieser Beispiele können vorgeschlagene Änderungen an einer Deployment-Pipeline durch Fachleute überprüft werden, bevor diese in den Quellcode der Live-Pipeline-Vorlage 109 oder LPT-Instanz 103 aufgenommen und durch die Meta-Pipeline kontrolliert der Pipeline bereitgestellt werden.
2 veranschaulicht ein Beispiel für eine Meta-Pipeline 210, die verwendet wird, um eine kontinuierliche Deployment-Pipeline 230 für einen Produktionsrechendienst 240 entsprechend einer Ausführungsform zu erstellen, zu konfigurieren und zu aktualisieren. Wie dargestellt, gehört zur Meta-Pipeline 210 eine Version eines LPT-Pakets 212 und eine Version einer LPT-Instanz 214, die vom LPT-Paket 212 erbt. Die Meta-Pipeline umfasst zudem eine Erstellungsstufe 216 und eine Teststufe 218. Das LPT-Paket 212 und die LPT-Instanz 214 entsprechen im Allgemeinen spezifischen Revisionen einer Live-Pipeline-Vorlage , die im LPT-Archiv 207 gespeichert ist, zusammen mit jedweden damit verbundenen Artefakten oder Dateien, die erforderlich sind, um die Live-Pipeline-Vorlage zu erstellen und auszuführen, z. B. Dateien, die einen Erstellungsprozess beschreiben, und jedwede Abhängigkeiten, die erforderlich sind, um ein Anwendungsziel auf der Grundlage der LPT-Instanz 214 zu erstellen.
Das Versionierungssystem 205 wird verwendet, um Revisionen des Quellcodes der Live-Pipeline-Vorlage 206 zu verwalten, die im LPT-Archiv 207 gespeichert ist. Durch das Versionierungssystem 205 kann ein Unternehmen verwalten und steuern, wie Änderungen am Quellcode der Live-Pipeline-Vorlage 206 (und der Instanzen dieser Live-Pipeline-Vorlage) über die Meta-Pipeline 210 bereitgestellt werden. Das heißt das Versionierungssystem 205 stellt die Konfiguration der Deployment-Pipeline 230 unter die Kontrolle des Quellcodes. In der Regel kann ein leitender Entwickler oder Techniker verantwortlich sein, Änderungen am Quellcode der Live-Pipeline-Vorlage 206 (und Instanzen dieser Live-Pipeline-Vorlage) zu empfangen und freizugeben. Dadurch wird sichergestellt, dass die Deployment-Pipeline 230 die besten Vorgehensweisen und Anforderungen eines Unternehmens widerspiegelt, das die Bereitstellung 230 verwendet, um den Produktionsdienst 240 bereitzustellen.
Wie durch einen Pfeil 2220 dargestellt, kann die Ausgabe oder das Ziel der Meta-Pipeline 210 eine Anwendungsdefinition sein. Wenn das LPT-Paket 212 und die LPT-Instanz 214 beispielsweise zunächst dem Versionierungssystem 205 übergeben werden (d.h. sobald Version 1.0.0 verfügbar ist), kann die Meta-Pipeline 210 verwendet werden, um die Anwendungsdefinition 215 zu erstellen. Bei einer Ausführungsform kann die Anwendungsdefinition 215 ein umfassendes Modell vorgeben, das eine Konfiguration einer Deployment-Pipeline 230 vollständig vorgibt, die verwendet wird, um den Produktionsdienst 240 zu erstellen und bereitzustellen. Die Anwendungsdefinition 215 kann unter Verwendung eines maschinenlesbaren Austauschformates vorgegeben sein, z. B. als JSON- oder XML-Dokument. Das LPT-Tool 155 kann wiederum die erste Instanz der Deployment-Pipeline 230 konfigurieren, bereitstellen und erstellen.
Während einer Erstellungsstufe 216 werden das LPT-Paket 212 und die LPT-Instanz 214 zusammengestellt, um Software zu erzeugen, die die Anwendungsdefinition 215 erstellen kann. Beispielsweise kann zum LPT-Paket 212 und zur LPT-Instanz 214 ein Softwarepaket gehören, das unter Verwendung des hinlänglich bekannten Ant-Erstellungstools erstellt worden sein kann. Direkt nach der Erstellung kann das resultierende Softwarepaket ausgeführt (oder interpretiert) werden, um die Anwendungsdefinition 215 zu erstellen. Erläuternd gehört zur Meta-Pipeline 210 eine Teststufe 218, die verwendet wird, um die Ergebnisse der Erstellungsstufe 216 zu bewerten (d.h. die Anwendungsdefinition 215). Beispielsweise kann die Teststufe 218 die Anwendungsdefinition 215 gegen einen Regelsatz bewerten, der Mindestanforderungen für eine Deployment-Pipeline vorgibt. Dies könnte dabei helfen, sicherzustellen, dass ein Entwickler kein Element des LPT-Pakets 212 in der LPT-Instanz 214 so überschreibt, dass dies zu einer unvollständigen oder nicht funktionsfähigen Deployment-Pipeline 230 oder zu einer Deployment-Pipeline 230 führt, die bestimmte Mindeststandards oder -anforderungen nicht einhält, die durch ein Unternehmen vorgegeben sind.
Direkt nach dem Erstellen (während der Erstellungsstufe 216) und Testen (während der Teststufe 218) kann die resultierende Anwendungsdefinition 215 dem LPT-Tool 155 bereitgestellt werden. Wie durch einen Pfeil 250 dargestellt, kann das LPT-Tool 155 die Deployment-Pipeline 230 entsprechend den Vorgaben in der Anwendungsdefinition 215 erstellen und konfigurieren. In dem Beispiel in 2 gehören zur Deployment-Pipeline 230 eine Erstellungsstufe 234, Vorproduktionsstufen 236 und Produktionsstufen 238. Bei einer Ausführungsform zum Erstellen der Deployment-Pipeline 230 kann das LPT-Tool 155 einen Satz Blattsystemtreiber aufrufen, die verwendet werden, um einen entsprechenden Satz Blattsysteme zu konfigurieren, die der Deployment-Pipeline 230 zugrunde liegen. Das heißt die Blattsystemtreiber werden verwendet, um die darunterliegenden Systeme, Anwendungen oder Dienste zu konfigurieren, die gemeinsam die Deployment-Pipeline 230 ausmachen. Beispielsweise können die Blattsystemtreiber ein Bereitstellungssystem konfigurieren, das so konfiguriert ist, dass es die Vorproduktionsstufen 236 und die Produktionsstufen 238 verwaltet, Hostklassen von Instanzen der VM erstellt, virtuelle Netzwerkadressen und Routing zwischen Rechenressourcen konfiguriert, Instanzen der VM oder andere virtuelle Rechenressourcen konfiguriert und bereitstellt, Überwachungsalarme, Zurückrollgrenzen für die Bereitstellung, Leistungsüberwachungseinheiten usw. einrichtet, und zwar nach Bedarf, um die Deployment-Pipeline 230 einzurichten.
Bei einer Ausführungsform kann die Meta-Pipeline 210 im Anschluss an die erste Einführung der Deployment-Pipeline 230 Änderungen an der Live-Pipeline-Vorlage 206 in die Produktion verbreiten, wenn Änderungen an der Live-Pipeline-Vorlage 206 über das Versionierungssystem 205 übertragen werden. Das heißt die Meta-Pipeline 210 kann verwendet werden, um Änderungen an der Live-Pipeline-Vorlage 206, die in veröffentlichten Versionen des LPT-Pakets 212 und der LPT-Instanz 214 enthalten sind, auf die Deployment-Pipeline 230 zu verbreiten. Bei einer Ausführungsform kann die Meta-Pipeline 210 neue Versionen des LPT-Pakets 212 oder der LPT-Instanz 214 automatisch in die Produktion in der Deployment-Pipeline 230 verbreiten, wenn neue Versionen durch das Versionierungssystem 205 übertragen und veröffentlicht werden. Natürlich kann die Meta-Pipeline 210 auf Anfrage aufgerufen werden, um neue Versionen einer Live-Pipeline-Vorlage 206 auf die Deployment-Pipeline 230 zu übertragen.
Sobald das LPT-Tool 155 die anfängliche Bereitstellung und Konfiguration der Deployment-Pipeline 230 abgeschlossen hat, kann die Deployment-Pipeline 230 verwendet werden, um die Softwareanwendungen und Systeme bereitzustellen (und zu aktualisieren), die den Produktionsdienst 240 bereitstellen. Das Quellcodearchiv 227 kann den Quellcode des Produktionsdienstes speichern, wobei auch die damit verbundene Konfiguration, die damit verbundenen Daten und andere Artefakte im Quellcodearchiv 227 gespeichert werden können. Änderungen am Quellcode des Produktionsdienstes 240 können dem Versionierungssystem 225 unterliegen, in dem Änderungen zuerst überprüft werden, bevor diese übertragen werden. Wenn Änderungen am Quellcode des Produktionsdienstes 240 übertragen werden, was zu einem neuen Erstellungspaket des Quellcodes 232 führt, kann die Deployment-Pipeline 230 den Produktionsdienst 240 über die Deployment-Pipeline 230 aktualisieren.
Wie dargestellt, gehört zur Deployment-Pipeline 230 beispielsweise eine Erstellungsstufe 234, die Quellcode 232 zusammenstellt, um mögliche ausführbare Programme zur Bereitstellung zu erstellen. In diesem Beispiel werden die im Rahmen der Erstellungsstufe 234 erzeugten ausführbaren Programme zuerst in Vorproduktionsstufen 236 geleitet und, wenn die ausführbaren Programme die in dieser Stufe durchgeführten Tests bestehen, werden sie anschließend in die Produktionsstufen 238 geleitet. Während der Vorproduktionsstufen 236 werden die ausführbaren Programme unter Verwendung von Integrationstests, Testfolgen und Probedaten usw. getestet, bevor sie zum Verarbeiten von Kundenverkehr verwendet werden. Während der Produktionsstufen 238 können die ausführbaren Programme in eine immer breitere Produktionsverwendung übertragen werden, bis die Bereitstellung der aktualisierten Anwendung im Produktionsdienst 240 abgeschlossen ist. Beispielsweise kann das Testen in der Produktionsstufe einen gamma-Integrationsstufentest, einen One-Box-Test und abschließend eine vollständige Bereitstellung in der Produktion umfassen. Ebenfalls während der Produktionsstufen 238 können Leistungsüberwachungseinheiten und Alarme die Leistung der ausführbaren Programme überwachen, wie diese in der Produktionsumgebung bereitgestellt sind. Wenn die ausführbaren Programme mit einer Rate durchfallen, die eine Alarmgrenze überschreitet, oder anderweitig durch eine schlechte Leistung einen Alarm auslösen, kann die Deployment-Pipeline 230 die Bereitstellung zurückrollen. Zusätzlich kann die Deployment-Pipeline 230 Protokolle und damit verbundene Daten erstellen, die einem Entwicklungsteam dabei helfen können, zu verstehen, was dazu geführt hat, dass die Bereitstellung zurückgerollt wurde.
3 veranschaulicht Komponenten einer Instanz einer Live-Pipeline-Vorlage (LPT) 300, die Deployment-Pipeline-Konfigurationsdaten von anderen Pipeline-Vorlagen erbt, entsprechend einer Ausführungsform. Wie dargestellt, gehört zur LPT-Instanz 300 eine Vererbungshierarchie von Deployment-Pipeline-Vorlagen, wobei jede Vorlage in der Hierarchie von anderen Pipeline-Vorlagen in der Hierarchie geerbte Aspekte überschreiben und zusätzliche Konfigurationsdaten zur LPT-Instanz 300 hinzufügen kann. In diesem konkreten Beispiel gehören zur LPT-Instanz 300 eine Basisvorlage 305 des Unternehmens, eine Diensttypvorlage 310, eine teamspezifische Vorlage 315 und eine dienstspezifische Vorlage 320. Natürlich wird ein Fachmann erkennen, dass die Anzahl an Vorlagen, das Vererbungsmuster zwischen Vorlagen oder welche Informationen in jeder Vorlage gespeichert sind so maßgeschneidert sein können, wie es für eine bestimmte Deployment-Pipeline oder für bestimmte Vorgehensweise im Unternehmen erforderlich ist
Bei einer Ausführungsform kann die Basisvorlage 305 des Unternehmen verwendet werden, um einen Satz bester Vorgehensweisen oder Anforderungen für eine kontinuierliche Deployment-Pipeline einzukapseln, die durch alle Deployment-Pipelines eingehalten werden sollten, die in einem bestimmten Unternehmen verwendet werden. Betrachten wir beispielsweise einen Cloud-Dienstleister, der Kunden Rechen-, Datenbank-, Speicher-, Netzwerk- und Überwachungsdienste usw. anbietet. Trotz der verschiedenen Diensttypen können auf jeden Rechendienst, der durch den Cloud-Anbieter angeboten wird, einige Bereitstellungspraktiken anwendbar sein. Beispielsweise kann ein Unternehmen fordern, dass eine beliebige Deployment-Pipeline, die verwendet wird, um die Software zu aktualisieren, die diesen Rechendiensten zugrunde liegt, einem Integrationstest unterzogen werden sollte, bevor diese mit Kundenverkehr verwendet wird, und zunächst unter Anwendung einer One-Box-Stufe in der Produktion mit Kundenverkehr bereitgestellt werden sollte. In einem derartigen Fall könnten diese Anforderungen im Quellcode der Basisvorlage 305 des Unternehmens festgehalten sein.
Wie dargestellt, erbt die Diensttypvorlage 310 die in der Basisvorlage 305 des Unternehmens vorgegebene Deployment-Pipeline-Konfiguration. Die Diensttypvorlage 310 könnte verwendet werden, um beispielsweise Deployment-Pipeline-Anforderungen vorzugeben, die einen bestimmten Diensttyp kennzeichnen. Fortfahrend mit dem Beispiel eines Cloud-Dienste-Anbieters könnten zur Diensttypvorlage 310 Konfigurationsdaten gehören, die einen bestimmten der den Kunden angebotenen Dienste kennzeichnet. Beispielsweise könnte eine Deployment-Pipeline, die verwendet wird, um die Software und die Systeme zu aktualisieren, die einen virtualisierten Datenbankdienst anbieten, eine spezifische Sammlung von beta-Tests umfassen, die verwendet werden, um die Latenzzeit von Anfragen zu testen, die verwendet werden, um Daten von einer Testinstanz einer Datenbank zu lesen/darauf zu schreiben, die unter Verwendung des Dienstes bereitgestellt wird. Gleichermaßen könnten zu einer Deployment-Pipeline für einen Rechendienst Teststufen gehören, die verschiedene Instanzen der VM einführen, entsprechend jedes Instanzkonfigurationstyps, der durch den Anbieter angeboten wird, und die Instanzen der VM auf Korrektheit prüfen. Allgemeiner ausgedrückt, kann jeder Rechendienst, der durch den Cloud-Computing-Anbieter angeboten wird, einen eignen Satz Bereitstellungsanforderungen aufweisen, die in der entsprechenden Diensttypvorlage 310 eingekapselt sind. Zusätzlich zum Vorgeben zusätzlicher Konfigurationsparameter für eine Deployment-Pipeline kann die Diensttypvorlage 310 beliebige der Anforderungen überschreiben oder erweitern, die in der Basisvorlage 305 des Unternehmens vorgegeben sind. In der Regel umfasst die Basisvorlage 305 jedoch beste Vorgehensweisen oder Anforderungen des Unternehmens, die in jeder Deployment-Pipeline enthalten sein sollten, die in einem bestimmten Unternehmen verwendet wird, und die beim Erstellen von Unterklassen für die Basisvorlage 305 des Unternehmens nicht überschrieben werden dürfen.
Die teamspezifische Vorlage 315 erbt sowohl von der Basisvorlage 305 des Unternehmens als auch von der Diensttypvorlage 310 und kann Aspekte der Basisvorlage 305 des Unternehmens oder der Diensttypvorlage 310 erweitern oder überschreiben. Die teamspezifische Vorlage 315 kann Konfigurationsdaten enthalten, die von einem Entwicklungsteam verwendet werden, das für die Verwaltung eines bestimmten Dienstes verantwortlich ist. Unter erneuter Bezugnahme auf das Beispiel des Cloud-Computing-Anbieters, der Rechendienste für Unternehmenskunden anbietet, kann die teamspezifische Vorlage 315 die Diensttypvorlage 310 dahingehend erweitern, dass diese Informationen über ein Entwicklungsteam enthält, das einen Produktionsdienst verwaltet, der über eine auf der Grundlage der LPT-Instanz 300 erstellte Deployment-Pipeline bereitgestellt wird. Beispielsweise kann das Entwicklungsteam die Diensttypvorlage 310 verwenden, um Informationen über das Team in die Live-Pipeline-Vorlage 300, wie etwa Ausführungsbenutzernamen, Zugriffskontrollrechte usw., für die Blattsysteme aufzunehmen, die als Teil einer kontinuierlichen Deployment-Pipeline enthalten sind, wie durch die Basisvorlage 305 des Unternehmens und die Diensttypvorlage 310 vorgegeben.
Zuletzt erbt die Vorlageninstanz 320 der LPT-Instanz 300 die Konfiguration einer Deployment-Pipeline, die in der Basisvorlage 305 des Unternehmens, der Diensttypbasisvorlage 310 und der teamspezifischen Vorlage 315 vorgegeben ist. Bei einer Ausführungsform erweitert die Vorlageninstanz 320 diese Vorlagen (oder überschreibt Verfahren in diesen Vorlagen) mit dienst- oder instanzspezifischen Parametern im Zusammenhang mit einer spezifisch Instanz einer Deployment-Pipeline, die zum Bereitstellen eines Produktionsdienstes verwendet wird. Die Vorlageninstanz 320 kann die anderen Vorlagen um dienstspezifische Informationen erweitern, wie etwa ein Dienstname, (ein) administrative(r) Kontakt(e), und wo eine Deployment-Pipeline, die auf Grundlage der Live-Pipeline-Vorlage 300 erstellt wurde, bereitgestellt werden soll, z. B. einer vorgegebenen Liste mit Cloud-Computing-Regionen, die durch einen Cloud-Dienste-Anbieter angeboten werden.
Beispielsweise veranschaulicht 4 Quellcode für ein Beispiel der Vorlageninstanz 320 der in 3 veranschaulichten LPT-Instanz 300, entsprechend einer Ausführungsform. In diesem Beispiel gehört zum Quellcode ein Ruby-Modul 400, das in der Ruby-Programmiersprache geschrieben ist.
Wie an den Linien 1-4 dargestellt, erweitert das Ruby-Modul 400 eine Diensttypvorlage 310 für eine Deployment-Pipeline um einen Diensttyp eines „Anfrageantwortdienstes“. Insbesondere erklärt Linie 4 eine Klasse namens „TemplateInstance“ zu einer Unterklasse einer anderen Pipeline-Vorlagenklasse namens „Lpt::Templates::RequestReplyService“. Die Linien 06-29 des Ruby-Moduls 400 geben Verfahren vor, die Verfahren der Diensttypvorlage 310 mit Dienst- oder Instanzinformationen für eine Instanz einer Deployment-Pipeline überschreiben, die auf der Grundlage der LPT-Instanz 300 erstellt wurde.
Zunächst erklären die Linien 06-08 ein Ruby-Verfahren namens „pipeline_name“ und definieren einen Namen für eine Bereitstellungsinstanz einer Produktions-Pipeline. Die Linien 10-13 erklären ein Ruby-Verfahren namens „pipeline_description“ und bieten eine Textbeschreibung für diese spezifische Instanz einer Live-Pipeline-Vorlage. In diesem Beispiel gibt die Beschreibung an, dass die definierte Deployment-Pipeline verwendet wird, um einen Anfrageantwortdienst bereitzustellen, der selbst verwendet wird, um einen regionalen Anfrage-/Antwortdienst bereitzustellen, der anfragenden Clients IP-Adressen zur Verfügung stellen kann.
Die Linien 15-17 des Ruby-Moduls 400 erklären ein Ruby-Verfahren namens „pipeline_notification_email_address“ und geben eine E-Mail-Adresse für eine Deployment-Pipeline vor, die auf der Grundlage der LPT-Instanz 300 erstellt wurde. Eine derartige E-Mail-Adresse könnte verwendet werden, um Meldungen über die Deployment-Pipeline an Mitglieder eines Entwicklungsteams zu senden. Beispielsweise könnte die Deployment-Pipeline automatisch E-Mail-Nachrichten über den Erfolg (oder Misserfolg) jeder Teststufe in der Deployment-Pipeline an das Entwicklungsteam senden, das für das Erstellen und Verwalten des bestimmten Dienstes verantwortlich ist, der unter Verwendung der Deployment-Pipeline bereitgestellt wird.
Die Linien 19-21 erklären ein Ruby-Verfahren namens „dimensionality“, das verwendet wird, um eine logische Bereitstellungseinheit für die Deployment-Pipeline vorzugeben. In diesem Fall liegt die Dimensionalität für die Pipeline auf der Ebene einer Cloud-Computing-Region, d.h. auf der Ebene unterschiedlicher geographischer Regionen, in denen der Cloud-Computing-Anbieter Dienste anbietet. In anderen Fällen könnte eine Deployment-Pipeline erstellt werden, um Software in einzelnen Verfügbarkeitszonen in einer Cloud-Computing-Region, in einem privaten Unternehmensnetzwerk oder in anderen logischen oder physischen Zonen bereitzustellen, in denen Rechendienste bereitgestellt werden können. Damit verbunden erklären die Linien 23-25 ein Ruby-Verfahren namens „blacklisted_dimensionality“, das einen Satz Regionen vorgibt, in denen eine Deployment-Pipeline, die der LPT-Instanz 300 entspricht, nicht bereitgestellt werden sollte. In diesem Beispiel gehören zu den Regionen auf der schwarzen Liste Cloud-Computing-Regionen in Europa und Asien, wodurch der Produktionsdienst in Rechenzentren für Regionen in den USA oder Nord- und Südamerika bereitgestellt werden muss. Wie nachstehend beschrieben, kann durch das Vorgeben einer „schwarzen Liste“ mit Cloud-Computing-Regionen, in denen eine Deployment-Pipeline nicht konfiguriert werden sollte, diese Deployment-Pipeline automatisch für neue Rechenregionen bereitgestellt werden, die verfügbar werden (vorausgesetzt, dass jedwede Dienstabhängigkeiten der Deployment-Pipeline in einer neuen Rechenregion ebenfalls befriedigt sind). Natürlich könnte ein anderes im Ruby-Modul 400 erklärtes Verfahren eine Positivliste vorgeben, wo die Deployment-Pipeline bereitgestellt werden sollte. Die Linien 27-29 des Ruby-Moduls 400 erklären ein Ruby-Verfahren namens „deployment-service_run_as_user“. Dieses Verfahren gibt einen Benutzernamen für einen Bereitstellungsdienst vor, auf den ein Blattsystemtreiber bei der Bereitstellung und Konfiguration der Teststufen (oder anderer Elemente) einer Deployment-Pipeline zugreift, die auf der Grundlage der LPT-Instanz 300 erstellt wurde.
Zuletzt gehört zu den Linien 31-36 eine Bemerkung, die angibt, dass die Vorlageninstanz 320, die durch das Ruby-Modul 400 dargestellt ist, den Vorlageninhalt von den hochrangigeren Vorlagen erbt, d.h. von der Basisvorlage 305 des Unternehmens, von der Diensttypbasisvorlage 310 und von der teamspezifischen Vorlage 315 in diesem Beispiel. Wie durch das Ruby-Modul 400 veranschaulicht, erlaubt das Einteilen von Unterklassen auf der Grundlage von hochrangigeren Vorlagen (d.h. von der Vorlage „RequestReplyService“ in diesem Fall) einem Entwickler das Erstellen einer Instanz einer Live-Pipeline-Vorlage (z. B. LPT-Instanz 300), die verwendet wird, um eine Deployment-Pipeline zu erstellen, durch Vorgeben einer geringen Menge an Informationen über den bestimmten Dienst oder die bestimmte Anwendung im Quellcode der Vorlageninstanz 320 - unter den Linien 30 des Ruby-Quellcodes in diesem Beispiel. Der Entwickler kann dann die Live-Pipeline-Vorlage instanziieren und ausführen, um eine Deployment-Pipeline zu erstellen, ohne die besten Vorgehensweisen, Sicherheitsmechanismen, Bereitstellungsstufen usw. direkt vorgeben zu müssen, die erforderlich sind, um eine Deployment-Pipeline zu erstellen.
5 ist ein konzeptionelles Diagramm, das den Datenfluss für ein Syntheseverfahren einer Live-Pipeline-Vorlage veranschaulicht, die verwendet wird, um eine Deployment-Pipeline zu instanziieren, entsprechend einer Ausführungsform. Wie dargestellt, wird eine LPT-Instanz 500 erstellt und ausgeführt, um eine Anwendungsdefinition 510 zu erstellen. Das LPT-Tool 555 wiederum verwendet die Anwendungsdefinition 510 zum Bereitstellen und Konfigurieren der Deployment-Pipeline 530 entsprechend der Anwendungsdefinition 510. Das heißt, während dem LPT-Syntheseverfahren stellt das LPT-Tool 555 die Dienste und Systeme bereit, konfiguriert diese, führt diese ein oder bereitet diese anderweitig vor, die erforderlich sind, um die Deployment-Pipeline 530 in einen Zustand zu bringen, in dem die Deployment-Pipeline 530 damit beginnen kann, eine Produktionsanwendung bereitzustellen.
In diesem konkreten Beispiel gehört zur LPT-Instanz 500 eine Hierarchie von drei Pipeline-Vorlagen - eine Pipeline-Vorlage 505 des Unternehmens, eine Diensttypvorlage 507 und eine Vorlageninstanz 509. Wie vorstehend erwähnt, kann die Pipeline-Vorlage 505 des Unternehmens einen grundlegenden Satz von besten Vorgehensweisen und Anforderungen für eine Deployment-Pipeline erfassen, die auf einer Unternehmensebene vorgegeben sind. Und die Diensttypvorlage 507 kann die Pipeline-Vorlage 505 des Unternehmens um Anforderungen und Konfigurationsinformationen für eine Deployment-Pipeline ergänzen, die verwendet wird, um einen Dienst eines spezifischen Typs bereitzustellen (z. B. der unter Bezugnahme auf 4 erörterte Anfrageantwortdienst). Die Vorlageninstanz 509 erweitert wiederum die Diensttypvorlage 507, um Einzelheiten für eine spezifische Instanz einer Deployment-Pipeline vorzugeben (z. B. das unter Bezugnahme auf 4 erörterte Ruby-Modul 400). Wie erwähnt, können die Pipeline-Vorlage 505 des Unternehmens, die Diensttypvorlage 507 und die Vorlageninstanz 509 unter Verwendung von Quellcode (z. B. Ruby) dargestellt und unter der Kontrolle eines Revisionskontrollsystems verwaltet werden.
Zusammen bilden die Pipeline-Vorlage 505 des Unternehmens, die Diensttypvorlage 507 und eine Vorlageninstanz 509 die LPT-Instanz 500. Nachdem die Vorlageninstanz 509 verwendet wird, um von dieser zu erben und diese Basisvorlagen entsprechend dem Bedarf für eine spezifische Deployment-Pipeline vorzugeben, wird die resultierende LPT-Instanz 500 zusammengestellt (oder anderweitig erstellt) und ausgeführt, um die Anwendungsdefinition 510 zu erzeugen. Weiter Bezug nehmend auf ein Beispiel auf der Grundlage der Ruby-Programmiersprache könnte die LPT-Instanz 500 an den MRI-Ruby-Übersetzer weitergeleitet und ausgeführt werden, um die Anwendungsdefinition 510 zu erzeugen.
Bei einer Ausführungsform ist die Anwendungsdefinition 510 als ein Ruby-Modell definiert, das ein strukturiertes Dokument umfasst (z. B. ein JSON-Dokument 512). Durch das Formatieren der Anwendungsdefinition 510 als ein strukturiertes Dokument 512 wird eine Beschreibung der Deployment-Pipeline 530 in einem Austauschformat bereitgestellt, die durch die verschiedenen Softwarekomponenten des LPT-Tools 555 verwendet werden kann, um die Deployment-Pipeline 530 bereitzustellen und zu konfigurieren (sowie den Konfigurationszustand der bereitgestellten Pipeline zu bewerten). Die Anwendungsdefinition 510 kann eine Konfiguration für eine Deployment-Pipeline vorgeben, die bereitgestellt und instanziiert werden soll. Zudem, wie nachstehend näher beschrieben, als Ausgabe des LPT-Tools 555 im Rahmen der Bewertung einer vorhandenen Deployment-Pipeline, um einen aktuellen Konfigurationszustand dieser Deployment-Pipeline durch Abfragen eines Satzes von Blattsystemen in Erfahrung zu bringen.
Bei einer Ausführungsform bietet die Anwendungsdefinition 510 eine vollständig vorgegebene Konfiguration für jedes Blattsystem 532-544, das in der Deployment-Pipeline 530 enthalten ist, ohne jedwede nicht aufgelöste Variablen, Makros oder andere externe Referenzen. Nach der Erstellung kann die Anwendungsdefinition 510 durch einen Satz LPT-Synthesetreiber 517-529 zerlegt werden, der im LPT-Tool 555 enthalten ist, wodurch anschließend die Blattsysteme 532-544 bereitgestellt und konfiguriert werden können, die in der Deployment-Pipeline 530 enthalten sind, entsprechend der Anwendungsdefinition.
Wie dargestellt, veranschaulicht das JSON-Dokument 512 - namens „MyApplication.LPT“ - einen Teil der Konfiguration für die Deployment-Pipeline 530. In dem konkreten Beispiel in 5 gehören zu dem Teil der Anwendungsdefinition 512 Konfigurationsinformationen für einen Satz „Leistungsmetriküberwachungseinheiten“, die verwendet werden, um den Zustand von virtuellen Maschinenhosts zu überwachen, die Teil eines Datensatzes „Produktion“ sind und in einer Cloud-Computing-Region bereitgestellt werden (namens „US-Ost“). Natürlich können der konkrete Inhalt und die Struktur der im JSON-Dokument 512 enthaltenen Informationen je nach Fähigkeiten des relevanten Blattsystems, das in der Anwendungsdefinition beschrieben ist, und je nach Bedarf eines bestimmten Falls maßgeschneidert sein.
Bei einer Ausführungsform gehört zum LPT-Tool 555 ein Satz LPT-Synthesetreiber 517-529. Jeder LPT-Synthesetreiber 517-529 kann einen Teil der Software bereitstellen, der einem bestimmten der Blattsysteme 532-544 entspricht. Zudem kann jeder LPT-Synthesetreiber Abschnitte der Anwendungsdefinition 510 zerlegen und auswerten, die für den jeweiligen LPT-Synthesetreiber relevant sind, (und andere Abschnitte ignorieren), um die gewünschte Konfiguration des entsprechenden Blattsystems in der Deployment-Pipeline 530 in Erfahrung zu bringen. Nach dem Zerlegen der Anwendungsdefinition 510 kann jeder LPT-Synthesetreiber so konfiguriert sein, dass er erkennt, welche Elemente des jeweiligen Blattsystems vorhanden sind oder bereitgestellt wurden, sowie deren aktuellen Konfigurationszustand. Nach diesem Erkennen kann ein LPT-Synthesetreiber einen Satz API-Aufrufe ermitteln, um gegen das jeweilige Blattsystem aufzurufen, die Konfiguration dieses Blattsystems mit der Anwendungsdefinition 510 in Einklang zu bringen.
LPT-Synthesetreiber 517-529 können zudem erklären, welche anderen Teile der Anwendungsdefinition 510 durchgesetzt werden sollen, bevor ein bestimmter LPT-Synthesetreiber ein entsprechendes Blattsystem konfigurieren kann. Beispielsweise könnte ein LPT-Synthesetreiber, der verwendet wird, um einen Alarmdienst 544 (d.h. Treiber 529) zu konfigurieren, der Leistungsmetriken überwacht und Alarme ausgibt, erfordern, dass ein Leistungsüberwachungsdienst 542, der die Leistungsmetriken erzeugt, konfiguriert und ausgeführt wird, bevor der Alarmdienst 544 aktiviert wird.
In dem konkreten Beispiel aus 5 gehören zu den LPT-Synthesetreibern 517-529, die im LPT-Tool 555 enthalten sind, ein Pipeline-Treiber 517, ein Bereitstellungstreiber 519, Hostklassen, Hosts und der Gruppentreiber für die automatische Skalierungsgruppe (ASG) 521, ein Netzwerk und Sicherheitstreiber 523, ein Identitäts- und Zugangsverwaltungstreiber (IAM) 525, ein Leistungsüberwachungstreiber 527 und ein Alarmüberwachungstreiber 529.
Bei einer Ausführungsform setzt ein LPT-Synthesetreiber 517-529 eine gewünschte Konfiguration auf einem entsprechenden Blattsystem in Kraft, indem er dem Blattsystem 532-544 eine Beschreibung eines Konfigurationszustandes übermittelt. Das entsprechende Blattsystem ermittelt wiederum, welche Änderungen notwendig sind, um die gewünschte Konfiguration auf diesem Blattsystem in Kraft zu setzen. Das heißt die Blattsysteme 532-544 können so konfiguriert sein, dass sie ihren jeweiligen Konfigurationszustand als Reaktion auf Meldungen vom jeweiligen LPT-Synthesetreiber 517-529 ändern. Ein LPT-Synthesetreiber 517-529 könnte jedoch auch API-Aufrufe nach Bedarf aufrufen, um Konfigurationszustände, Einstellungen, Attribute, Parameter oder Eigenschaften usw. direkt zu ändern. Der Pipeline-Treiber 517 kann verwendet werden, um einen Pipeline-Dienst 532 zu konfigurieren. Bei einer Ausführungsform kann der Pipeline-Dienst 532 Systeme und Dienste umfassen, die ein Quellcodearchiv auf neue Versionen einer Anwendung überwachen und den Prozess des Übertragens dieser Anwendung in die Produktion über die Deployment-Pipeline 530 beginnen. Dementsprechend könnte der Pipeline-Dienst 517 verwendet werden, um Instanzen der VM mit den entsprechenden Erstellungstools bereitzustellen (z. B. Compiler, Interpreter usw.), die Quellcodearchive vorzugeben, Erstellungsziele und Installationsskripte oder -tools vorzugeben, neben jedweden anderen damit verbundenen Artefakten, die erforderlich sind, um einen Satz ausführbare Software aus dem Quellcode eines Produktionsdienstes zu erstellen. Gleichermaßen könnte der Pipeline-Treiber 517 Alarme konfigurieren, die durch den Pipeline-Dienst 532 verwendet werden, um ein Entwicklungsteam auf Fehler oder Warnungen bei der Erstellung hinzuweisen, wenn Erstellungsziele für eine neue Revision einer bereitgestellten Anwendung erstellt werden.
Der Bereitstellungstreiber 519 kann verwendet werden, um einen Bereitstellungsdienst 534 zu konfigurieren. Bei einer Ausführungsform können zum Bereitstellungsdienst 535 Systeme und Dienste gehören, die die durch den Pipeline-Dienst erzeugten Erstellungsziele durch eine Reihe von Teststufen und bei Erfolg in die Produktion übertragen. Dementsprechend kann der Bereitstellungsdienst 534 Instanzen der VM konfigurieren, die die Erstellungsziele in einer Vorproduktionstestumgebung bereitstellen und beliebige „Sandkastentests“ durchführen können, die in der Anwendungsdefinition 510 vorgegeben sind. Der Bereitstellungsdienst kann zudem die Erstellungsziele auf Produktionsservern bereitstellen, z. B. unter Verwendung eines One-Box-Testzeitraums, gefolgt von einer schrittweisen Bereitstellung für die vollständige Produktion. Der Bereitstellungstreiber 519 könnte zudem den Bereitstellungsdienst 534 so konfigurieren, dass dieser auf Alarme reagiert, die im Zusammenhang mit Leistungsmetriken erzeugt werden, die durch die Leistungsüberwachungsdienste 542 (entsprechend der Konfiguration durch den Leistungsüberwachungseinheittreiber 527) und Alarmdienste 529 bereitgestellt werden (entsprechend der Konfiguration durch den Alarmtreiber 527). In einem derartigen Fall könnte der Bereitstellungstreiber 519 fordern, dass der Leistungsüberwachungsdienst 542 und der Alarmdienst 544 bereitgestellt werden und aktiv sind, bevor eine Bereitstellungsumgebung konfiguriert wird, die auf den Leistungsüberwachungsdienst 542 und den Alarmdienst 544 zurückgreift.
Die Hostklassen, Hosts und ASG-Treiber (kurz Host-Treiber 521) können verwendet werden, um Rechendienste 536 zu konfigurieren. Bei einer Ausführungsform können zu den Rechendiensten 536 die Instanzen der VM und damit verbundene Dienste gehören, die durch die Instanzen der VM als Teil des bereitgestellten Produktionsdienstes verwendet werden. Beispielsweise können die Host-Treiber 521 Hostklassen für Instanzen der VM konfigurieren, die verwendet werden, um die Anwendungsziele auszuführen, die durch den Pipeline-Dienst 532 erstellt wurden. Beispielsweise könnten die Host-Treiber 521 eine Hostklasse „Server“ konfigurieren, die Eigenschaften für eine Instanz der VM vorgibt, die verwendet wird, um einen Anwendungsserver zu hosten. Nach der Konfiguration könnten die Host-Treiber 521 auf den Rechendienst 536 zugreifen, um eine Sammlung von Instanzen der VM der Hostklasse „Server“ einzuführen und diese mit dem Anwendungsziel bereitzustellen, das durch den Pipeline-Dienst 532 erstellt wurde, und zwar eine Umgebung, die durch den Bereitstellungskonfigurationstreiber 519 bereitgestellt wird. Gleichermaßen könnten die Host-Treiber 521 einen automatischen Skalierungsdienst konfigurieren (bereitgestellt als Teil des Rechendienstes 536 in diesem Beispiel) der Instanzen der VM der Hostklasse „Server“ von der Sammlung auf Grundlage des Bedarfs eingeführt (oder entfernt) hat, den der Produktionsdienst empfangen hat. In einem derartigen Fall könnten die Host-Treiber 521 erfordern, dass der Leistungsüberwachungsdienst 542 und der Alarmdienst 544 bereitgestellt und konfiguriert werden, damit die automatische Skalierungsgruppe erstellt wird, um die der Sammlung bereitgestellten Hosts zu verwalten. Die Host-Treiber 521 könnten zudem eine Vielzahl von anderen Rechendiensten konfigurieren, die der unter Verwendung der Deployment-Pipeline 530 bereitgestellte Produktionsdienst benötigt, z. B. Dienste wie Datenbankdienste, Speicherdienste, Messaging-Dienste, Benachrichtigungsdienste, Ablaufdienste usw.
Der Netzwerk- und Sicherheitstreiber 523 kann verwendet werden, um Netzwerkdienste 538 zu konfigurieren. Bei einer Ausführungsform kann der Netzwerk- und Sicherheitstreiber 523 Datenkommunikationsnetze bereitstellen, die von den Instanzen der VM verwendet werden, die durch den Treiber 519 eingeführt wurden. Beispielsweise könnte der Netzwerk- und Sicherheitstreiber 523 virtuelle IP-Adressen (VIP) konfigurieren, die verwendet werden, um ein Netzwerk für die Instanzen der VM zu erstellen, die durch die Host-Treiber 521 bereitgestellt werden. Hierfür könnte die Anwendungsdefinition 510 eine Konfiguration für IP-Adressen, Domänennameninformationen, Switching- und Routing-Informationen, Regeln zum Erstellen von Firewalls oder Verkehr, Standorte für Edge-Server oder Adressen für CDN usw. vorgeben. Zudem könnte der Netzwerk- und Sicherheitstreiber 523 virtuelle private Netzwerke zwischen Instanzen der VM bereitstellen und Sicherheitszertifikate installieren, z. B. SSL-Zertifikate auf Instanzen der VM und Anwendungen. Dadurch können die Anwendungen des durch die Deployment-Pipeline 530 bereitgestellten Produktionsdienstes miteinander (oder mit Client-Systemen) unter Verwendung verschlüsselter Kanäle kommunizieren.
Der Identitäts- und Zugriffsverwaltungstreiber (IAM) 525 kann verwendet werden, um Identitätsdienste 540 zu konfigurieren. Bei einer Ausführungsform kann der IAM-Treiber 525 Benutzerkonten, Benutzernamen, Zugriffskontrolllisten, Zugriffsregeln usw. auf den Instanzen der VM bereitstellen, die durch die Bereitstellung eines Produktionsdienstes abgedeckt sind, d.h. auf den Instanzen der VM, die durch die Host-Treiber 521 eingeführt wurden.
Wie erwähnt, konfiguriert der Leistungsüberwachungseinheittreiber 527 die Leistungsüberwachungsdienste 543 und konfiguriert der Alarmüberwachungstreiber 529 Alarmdienste 544. Bei einer Ausführungsform können die Überwachungsdienste 543 und die Alarmdienste 544 verwendet werden, um jeden messbaren Aspekt der durch die Deployment-Pipeline 530 bereitgestellten Anwendung, Systeme oder Dienste sowie Aspekte der Deployment-Pipeline 530 selbst zu überwachen. Wie ebenfalls erwähnt, können andere LPT-Synthesetreiber auf die Konfiguration von Alarmen oder Werte für Leistungsmetriken zurückgreifen, wenn sie Softwareanwendungen durch die Deployment-Pipeline 530 und in die Produktion übertragen, sowie die Leistung des Produktionsdienstes selbst überwachen.
6 veranschaulicht ein Beispiel einer kontinuierlichen Deployment-Pipeline, die unter Verwendung des LPT-Syntheseverfahrens unter Verwendung der Anwendungsdefinition 510 und des LPT-Instanzpakets 500 erzeugt wurde, die in den 5 dargestellt sind, entsprechend einer Ausführungsform. In diesem Beispiel wird die Deployment-Pipeline 600 verwendet, um Revisionen auf Quellcodepakete 602 durch beide Vorproduktionsteststufen (d.h. alpha-Teststufe 604 und beta-Teststufe 605) und durch drei Wellen von Produktionsteststufen zu verteilen, die drei Gruppen von Cloud-Computing-Regionen ein Anwendungsziel 603 bereitstellen.
Die Quellpakete 602 entsprechen dem Quellcode und jedweden damit verbundenen Dateien (z. B. Erstellungsdateien, Bibliotheken, Bilder, Web- oder Medieninhalte usw.), die erforderlich sind, um ein Anwendungsziel 603 zu erstellen. In diesem Beispiel steht die Initiierung der Pipeline 601 für eine Einstellung dessen, ob die kontinuierliche Deployment-Pipeline Revisionen den Quellpaketen 602 automatisch bereitstellt (z. B. jede neue Version im Versionierungssystem) oder ein Entwickler auslösen muss, dass eine spezifische Version durch die Deployment-Pipeline 602 und in die Produktion verbreitet wird. In jedem Fall ruft die Deployment-Pipeline direkt nach der Aktivierung die Quellpakete 602 ab und erstellt ein Anwendungsziel.
Vorausgesetzt, dass das Erstellen des Anwendungsziels 603 aus dem Quellpaket 602 erfolgreich ist, geht die Deployment-Pipeline 600 anschließend zu einem Test in der alpha-Stufe 604 über. In der Regel erfolgt das Testen in der alpha-Stufe, um den Verwendungszweck des Anwendungsziels unter Verwendung eines Testrahmens- oder Gerüstes zu simulieren. Benutzer im Entwicklungsteam können während Tests in der alpha-Stufe ebenfalls mit dem Anwendungsziel in einer simulierten Produktionsumgebung interagieren. Da die Deployment-Pipeline 600 jedoch allgemein verwendet wird, um das Bereitstellungsverfahren zu automatisieren, kann in vielen Fällen auf ein direktes Eingreifen des Benutzers verzichtet werden. Tests in der alpha-Stufe können zudem die Durchführung eines Integrationstests umfassen, um zu ermitteln, ob das Anwendungsziel 603 korrekt mit anderen bereits bereitgestellten Systemen und/oder Diensten interagiert, die Teil eines Produktionsdienstes sind, dem das Anwendungsziel 603 bereitgestellt wird. Wenn das Anwendungsziel 603 einen der Tests in der alpha-Stufe 604 nicht besteht (oder eine beliebige Kombination aus Grenzanforderungen nicht einhält, die für Tests in der alpha-Stufe vorgegeben sind), kann die Deployment-Pipeline 600 die Bereitstellung des Anwendungsziels 603 abbrechen und dem Entwicklungsteam Protokolldaten bereitstellen. Beispielsweise kann die Deployment-Pipeline 600 dem administrativen Kontakt Nachrichten senden, der in der Vorlageninstanz einer Live-Pipeline-Vorlage vorgegeben ist, die verwendet wird, um die Deployment-Pipeline 600 zu erzeugen.
Vorausgesetzt, dass das Anwendungsziel 603 die Tests in der alpha-Stufe 604 erfolgreich absolviert, kann die Deployment-Pipeline 600 mit Tests in der beta-Stufe 605 fortfahren. In der Regel können Tests in der beta-Stufe folgendes umfassen. Beispielsweise kann ein Test in der beta-Stufe 605 eine Bereitstellungshandlung umfassen, mit der das Anwendungsziel 603 einem oder mehreren Zwischenservern bereitgestellt wird, die durch die Deployment-Pipeline 600 eingeführt wurden. Während der Tests in der beta-Stufe 605 kann die Leistung des auf den Zwischenservern laufenden Anwendungsziels 603 überwacht und ggf. entsprechend einer Reihe von Metriken bewertet werden, um zu ermitteln, ob das Anwendungsziel in der Zwischenumgebung korrekt funktioniert. Wie bei den Tests in der alpha-Stufe 604, kann, sollte das Anwendungsziel 604 jedwede Leistungsanforderungen nicht erfüllen, die für die Tests in der beta-Stufe 605 vorgegeben sind, die Deployment-Pipeline die Bereitstellung des Anwendungsziels 603 abbrechen und dem Entwicklungsteam Protokolldaten bereitstellen.
Im Anschluss an die Vorproduktionsteststufen, d.h. im Anschluss an Tests in der alpha-Stufe 604 und Tests in der beta-Stufe 606, kann die Deployment-Pipeline 600 damit beginnen, das Anwendungsziel 603 für eine immer breitere Produktionsverwendung zu übertragen, bis das Anwendungsziel 603 vollständig bereitgestellt ist. In dem konkreten Beispiel in 6 gehören zur Deployment-Pipeline 600 drei Produktionsbereitstellungswellen. In jeder Welle wird das Anwendungsziel 603 in die Produktion in eine andere Gruppe von Rechenregionen übertragen. Jede Welle umfasst einen Test in der gamma-Stufe, der verwendet wird, um die regionale Konfigurations- und Integrationskompatibilität zwischen dem Anwendungsziel 603 und einer bestimmten Cloud-Computing-Region zu untersuchen, bevor der Übergang zu regionalen Stufen mit Kundenverkehr erfolgt. Im Anschluss an den Test in der gamma-Stufe gehört zu jeder Welle eine One-Box-Stufe, um fatale Fehler oder Probleme mit der Latenzzeit zu erkennen. Während der One-Box-Stufe wird ein Anwendungsziel mit einer einzelnen Instanz in einer Live-Bereitstellungsumgebung getestet. Nach einem Zeitraum der Überwachung kann die Deployment-Pipeline 600 mit einer vollständigen Produktionsbereitstellungsstufe fortfahren, in der das Anwendungsziel 603 auf jeden Server ausgerollt wird, der das Anwendungsziel 603 in einer bestimmten Cloud-Computing-Region hostet.
Natürlich können die Geschwindigkeit, mit der das Anwendungsziel 603 auf die vollständige Produktion verbreitet wird, und die Bedingungen zum Anhalten, Abbrechen oder Zurückrollen einer laufenden Bereitstellung als Teil der Live-Pipeline-Vorlage vorgegeben werden, die verwendet wird, um die kontinuierliche Deployment-Pipeline 600 unter Verwendung des vorstehend erörterten LPT-Syntheseverfahrens zu instanziieren. Wie erwähnt, kann die Deployment-Pipeline 600 beispielsweise Zurückroll- und Leistungsüberwachungseinheiten für jede Produktionsstufe, für jede Region, sowie Beharrungsalarme für Dienstmetriken und andere Alarme oder Dienstmetriken umfassen, wie etwa Alarme für VIP-Metriken oder JMX-Metriken, die verwendet werden, um das Anwendungsziel während der Bereitstellung in die Produktionsverwendung zu überwachen. Wichtig ist jedoch, dass die Entwickler, die die Deployment-Pipeline 600 erstellen, keine dieser Sicherheitsfunktionen, Zurückrollbedingungen, Alarme oder Leistungsmetrikgrenzen usw. während der Erstellung der Deployment-Pipeline 600 ausdrücklich vorgeben mussten. Diese Funktionen werden vielmehr durch die Auswahl einer Live-Pipeline-Vorlage impliziert, um diese um eine Dienstinstanzvorlage zu erweitern, und automatisch in der Deployment-Pipeline 600 durch das LPT-Tool während der LPT-Synthese erzeugt.
In dem Beispiel aus 6 wird das Anwendungsziel 603 zunächst für eine Rechenregion namens „AP-Südost-1“ bereitgestellt, und zwar während der gamma-/Integrationsstufe 622. Im Anschluss an diese Stufe wird das Anwendungsziel 603 als nächstes in einer One-Box-Produktionsstufe 614 und anschließend in einer vollständigen Produktionsbereitstellungsstufe 616 bereitgestellt. Vorausgesetzt, dass das Anwendungsziel 603 vollständig für die Rechenregion „AP-Südost-1“ bereitgestellt ist, wiederholt die Deployment-Pipeline 600 diesen Vorgang während einer zweiten Bereitstellungswelle. Dementsprechend umfasst die zweite Bereitstellungswelle ebenfalls eine gamma-/Integrationsstufe 622, eine One-Box-Produktionsstufe 624 und eine vollständige Produktionsbereitstellungsstufe 626, die verwendet werden, um das Anwendungsziel drei zusätzlichen Cloud-Computing-Regionen bereitzustellen - namens „SA-Ost“ „US-West“ und „AP-Südost-2“. Auf jeder Stufe der zweiten Welle können Leistungsüberwachungseinheiten und Alarme (vorgegeben in der Basisvorlage einer Live-Pipeline-Vorlage) die Bereitstellung des Anwendungsziels 603 in diesen Regionen überwachen. Es ist zu beachten, dass die Deployment-Pipeline 600 das Anwendungsziel 603 in jeder der Regionen „SA-Ost“, „US-West“ und „AP-Südost-2“ unabhängig voneinander überwachen kann. Dementsprechend könnte das Anwendungsziel 603 am Ende erfolgreich auf weniger als alle drei dieser Regionen verteilt sein. Schließlich fährt die Deployment-Pipeline 600, vorausgesetzt, dass das Anwendungsziel 603 auf eine oder mehrere der Rechenregionen „SA-Ost“, „US-West“ und „AP-Südost-2“ verbreitet wird, damit fort, das Anwendungsziel 603 während der abschließenden Bereitstellungswelle auf zwei zusätzliche Rechenregionen (namens „EU-West“ und „US-Ost“ in diesem Beispiel) zu verbreiten. Wie bei der ersten und zweiten Welle, gehört zur abschließenden Bereitstellungswelle eine gamma-/Integrationsstufe 632, eine One-Box-Produktionsstufe 634 und eine vollständige Produktionsbereitstellungsstufe 636, in denen die Deployment-Pipeline 600 das Anwendungsziel 603 überwacht, bis dieses vollständig in der Produktion bereitgestellt (oder aufgrund von Leistungsproblemen angehalten) ist.
Es ist zu beachten, dass die Regionen für die Deployment-Pipeline 600 in diesem Beispiel durch das LPT-Tool durch Subtrahieren der Regionen, die ausdrücklich in den Linien 23-25 der Dienstinstanzvorlage in der schwarzen Liste aufgeführt sind, siehe 4, von einer Masterliste mit Rechenregionen, die durch einen Anbieter zur Verfügung gestellt werden, berechnet worden sein können (anstatt ausdrücklich vorgegeben). Zudem kann das LPT-Tool 155 den Bereitstellungsfluss für die ausgewählten Regionen automatisch durch Erzeugen von Bereitstellungswellen angeordnet haben, beginnend mit der Rechenregion mit dem niedrigsten Verkehr und endend mit den Regionen mit dem höchsten Verkehr (und mit den verbleibenden Regionen in der Mitte der Bereitstellungswelle). Natürlich könnte ein Entwickler Verfahren in der Vorlageninstanz 320 aus 4 definieren, die ausdrücklich einen Bereitstellungsfluss oder sogar eine einzelne Rechenregion vorgeben.
Allgemeiner ausgedrückt, wird ein Durchschnittsfachmann erkennen, dass die Verwendung von alpha-, beta-, gamma-, One-Box- und vollständigen Bereitstellungsstufen die Arten von Tests veranschaulicht, die ein Unternehmen in eine Deployment-Pipeline einbeziehen könnte, die auf der Grundlage einer Live-Pipeline-Vorlage erstellt wurde und verwendet wird, um das Anwendungsziel 603 in die Produktion zu verbreiten. In der Praxis könnte die Deployment-Pipeline 600 mit diesen oder anderen Teststufen konfiguriert sein, wobei Kennzeichnung und Konfiguration eine untergeordnete Rolle spielen, wie dies erforderlich ist, um den Anforderungen in einem bestimmten Fall Rechnung zu tragen.
7 veranschaulicht ein Verfahren 700 zum Erzeugen, auf der Grundlage einer Live-Pipeline-Vorlage, einer Deployment-Pipeline, die verwendet wird, um einen Produktionsrechendienst bereitzustellen und zu aktualisieren, entsprechend einer Ausführungsform. Wie dargestellt, beginnt das Verfahren 700 bei Schritt 705, wo das Live-Pipeline-Vorlage-Tool ein LPT-Paket empfängt. Das LPT-Paket kann den Quellcode für eine dienstspezifische Instanz einer Live-Pipeline-Vorlage enthalten, die eine Hierarchie aus einer oder mehreren Pipeline-Basisvorlagen in Unterklassen teilt. Die dienstspezifische Instanz kann die eine oder die mehreren Basisvorlagen nach Bedarf erweitern und/oder überschreiben, um eine begrenzte Anzahl an dienstinstanzspezifischen Einzelheiten für eine kontinuierliche Deployment-Pipeline vorzugeben. Die eine oder die mehreren Pipeline-Basisvorlagen können einen Satz bester Vorgehensweisen, Sicherheitsfunktionen, Zurückrollbedingungen, Alarme oder Leistungsmetrikgrenzen erfassen, die verwendet werden sollen, um eine Anwendung oder Komponente eines Produktionsdienstes eines bestimmten Diensttyps bereitzustellen.
Bei Schritt 710 können die entsprechenden Erstellungstools ein Anwendungsziel des LPT-Pakets erstellen. Unter Verwendung des Ruby-Moduls 400 aus 4 als ein Beispiel könnte das LPT-Paket unter Verwendung des MRI-Ruby-Interpreters ausgeführt werden, um die Inhalte einer Anwendungsdefinition in eine Datei zu schreiben. Wie erwähnt, kann die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für eine Deployment-Pipeline bereitstellen, ohne jedwede nicht aufgelöste Variablen, externe Referenzen oder Makros. Die Anwendungsdefinition kann in ein strukturiertes Austauschformat formatiert sein (z. B. als JSON-formatiertes Dokument).
Bei Schritt 715 kann die resultierende Anwendungsdefinition auf das LPT-Tool übertragen werden, das eine Sammlung von LPT-Synthesetreibern verwendet, die im LPT-Tool enthalten sind, um ein System oder eine Dienstkomponente einer Deployment-Pipeline entsprechend der Anwendungsdefinition bereitzustellen, einzuführen, zu konfigurieren oder anderweitig vorzubereiten. Bei Schritt 725 zerlegen die LPT-Synthesetreiber die Anwendungsdefinition, um einen oder mehrere Abschnitte der Anwendungsdefinition zu erkennen, die für einen bestimmten LPT-Synthesetreiber relevant sind.
Bei Schritt 730 kann jeder der LPT-Synthesetreiber ermitteln, ob jedwede Anforderungen an die Konfiguration des Blattsystems, die einem bestimmten LPT-Synthesetreiber entsprechen, erfüllt sind. Beispielsweise kann ein Bereitstellungstreiber, der verwendet wird, um einen Bereitstellungsdienst zu konfigurieren, auf Überwachungs- und Alarmdienste zurückgreifen, die vor dem Erstellen der Vorproduktionsteststufen und der Produktionsteststufen einer Bereitstellungsumgebung konfiguriert werden. Gleichermaßen kann ein automatischer Skalierungsdienst, der verwendet wird, um eine automatische Skalierungsgruppe bereitzustellen, eine Hostklassenkonfiguration erfordern, damit Instanzen der VM, die im Rahmen der automatischen Skalierungsgruppe verwendet werden sollen, vor dem Konfigurieren der automatischen Skalierungsgruppe verfügbar sind. Allgemeiner ausgedrückt, kann jeder LPT-Synthesetreiber erklären, welche anderen Teile der Anwendungsdefinition durchgesetzt werden müssen, bevor diese veranlasst werden, ein Element der Deployment-Pipeline zu konfigurieren, das in der Anwendungsdefinition vorgegeben ist.
Sobald alle Anforderungen für einen bestimmten LPT-Synthesetreiber erfüllt wurden, kann dieser Treiber eine entsprechende Blattsystemkomponente der Deployment-Pipeline konfigurieren, die in der Anwendungsdefinition vorgegeben ist. Bei Schritt 735, wenn ein bestimmter LPT-Synthesetreiber die entsprechende Blattsystemkomponente nicht konfigurieren kann, meldet das LPT-Tool bei Schritt 740 einen Fehler und hält das LPT-Syntheseverfahren an, um Blattsystemkomponenten der Deployment-Pipeline zu konfigurieren. Natürlich könnten Protokolldaten oder andere Meldungen erfasst und an ein Entwicklungsteam gesendet werden, die anzeigen, welcher der LPT-Synthesetreiber ein entsprechendes Blattsystem nicht entsprechend der Anwendungsdefinition konfigurieren konnte und welche Fehler aufgetreten sind. Andernfalls ermittelt das LPT-Tool bei einer erfolgreichen Konfiguration bei Schritt 745 anschließend, ob mehr LPT-Synthesetreiber die Blattsystemkomponenten der Pipeline konfigurieren müssen. Ist dies der Fall, kehrt das Verfahren 700 zu Schritt 730 zurück, wo zusätzliche Blattsystemkomponenten konfiguriert werden. Dieser Prozess kann sich im Allgemeinen wiederholen, bis ein Fehler auftritt oder die Deployment-Pipeline vollständig konfiguriert und für eine Verwendung zum Bereitstellen eines Produktionsdienstes bereit ist.
Nach der Bereitstellung, z. B. entsprechend Verfahren 700 aus 7, kann die resultierende kontinuierliche Deployment-Pipeline selbst das Bereitstellungsziel einer Meta-Pipeline sein. Wie erwähnt, kann die Meta-Pipeline verwendet werden, um an der Live-Pipeline-Vorlage vorgenommene Änderungen in die kontinuierliche Deployment-Pipeline zu verbreiten. Anders ausgedrückt, ist die Meta-Pipeline getrennt von den Aktionen der Deployment-Pipeline, die verwendet wird, um Änderungen an Anwendungen oder anderen Komponenten eines Produktionsdienstes zu verbreiten. 8 veranschaulicht ein Verfahren 800 für eine Meta-Pipeline, um eine Deployment-Pipeline zu modifizieren, die selbst verwendet wird, um einen Produktionsrechendienst auf der Grundlage von Änderungen an einer Live-Pipeline-Vorlage bereitzustellen, entsprechend einer Ausführungsform.
Wie dargestellt, beginnt das Verfahren 800 bei Schritt 805, wo die Meta-Pipeline (oder die Komponente des LPT-Tools) ein Auslöseereignis erkennt, das die aufgezeichnete Version eines LPT-Pakets ändert, das mit einer kontinuierlichen Deployment-Pipeline assoziiert ist. Bei einer Ausführungsform kann das LPT-Tool auf Änderungen am Quellcode einer Live-Pipeline-Vorlage überwachen, die auf einen Bereitstellungsversionszweig in einem Versionierungssystem übertragen werden.
Beispielsweise kann ein Entwicklungsteam bei Herausbildung oder Änderung der besten Vorgehensweisen oder Präferenzen für eine Deployment-Pipeline in einem Unternehmen oder Geschäftsbereich den Quellcode der Basisvorlage des Unternehmens aktualisieren. Als weiteres Beispiel könnte der Quellcode der Basisvorlage des Unternehmens aktualisiert werden, um einen Nutzen aus neuen Diensten oder neuen Funktionen bestehender Dienste zu ziehen, wenn diese in den Cloud-Computing-Regionen verfügbar werden, die einen Produktionsdienst hosten. Als zusätzliche Beispiele könnten Aspekte von spezifischeren Vorlagen in der Live-Pipeline-Hierarchie geändert werden, wie etwa eine Vorlage des Entwicklungs-/Betriebsteams, die zusätzliche Kontaktinformationen oder Änderungen an der dienstspezifischen Vorlage hinzufügt, durch die zusätzliche Verfahren in der Basisklassenvorlage überschrieben oder eine auf der schwarzen Liste aufgeführte Region aus der dienstspezifischen Vorlage entfernt werden sollen. Dieses letztere Beispiel könnte zu einer vollkommen neuen Instanz der Systeme und Dienste führen, die verwendet werden, um eine kontinuierliche Deployment-Pipeline bereitzustellen, die in einer neuen Rechenregion bereitgestellt und eingeführt wird.
Welche Änderungen an der LPT-Instanz oder an der darunterliegenden Hierarchie von Vorlagen eine Verbreitung der Änderung nach außen auf die kontinuierliche Deployment-Pipeline auslösen sollen, über die Meta-Pipeline, kann auf der Grundlage der Präferenz in einem bestimmten Fall maßgeschneidert sein. Zudem können zusätzlich zu Änderungen an einer Live-Pipeline-Vorlage, die eine Aktualisierung einer Deployment-Pipeline auslösen, Änderungen an der Cloud-Computing-Umgebung dazu führen, dass die Meta-Pipeline verwendet wird, um eine Deployment-Pipeline zu modifizieren. Wenn beispielsweise neue Cloud-Computing-Regionen verfügbar werden oder wenn bestimmte Dienste, die für die Deployment-Pipeline erforderlich sind, in einer vorhandenen Cloud-Computing-Region bereitgestellt und eingeführt werden, könnte die Meta-Pipeline verwendet werden, um Systeme und Dienste für eine neue kontinuierliche Deployment-Pipeline in derartigen Rechenregionen bereitzustellen und einzuführen. Natürlich könnte ein Entwickler die Meta-Pipeline auch manuell aktivieren, um Änderungen an einer Live-Pipeline-Vorlage für eine Verwendung in der Produktion zu verbreiten.
Erneut Bezug nehmend auf 8, wird bei Schritt 810 das LPT-Tool verwendet, um eine aktualisierte Anwendungsdefinition aus dem aktualisierten Quellcode der Live-Pipeline-Vorlage zu erstellen. Bei Schritt 815 beginnt ein Kreis, in dem ein (oder mehrere) der LPT-Synthesetreiber die aktualisierte Anwendungsdefinition zerlegen, um Abschnitte zu bestimmen, die einen gewünschten Konfigurationszustand für ein entsprechendes Blattsystem (oder für entsprechende Systeme) vorgeben. Wie erwähnt, können einige LPT-Synthesetreiber in Abhängigkeiten mit anderen stehen. Bei jedem Durchlauf des Kreises, beginnend bei Schritt 815, können LPT-Synthesetreiber, die keine unbefriedigten Abhängigkeitsanforderungen aufweisen, verwendet werden, um den Konfigurationszustand der entsprechenden Blattsysteme auf der Grundlage der aktualisierten Anwendungsdefinition zu aktualisieren.
Bei Schritt 820 kann ein LPT-Synthesetreiber den gewünschten Konfigurationszustand an das entsprechende Blattsystem weiterleiten. Das Blattsystem kann wiederum ermitteln, ob die Änderungen durchgeführt werden können oder ob der vom LPT-Synthesetreiber weitergeleitete Konfigurationszustand auf dem Blattsystem durchgesetzt werden kann (Schritt 825). Beispielsweise kann jedes Blattsystem Unterschiede zwischen einer aktuellen Konfiguration dieses Blattsystems und einem gewünschten Zustand erkennen, der durch den entsprechenden LPT-Synthesetreiber gefordert wurde. Wenn ein Konfigurationszustand eines bestimmten Blattsystems nicht modifiziert oder, wie durch den LPT-Synthesetreiber gefordert, durchgesetzt werden kann, meldet bei Schritt 830 der entsprechende LPT-Synthesetreiber einen Fehler und können alle an diesem Blattsystem (oder an anderen Systemen als Teil eines Updates) vorgenommenen Änderungen auf den vorherigen Konfigurationszustand zurückgerollt werden. Natürlich könnten Protokolldaten oder andere Meldungen erfasst und an ein Entwicklungsteam gesendet werden, die anzeigen, wie die aktualisierte Anwendungsdefinition im Widerspruch mit der aktuellen Deployment-Pipeline steht, oder beschreiben, warum die Deployment-Pipeline nicht aktualisiert werden kann.
Andernfalls kehrt bei Schritt 835, wenn mehr Blattsysteme verarbeitet werden müssen, das Verfahren zu Schritt 815 zurück, wo ein (oder mehrere) der LPT-Synthesetreiber die Anwendungsdefinition weiter auf dem entsprechenden Blattsystem (oder den entsprechenden Systemen) durchsetzen, bis die Deployment-Pipeline vollständig aktualisiert ist (oder ein Fehler auftritt, der die Aktualisierung unterbricht).
9 veranschaulicht ein Verfahren 900 zum Ermitteln, ob Änderungen an einer Live-Pipeline-Vorlage auf die Blattsysteme einer kontinuierlichen Deployment-Pipeline verbreitet werden können, entsprechend einer Ausführungsform. Das Verfahren 900 veranschaulicht im Allgemeinen Schritte, die als Teil von Schritt 835 des Verfahrens 800 aus 8 durchgeführt werden können. Wie dargestellt, beginnt das Verfahren 900 bei Schritt 905, wo ein Blattsystem Unterschiede zwischen einem aktuellen Konfigurationszustand und einem Sollkonfigurationszustand ermittelt, der durch einen LPT-Synthesetreiber gefordert wurde.
Bei Schritt 910 kann ein Blattsystem ermitteln, welche anderen Dienste, Anwendungskomponenten oder Dienstabhängigkeiten durch den Sollkonfigurationszustand gefordert sein könnten. Das heißt, dass das Blattsystem ermittelt, welche Abhängigkeiten erfüllt sein müssen, damit der Sollkonfigurationszustand auf diesem Blattsystem durchgesetzt werden kann.
Bei Schritt 915 kann das Blattsystem ermitteln, ob die Systeme oder Dienste, die bei Schritt 910 erkannt wurden, verfügbar oder konfiguriert sind oder anderweitig jedwede Anforderungen des Blattsystems erfüllen. Beispielsweise kann eine Update für die Live-Pipeline-Vorlage eine Konfiguration für ein erstes Blattsystem vorgeben, die andere Blattsysteme oder Dienste erfordert, die dem ersten Blattsystem nicht zur Verfügung stehen. In anderen Fällen kann ein bestimmtes Blattsystem ermitteln, dass die aktualisierte Anwendungsdefinition auf Funktionen des bestimmten Blattsystems verweist, die in einer bestimmten Hostregion nicht bereitgestellt werden.
Das Blattsystem kann zudem ermitteln, ob jedwede Dienstabhängigkeiten erfüllt werden, die durch das Blattsystem gefordert sind. Beispielsweise könnte ein Blattsystem in einer Region die Verfügbarkeit von anderen Diensten erfordern, auf die durch die Anwendungsdefinition nicht ausdrücklich verwiesen wird, die für diese Region nicht verfügbar sind. Beispielsweise kann ein Netzwerksicherheitsdienst, der verwendet wird, um Sicherheitszertifikate auf Serversystemen für die Öffentlichkeit bereitzustellen und zu konfigurieren, bei gleichzeitiger Bereitstellung einer Anwendung über die Deployment-Pipeline, eine Abhängigkeit aufweisen, die Zugriff auf eine Zertifizierungsstelle erfordert, die digitale Zertifikate ausgibt, die öffentliche Schlüssel unterzeichnen, die durch den Netzwerksicherheitsdienst erzeugt wurden. Als ein anderes Beispiel kann ein verwendeter Pipeline-Dienst Abhängigkeiten im Zusammenhang mit der Verfügbarkeit eines Quellcodearchivs, eines Versionierungssystems und verfügbarer Erstellungstools in der Cloud-Computing-Region aufweisen, in der der Pipeline-Dienst gehostet wird.
Wenn beliebige Dienste oder durch die aktualisierte Anwendungsdefinition vorgegebene Abhängigkeiten nicht verfügbar sind oder irgendwelche nicht aufgelösten Abhängigkeitsprobleme erkannt werden, kann das Blattsystem einen Fehler an den LPT-Synthesetreiber melden (Schritt 920). Andernfalls, d.h. alle Abhängigkeiten sind erfüllt, kann bei Schritt 925 das Blattsystem ermitteln, ob der aktualisierte Konfigurationszustand des Blattsystems umsetzbar ist (Schritt 920). Das heißt, das Blattsystem kann zudem beliebige Parameter, Attribute oder andere Aspekte des Sollkonfigurationszustandes validieren, und zwar auf der Grundlage der Betriebsfähigkeiten dieser Blattsysteme. Steht eine beliebige Konfiguration im Widerspruch oder werden ungültige Konfigurationseinstellungen gefunden, kann das Blattsystem einen Fehler an den LPT-Synthesetreiber melden (Schritt 935). Andernfalls aktualisiert das Blattsystem bei Schritt 930 den aktuellen Konfigurationszustand dieses Blattsystems, damit dieser dem Sollkonfigurationszustand entspricht, der vom LPT-Synthesetreiber empfangen wurde. Direkt nach dem Durchsetzen kann das Blattsystem dem entsprechenden LPT-Synthesetreiber melden, dass das Update abgeschlossen ist.
10 veranschaulicht ein Verfahren 1000 zum automatischen Konfigurieren und Bereitstellen von Systemen und Diensten für eine Deployment-Pipeline auf der Grundlage einer vorhandenen Live-Pipeline-Vorlage in einer neu verfügbaren Cloud-Computing-Region, entsprechend einer Ausführungsform.
Wie im Ruby-Modul 400 in 4 veranschaulicht, kann ein Entwickler bei einer Ausführungsform einen Satz Rechenregionen vorgeben, die aus dem LPT-Syntheseverfahren beim Einführen einer Deployment-Pipeline ausgeschlossen werden sollen. Dementsprechend wird der Produktionsdienst, der über diese Pipeline bereitgestellt wird, daran gehindert, in demselben Satz Rechenregionen eingeführt zu werden. Wenn ein Entwickler eine der Cloud-Computing-Regionen aus diesem Satz entfernt, oder in anderen Fällen, wo neue Cloud-Computing-Regionen durch den Anbieter bereitgestellt werden, kann das Verfahren 1000 ausgelöst werden, um eine Deployment-Pipeline zu konfigurieren, die verwendet wird, um den darunterliegenden Produktionsdienst in derartigen Cloud-Computing-Regionen bereitzustellen.
Wie dargestellt, beginnt das Verfahren 1000 bei Schritt 1005, wo das LPT-Tool (oder die Meta-Pipeline) die Gegenwart einer neuen Cloud-Computing-Region erkennt, in der ein Produktionsdienst unter Verwendung einer kontinuierlichen Deployment-Pipeline bereitgestellt werden kann. Eine derartige Pipeline kann unter Verwendung einer LPT-Instanz modelliert werden, die einer Live-Pipeline-Vorlage entspricht. Bei Schritt 1010 ermittelt das LPT-Tool, ob die neue Region die Blattsysteme oder Dienste hostet, die erforderlich sind, um den Produktionsdienst zu unterstützen. Zusätzlich kann das LPT-Tool ermitteln, ob die neue Cloud-Computing-Region die Blattsysteme und Dienste hostet, die durch die Deployment-Pipeline gefordert werden. Das heißt, das LPT-Tool bestätigt, dass die Blattsystemkomponenten einer Deployment-Pipeline, auf die durch eine Anwendungsdefinition verwiesen wurde, in der neuen Cloud-Computing-Region verfügbar sind.
Bei Schritt 1015 ermittelt die LPT, ob jedwede Dienstabhängigkeiten, die mit dem Produktionsdienst assoziiert sind, in einer neuen Cloud-Computing-Region verfügbar sind. Zusätzlich kann das LPT-Tool ermitteln, ob irgendwelche Dienstabhängigkeiten, die mit den Blattsystemen oder Diensten assoziiert sind, die zum Erstellen und Einführen der Deployment-Pipeline erforderlich sind, in der neuen Cloud-Computing-Region verfügbar sind. Das heißt, zusätzlich zum Bestätigen, dass die Blattsysteme und Dienste, auf die ausdrücklich in der Anwendungsdefinition verwiesen wurde, verfügbar sind (Schritt 1010), bestätigt das LPT-Tool, dass jedwede Abhängigkeiten, die mit derartigen Blattsystemen und Diensten assoziiert sind, in der neuen Cloud-Computing-Region sowohl für einen Produktionsdienst als auch eine Deployment-Pipeline verfügbar sind, die verwendet wird, um diesen Produktionsdienst bereitzustellen.
Bei Schritt 1020 testet das LPT-Tool auf der Grundlage der Schritte 1010 und 1015, ob die Blattsysteme und Dienste (und Dienstabhängigkeiten) sowohl für die Deployment-Pipeline als auch für den darunterliegenden Produktionsdienst in der neuen Cloud-Computing-Region verfügbar sind. Ist dies nicht der Fall, endet das Verfahren 1000, da der neue Rechendienst weder die Anforderungen der Deployment-Pipeline noch des darunterliegenden Produktionsdienstes (oder beide) erfüllt. Natürlich können Protokolldaten oder andere Meldungen erzeugt und an ein Entwicklungs-/Betriebsteam gesendet werden, aus denen die Verfügbarkeit der neuen Cloud-Computing-Region hervorgeht. Derartige Meldungen könnten anzeigen, welches Blattsystem, welcher Dienst oder welche Abhängigkeiten davon nicht erfüllt wurden und eine Live-Pipeline-Vorlage dementsprechend daran gehindert haben, dazu verwendet zu werden, eine Deployment-Pipeline in der neuen Cloud-Computing-Region einzuführen.
11 veranschaulicht ein Beispiel für Komponenten eines LPT-Synthesetreibers 1100, die verwendet werden, um Rechenressourcen in einem Blattsystem 1130 zu konfigurieren, bereitzustellen und zu prüfen, das als Teil der Bereitstellung eines Produktionsdienstes verwendet wird, entsprechend einer Ausführungsform. Wie dargestellt, gehören zum LPT-Synthesetreiber 1100 eine die Anwendungsdefinition zerlegende Komponente 1105, eine Komponente zum Prüfen des Blattsystems 1110, eine Blattsystemsteuerung 1115 und ein Satz Dienstabhängigkeitsdaten 1120.
Die die Anwendungsdefinition zerlegende Komponente 1105 bietet ein Softwareelement des LPT-Synthesetreibers 1100, das verwendet wird, um relevante Abschnitte einer Anwendungsdefinition zu erkennen. In Anbetracht einer Anwendungsdefinition interpretiert die zerlegende Komponente 1105 die Abschnitte, die die Konfiguration des Blattsystems 1130 beschreiben, die dem LPT-Synthesetreiber 1100 entspricht, und ignoriert andere Abschnitte der Anwendungsdefinition. Beispielsweise kann die zerlegende Komponente für eine Anwendungsdefinition, die als ein JSON-Dokument erstellt wurde, das JSON-Dokument nach Schlüsselwerten durchsuchen, die durch die zerlegende Komponente 1105 erkannt werden. Nach dem Erkennen kann die zerlegende Komponente 1105 die gewünschte Konfiguration für das Blattsystem 1130 aus den JSON-Elementen extrahieren, die mit den erkannten Schlüsselwerten assoziiert sind. Nehmen wir beispielsweise an, das Blattsystem 1130 entspricht einem Bereitstellungsdienst, der durch einen Cloud-Computing-Anbieter gehostet wird. In einem derartigen Fall könnte die zerlegende Komponente 1105 JSON-Elemente erkennen, die die gewünschten Bereitstellungsstufen in einer Deployment-Pipeline beschreiben, wie etwa die drei Wellen von gamma-, One-Box- und Produktionsstufen für die Cloud-Computing-Regionen aus 6 mit niedrigem Verkehrsaufkommen, hohem Verkehrsaufkommen und mittlerem Verkehrsaufkommen.
Die Komponente zum Prüfen des Blattsystems 1110 bietet ein Softwareelement des LPT-Synthesetreibers 1100, das auf das Blattsystem 1130 zugreifen und einen aktuellen Konfigurationszustand, aktuelle Parameter, einen aktuellen Betriebszustand, aktuelle Leistungsmetriken oder -eigenschaften oder andere relevante Attribute oder Eigenschaften des Blattsystems 1130 erkennen kann. Die Komponente zum Prüfen des Blattsystems 1110 kann während einem nachstehend beschriebenen LPT-Analyseverfahren verwendet werden. Bei einer Ausführungsform kann die Komponente zum Prüfen des Blattsystems 1110 API-Aufrufe aufrufen, die durch API des Blattsystems 1125 dargelegt werden, um auf das Blattsystem 1130 zuzugreifen, dieses abzufragen oder zu prüfen. Unter weiterer Bezugnahme auf das Beispiel eines Bereitstellungsdienstes könnte die Komponente zum Prüfen des Blattsystems 1110 API des Blattsystems 1125 aufrufen, um zu erkennen, welche Stufen in einer Deployment-Pipeline vorhanden sind, welche Bedingungen zu einem Erfolg oder Misserfolg in jeder Stufe führen, welche Überwachungsalarme, Zurückrollbedingungen oder Leistungsüberwachungseinheiten für jede Stufe eingerichtet sind usw.
Die Blattsystemsteuerung 1115 bietet ein Softwareelement des LPT-Synthesetreibers 1100, das das Blattsystem 1130 auffordern kann, die Konfiguration oder den Betriebszustand des Blattsystems 1130 nach Bedarf zu modifizieren, um eine Sollkonfiguration durchzusetzen, die aus der Anwendungsdefinition von der Komponente 1105 zerlegt wurde. Hierfür kann die Blattsystemsteuerung 1115 API-Aufrufe 1125 aufrufen, um den Sollkonfigurationszustand des Blattsystems 1130 weiterzuleiten.
Unter weiterer Bezugnahme auf das Beispiel eines Bereitstellungsdienstes könnte die Blattsystemsteuerung 1130 fordern, dass der Bereitstellungsdienst eine Produktionsbereitstellungsstufe modifiziert, um einen niedrigeren Grenzwert für das Zurückrollen einer Bereitstellung auf der Grundlage einer Leistungsmessung zu erhalten (z. B. die mittlere Latenzzeit einer Reaktion auf Anfragen vom Client). Eine derartige Modifikation könnte als Reaktion auf eine Änderung der besten Vorgehensweisen erfolgen, die in einer Basisvorlage des Unternehmens erfasst sind, die im Rahmen der Erstellung der LPT-Instanz für eine Deployment-Pipeline verwendet wird. In einem derartigen Fall könnte eine Meta-Pipeline eine derartige Änderung (über die zerlegende Komponente 1105) erkennen, die geänderte Konfiguration an das Blattsystem 1130 weiterleiten (über die Steuerungskomponente 1110 und API 1125) und bestätigen, dass die Änderungen durchgesetzt wurden.
Dienstabhängigkeitsdaten 1120 erkennen, welche Blattsysteme in einer Deployment-Pipeline konfiguriert und verfügbar sein sollten, bevor der Blattsystemtreiber 1110 das Blattsystem 1130 prüft oder konfiguriert. Das heißt, dass die Dienstabhängigkeitsdaten 1120 erkennen, welche Blattsysteme, das Blattsystem 1130 ausgenommen, in einer Deployment-Pipeline vollständig konfiguriert sein müssen, bevor das Blattsystem 1130 selbst konfiguriert wird. Unter erneuter weiterer Bezugnahme auf das Beispiel eines Bereitstellungsdienstes könnten die Dienstabhängigkeitsdaten darauf hinweisen, dass jedwede Alarme oder Leistungsüberwachungseinheiten, die von jeder Bereitstellungsstufe einer Deployment-Pipeline benötigt werden, über den Bereitstellungsdienst konfiguriert sind, bevor der Blattsystemtreiber auf das Blattsystem 1130 zugreift oder dieses modifiziert.
Zusätzlich zum vorstehend beschriebenen LPT-Syntheseverfahren kann das LPT-Tool zudem ein LPT-Analyseverfahren durchführen, um die Konfiguration einer Deployment-Pipeline für eine bestimmte Produktionsanwendung oder einen bestimmten Produktionsdienst zu bewerten, egal ob diese Anwendung oder dieser Dienst unter Verwendung einer Live-Pipeline-Vorlage oder unter Verwendung des vorstehend beschriebenen LPT-Syntheseverfahrens bereitgestellt wurde. Zudem kann, wenngleich vorstehend als ein LPT-Synthesetreiber beschrieben, der LPT-Synthesetreiber bei einer Ausführungsform die Komponente zum Prüfen des Blattsystems 1110 umfassen, um die nachstehend näher beschriebene Funktion eines LPT-Analysetreibers bereitzustellen. Dementsprechend können, während die LPT-Synthesetreiber und LPT-Analysetreiber in der vorliegenden Schrift der Einfachheit halber getrennt beschrieben sind, die in der vorliegenden Schrift erörterten LPT-Synthesetreiber und LPT-Analysetreiber als ein integrierter LPT-Synthese- und -Analysetreiber umgesetzt sein.
12 ist ein konzeptionelles Diagramm, das Komponenten eines LPT-Dienstes 1220 veranschaulicht, die ein LPT-Analyseverfahren durchführen, das verwendet wird, um die Konfiguration einer Deployment-Pipeline 1229 zu bewerten, die selbst verwendet wird, um einen Produktionsrechendienst 1223 entsprechend einer Ausführungsform bereitzustellen und zu aktualisieren. Wie dargestellt, wird der Produktionsdienst 1223 in einer globalen Computing-Cloud 1200 gehostet. Der Produktionsdienst 1223 selbst umfasst eine Sammlung von Instanzen der VM 1224, die eine Client-Anwendung 1227 hosten. Der Produktionsdienst 1223 umfasst zudem einen Lastverteiler 1225, Speicherdienste 1228 und Datenbankdienste 1226. Beispielsweise könnte der Produktionsdienst 1223 eine Einzelhandelswebseite bereitstellen, wie unter Bezugnahme auf 1 beschrieben. Zudem könnten Instanzen der Systeme und Dienste, die verwendet werden, um den Produktionsdienst 1223 bereitzustellen, in mehreren Cloud-Computing-Regionen der globalen Computing-Cloud 1200 bereitgestellt werden, z. B. Produktionsdienst 125 in Region 120, ein Produktionsdienst 135 in Region 130 und ein Produktionsdienst 145 in Region 140, die alle in 1 dargestellt sind.
In diesem Beispiel kann der Produktionsdienst 1223 unter Verwendung der Deployment-Pipeline 1229 bereitgestellt und aktualisiert werden. Die Deployment-Pipeline 1229 kann eine Folge von Diensten und Systemen umfassen, die in der globalen Computing-Cloud 1200 verfügbar sind und verwendet werden, um die Rechendienste 1224-1228 in der globalen Computing-Cloud 1200 zu konfigurieren, bereitzustellen und einzuführen. Zusätzlich, wenn ein Entwicklungsteam die Client-Anwendung 1227 oder eine gewünschte Konfiguration für die Rechendienste 1224-1228 aktualisiert, kann die Deployment-Pipeline 1229 derartige Änderungen auf den Produktionsdienst 1223 übertragen.
Für dieses Beispiel gehen wir davon aus, dass ein Entwickler die Systeme und Dienste manuell konfiguriert und bereitstellt, die durch die Deployment-Pipeline 1229 verwendet werden. In einem derartigen Fall kann die Deployment-Pipeline 1229 einen Mangel an einigen der besten Vorgehensweisen, Sicherheitsmechanismen, Bereitstellungsstufen, Zurückrollfähigkeiten usw. aufweisen, die ein Unternehmen oder ein Geschäftsbereich bevorzugt, das/der den Produktionsdienst 1223 verwaltet - oder kann schlicht unvollständig oder falsch konfiguriert sein.
Bei einer Ausführungsform kann der LPT-Dienst 1220, der in der globalen Computing-Cloud 1200 gehostet wird, so konfiguriert sein, dass er die Deployment-Pipeline 1229 prüft, um jedwede Unterschiede zwischen einer bevorzugten Konfiguration für die Deployment-Pipeline 1229 und dem Istkonfigurationszustand der Deployment-Pipeline 1229 zu erkennen. Wie dargestellt, gehören zum LPT-Dienst 1230 das LPT-Tool 1232, die Anwendungsdefinition 1234, das Pipeline-Analysetool 1236, die Regeln 1238 und der LPT-Analysebericht 1240. Bei einer Ausführungsform kann das LPT-Tool 1232 eine „Ground-Truth“-Anwendungsdefinition 1234 erstellen, die die Deployment-Pipeline 1229 entsprechend demselben strukturierten Austauschformat beschreibt, das auch für das LPT-Syntheseverfahren verwendet wurde, z. B. ein JSON-formatiertes Dokument.
Zudem kann der LPT-Dienst 1230 eine Sammlung von LPT-Analysetreibern umfassen (z. B. der LPT-Synthesetreiber 1100 aus 11 mit der Prüfkomponente 1110). Bei einer Ausführungsform wird jeder LPT-Analysetreiber verwendet, um auf einen Dienst oder ein System zuzugreifen, der/das selbst als Teil der Deployment-Pipeline 1229 und dazu verwendet wird, einen aktuellen Konfigurationszustand dieses Dienstes oder Systems zu ermitteln. Auf der Grundlage der aktuellen Konfiguration kann der LPT-Analysetreiber einen Abschnitt der Anwendungsdefinition 1234 erstellen, der entsprechend dem Austauschformat formatiert ist. Sobald jeder LPT-Analysetreiber die Deployment-Pipeline 1229 bewertet hat, kann die resultierende Anwendungsdefinition 1234 an das Pipeline-Analysetool 1236 weitergeleitet werden.
Die Pipeline-Analyse 1236 kann wiederum die Anwendungsdefinition 1234 gegen einen Regelsatz 1238 bewerten. Die Regeln 1238 können verwendet werden, um die besten Vorgehensweisen oder Konfigurationsanforderungen für eine Deployment-Pipeline zu erfassen. Das heißt, die Regeln 1238 können verwendet werden, um sicherzustellen, dass die Deployment-Pipeline 1229 die besten Vorgehensweisen einhält, die durch ein Unternehmen für Deployment-Pipelines aufgestellt wurden. Einige der Regeln 1238 könnten auf alle Deployment-Pipelines angewendet werden, die von einem Unternehmen verwendet werden, um Produktionsdienste bereitzustellen und zu warten, wohingegen andere Regeln spezifisch für einen bestimmten Diensttyp sein könnten.
Bei einer Ausführungsform könnten die Regeln 1238 nach Aspekten einer Deployment-Pipeline modelliert werden, die durch die Basisvorlage 305 des Unternehmens vorgegeben sind. Gleichermaßen könnten die Regeln 1238 für einen bestimmten Diensttyp nach Aspekten der Diensttypvorlage 310 modelliert werden (jeweils vorstehend unter Bezugnahme auf 3 erörtert). Beispielsweise könnte eine unternehmensweite Regel 1238 vorgeben, dass jede Deployment-Pipeline gamma- und One-Box-Teststufen als Teil jeder Produktionsbereitstellungsstufe enthält. Gleichermaßen könnte eine andere Regel 1238 fordern, dass eine automatische Zurückrollüberwachungseinheit für die One-Box- und Produktionsstufen in der Deployment-Pipeline konfiguriert wird. In diesem letzteren Fall könnte eine dienstspezifische Regel 1238 verwendet werden, um die Mindestleistungsgrenzen vorzugeben, die auf Produktionssysteme angewendet werden sollten, bevor die Zurückrollmechanismen ausgelöst und eine Bereitstellung unterbrochen werden, die die Mindestleistungsgrenzen nicht erfüllt. Natürlich wird ein Fachmann erkennen, dass der wesentliche Teil der Regeln 1238 auf der Grundlage der Bedürfnisse und Vorgehensweisen eines Unternehmens, der Dienste, die zum Erstellen einer Deployment-Pipeline verfügbar sind, der Diensttypen, die durch eine Deployment-Pipeline bereitgestellt werden, und der Umstände eines bestimmten Falls maßgeschneidert sein können.
Nach dem Bewerten der Anwendungsdefinition 1234 kann die Pipeline-Analyse 1236 einen LPT-Analysebericht 1240 erstellen. Der LPT-Analysebericht 1240 kann einen Hinweis auf die aktuelle Konfiguration der Deployment-Pipeline 1229 geben (auf der Grundlage der „Ground-Truth“-Anwendungsdefinition 1234), neben einem Hinweis darauf, welche Regeln 1238 durch die bereitgestellte Pipeline 1229 erfüllt oder nicht erfüllt werden. Zusätzlich zum Offenlegen jedweder Kritik an der Deployment-Pipeline, wie etwa Regelverstöße oder Warnungen hinsichtlich des Konfigurationszustandes der Deployment-Pipeline 1229, kann der LPT-Analysebericht 1240 auch vorgeben, welche Aktionen oder Änderungen an der Konfiguration der Deployment-Pipeline 1230 durchgeführt werden sollten, um einen bestimmten Regelverstoß zu beheben. Beispielsweise könnte der LPT-Analysebericht 1240 Änderungen an der Anzahl, der Reihenfolge oder dem Typ der Teststufen in einer Deployment-Pipeline, der Konfiguration und Werte für Zurückrollüberwachungseinheiten, Alarme hinsichtlich Leistungsmetriken, die Typen von Systemen und Diensten, die in der Deployment-Pipeline enthalten sind, usw. empfehlen
Zudem könnte der LPT-Dienst 1230 bei einer Ausführungsform eine „Ein-Klick-Behebung“ für Regelverstöße vorsehen, die in der Deployment-Pipeline 1226 gefunden wurden. In einem derartigen Fall könnte der LPT-Analysebericht 1240 eine Korrekturmaßnahme im Zusammenhang mit einem bestimmten Regelverstoß vorgeben. Auf Anfrage von einem Entwickler könnte der LPT-Dienst 1230 anschließend Abschnitte der „Ground-Truth“-Anwendungsdefinition 1234 (oder den Quellcode der darunterliegenden Live-Pipeline-Vorlage) modifizieren, um einen Regelverstoß zu beheben, der im Rahmen des LPT-Analyseberichts 1240 aufgeführt wurde. Als Reaktion darauf könnte der LPT-Dienst 1230 das vorstehend beschriebene LPT-Syntheseverfahren verwenden, um Änderungen an der modifizierten Anwendungsdefinition 1234 (oder Änderungen an der darunterliegenden LPT-Instanz) auf die Deployment-Pipeline 1229 zu verbreiten.
Bei einer anderen Ausführungsform könnte die Pipeline-Analyse 1236 die „Ground-Truth“-Anwendungsdefinition mit einer anderen Anwendungsdefinition vergleichen und einen LPT-Analysebericht 1250 erstellen, der jedwede Unterschiede widerspiegelt. Beispielsweise könnte ein Entwickler eine Diensttyp-Live-Pipeline-Vorlage auswählen, die mit einem Diensttyp übereinstimmt oder kompatibel ist, der mit dem Produktionsdienst 1223 assoziiert ist. Als Reaktion darauf könnte die Pipeline-Analyse 1236 eine Anwendungsdefinition, die unter Verwendung dieser Live-Pipeline-Vorlage erstellt wurde, mit der „Ground-Truth“-Anwendungsdefinition 1234 vergleichen. In einem anderen Fall könnte die „Ground-Truth“-Anwendungsdefinition 1234 mit einer Anwendungsdefinition verglichen werden, die verwendet wird, um die Deployment-Pipeline 1234 zu erstellen. Dadurch könnten Änderungen erkannt werden, die direkt an einer Deployment-Pipeline 1229 durchgeführt wurden und im Widerspruch mit einer LPT-Instanz und einer entsprechenden Anwendungsdefinition stehen, die verwendet wurde, um die Deployment-Pipeline 1229 zu erstellen. In beiden Fällen könnte der LPT-Analysebericht 1234 erstellt werden, um jedwede Unterschiede zwischen den Konfigurationen, die durch die Anwendungsdefinitionen dargestellt werden, als mögliche Probleme zu erkennen, die in der Deployment-Pipeline 1229 angegangen und behoben werden müssen.
Zudem könnte der LPT-Analysebericht bei einer Ausführungsform ebenfalls eine Live-Pipeline-Vorlage vorschlagen, mit der die Deployment-Pipeline 1229 konkretisiert und die mit dieser verwendet werden kann. Dadurch könnte ein Entwicklungsteam die Deployment-Pipeline 1229 unter die Kontrolle des Quellcodes des LPT-Syntheseverfahrens stellen und damit beginnen, die Konfiguration der Deployment-Pipeline 1229 unter Verwendung einer Meta-Pipeline zu warten. Beispielsweise könnte die Pipeline-Analyse 1236 die „Ground-Truth“-Anwendungsdefinition 1234 mit Anwendungsdefinitionen vergleichen, die auf der Grundlage anderer LPT-Vorlageninstanzen erstellt oder auf hochrangigeren Basis- oder Diensttypvorlagen modelliert wurden. Je nach Ähnlichkeiten zwischen Anwendungsdefinitionen, könnte die Pipeline-Analyse 1236 eine Empfehlung einer Live-Pipeline-Vorlage in den LPT-Analysebericht 1240 einfügen, die der „Ground-Truth“-Konfiguration der Deployment-Pipeline 1229 am nächsten kommt oder anderweitig mit dieser kompatibel ist.
13 veranschaulicht Komponenten der Pipeline-Analyse 1236, die verwendet werden, um das LPT-Analyseverfahren entsprechend einer Ausführungsform durchzuführen. Wie dargestellt, gehören zur Pipeline-Analyse 1236 eine Komponente zum Vergleichen von Unterschieden 1300, eine Regelbewertungskomponente 1305, eine Empfehlungskomponente 1310 und eine Berichtskomponente 1315. Die Komponenten 1300-1315 stellen in der Regel Softwareelemente der Pipeline-Analyse 1236 bereit, die verwendet werden, um den Konfigurationszustand der Deployment-Pipeline 1229 zu bewerten und zu melden.
Die Komponente zum Vergleichen von Unterschieden 1300 stellt ein Softwareelement der Pipeline-Analyse 1236 bereit, das so konfiguriert ist, dass es eine Anwendungsdefinition mit einer anderen vergleicht und Unterschiede der Deployment-Pipelines erkennt, die durch die miteinander verglichenen Anwendungsdefinitionen dargestellt werden. Beispielsweise kann die Komponente zum Vergleichen von Unterschieden 1300 den strukturierten Inhalt für ein bestimmtes Blattsystem in verschiedenen Anwendungsdefinitionen miteinander vergleichen und einen Bericht erstellen, der jedwede Unterschiede in der Konfiguration des bestimmten Blattsystems beschreibt. Der Prozess kann für jede Blattsystemkomponente in der Deployment-Pipeline 1229 wiederholt werden. Wie erwähnt, könnte ein Entwicklungsteam dadurch verstehen, welche Änderungen an einer funktionsfähigen Deployment-Pipeline vorgenommen werden müssen, um die betriebsfähige Deployment-Pipeline unter die Kontrolle einer Live-Pipeline-Vorlage zu stellen. In anderen Fällen könnte der Vergleich verwendet werden, um Änderungen zu erkennen, die direkt an einer Deployment-Pipeline durchgeführt wurden, die ursprünglich unter Verwendung des LPT-Syntheseverfahrens konfiguriert wurde. In noch anderen Fällen könnte die Komponente zum Vergleichen von Unterschieden 1300 mehrere potentielle Deployment-Pipelines, die auf der Grundlage von möglichen Pipeline-Vorlagen erstellt wurden, mit einer Ist-Deployment-Pipeline vergleichen, um mögliche Pipeline-Vorlagen zu finden, die verwendet werden sollten, um die Ist-Deployment-Pipeline unter die Kontrolle des Quellcodes zu stellen.
Die Regelbewertungskomponente 1305 stellt ein Softwareelement der Pipeline-Analyse 1236 bereit, das ermitteln kann, ob eine Anwendungsdefinition einem Satz aus einer oder mehreren Regeln entspricht. Bei einer Ausführungsform könnte die durch die Komponente 1305 bewertete Anwendungsdefinition den „Ground-Truth“-Zustand einer Ist-Deployment-Pipeline darstellen. Dadurch könnte ein Entwicklungs-/Betriebsteam verstehen, wie gut eine verwendete Deployment-Pipeline einem Satz von besten Vorgehensweisen oder Richtlinien entspricht. Gleichermaßen könnte die Regelbewertungskomponente einem Entwicklungs-/Betriebsteam dabei behilflich sein, eine Deployment-Pipeline zu diagnostizieren, die nicht bestimmungsgemäß arbeitet. In einem anderen Fall könnte die Regelbewertungskomponente 1305 eine Anwendungsdefinition bewerten, die auf der Grundlage einer LPT-Instanz erstellt wurde, die nicht verwendet wurde, um eine Deployment-Pipeline zu erstellen. Dadurch könnte ein Entwickler verstehen, ob eine mögliche Pipeline-Vorlage jedweden besten Vorgehensweisen oder betrieblichen Anforderungen entspricht, die sich in dem Regelsatz widerspiegeln.
Die Regelempfehlungskomponente 1310 stellt ein Softwareelement der Pipeline-Analyse 1236 bereit, das einem Entwicklungsteam dabei behilflich sein kann, Elemente der Bereitstellung zu modifizieren, die nicht einer bestimmten Regel entsprechen. Wie erwähnt könnte die Empfehlung Änderungen an einer bereitgestellten Pipeline vorschlagen, um diese in Einklang mit Vorgehensweisen im Unternehmen zu bringen oder Probleme in einer Deployment-Pipeline anzugehen, die nicht korrekt arbeitet. Zudem könnte der LPT-Dienst einem Entwickler erlauben, Änderungen auf Anfrage umzusetzen, die durch die Empfehlungskomponente 1310 vorgeschlagen wurden.
In einem anderen Fall könnten die Ergebnisse der Bewertungskomponente in einen Freigabeablauf integriert werden, der mit einer manuell konfigurierten Deployment-Pipeline assoziiert ist. In einem derartigen Fall könnte der Freigabeablauf eine Deployment-Pipeline auf der Grundlage eines individuell anpassbaren Schweregrades beliebiger Regelverstöße blockieren, die durch die Pipeline-Analyse 1236 erkannt wurden.
Die Berichtskomponente 1315 stellt ein Softwareelement bereit, das im Allgemeinen so konfiguriert ist, dass es Berichte anhand der Informationen erstellt, die durch die Komponente zum Vergleichen von Unterschieden 1300, die Regelbewertungskomponente 1305 und die Empfehlungskomponente 1310 erzeugt wurden. Beispielsweise veranschaulicht 14 eine beispielhafte Schnittstelle 1400, die einen LPT-Analysebericht für eine kontinuierliche Deployment-Pipeline entsprechend einer Ausführungsform darstellt. Wie dargestellt gehört zur Schnittstelle 1400 eine Sammlung von Feldern, die verwendet werden, um Informationen darzustellen, die durch die Berichtskomponente 1315 der Pipeline-Analyse erzeugt wurden. Wie dargestellt, gehört zur Schnittstelle 1400 ein Dienstdatenfeld 1405, aus dem die relevante Deployment-Pipeline, der assoziierte Produktionsdienst und die LPT-Instanz hervorgehen, die unter Verwendung der Pipeline-Analyse bewertet wurden. In diesem Beispiel werden die Dienstdaten auf dem Quellcode einer LPT-Instanz modelliert, die in 4 dargestellt ist.
Ein Risikoberichtfeld 1410 zeigt eine Reihe von Ergebnissen, die durch die Bewertungskomponente 1305 beim Bewerten der Istkonfiguration der Deployment-Pipeline erzeugt wurden, die im Feld 1405 erkannt wurde. In diesem konkreten Beispiel geht aus dem Risikobericht hervor, dass bei einer Deployment-Pipeline in der Rechenregion US-Ost eine Zurückrollüberwachungseinheit für eine Produktionsstufe fehlt und dass bei einer Deployment-Pipeline in der Rechenregion US-West ein Test in der gamma-Stufe in einer von zwei Verfügbarkeitszonen in der Rechenregion US-West fehlt. Ein Schweregradfeld 1415 deutet darauf hin, dass die fehlende Zurückrollüberwachungseinheit in der Rechenregion US-Ost ein größeres Risiko für den Produktionsdienst in dieser Region darstellt als der fehlende Test in der gamma-Stufe in einer von zwei Verfügbarkeitszonen in der Rechenregion US-West. Ein Korrekturfeld 1415 zeigt eine empfohlene Korrektur, die für jedes der beiden Risiken verfügbar ist, die durch die Pipeline-Analyse 1326 erkannt wurden. In diesem konkreten Beispiel besteht die empfohlene Korrektur lediglich darin, die fehlenden Komponenten hinzuzufügen, d.h. die fehlende Zurückrollüberwachungseinheit der Deployment-Pipeline in der Region US-Ost und die fehlende gamma-Stufe der entsprechenden Verfügbarkeitszone in der Region US-West hinzuzufügen. Zusätzlich gehört zur Schnittstelle 1400 ein Feld „click2fix“, durch das ein Entwickler die empfohlene Korrektur auf diese Deployment-Pipelines anwenden kann. Wird diese Funktion verwendet, können die vorstehend erörterten LPT-Synthesetechniken verwendet werden, um die durch die Pipeline-Analyse 1326 erkannten Regelverstöße automatisch zu beheben.
Zusätzlich zum Risikobericht 1410, aus dem Risiken hervorgehen können, die mit Regeln assoziiert sind, denen eine Deployment-Pipeline nicht entspricht, wird das Unterschiedsberichtfeld 1430 verwendet, um die Ergebnisse eines Vergleichs von Unterschieden zwischen zwei Anwendungsdefinitionen anzuzeigen. Wie dargestellt wurde die Istinstanz der Deployment-Pipeline in der Region US-Ost mit der LPT-Instanz verglichen, die zum Erstellen dieser Deployment-Pipeline verwendet wurde. Zudem entspricht in diesem Beispiel die Istkonfiguration der durch die LPT-Instanz vorgegebenen Konfiguration. Eine Schaltfläche zum Vergleichen von Änderungen 1435 kann verwendet werden, um auszuwählen, welche bereitgestellten Pipelines, Anwendungsdefinitionen oder LPT-Instanzen miteinander verglichen werden, um den Unterschiedsbericht 1430 zu erstellen.
15 ist ein konzeptionelles Diagramm, das einen Datenstrom für eine Live-Pipeline-Vorlagenanalyse veranschaulicht, das verwendet wird, um eine Deployment-Pipeline zu bewerten, die verwendet wird, um einen Produktionsrechendienst bereitzustellen, entsprechend einer Ausführungsform. Wie dargestellt, wird ein LPT-Tool 1515 verwendet, um eine Konfiguration einer Deployment-Pipeline 1530 im bereitgestellten Zustand zu prüfen. Das LPT-Tool 1515 verwendet die Konfiguration im bereitgestellten Zustand, um eine Anwendungsdefinition 1510 zusammenzustellen, die die Konfiguration im bereitgestellten Zustand beschreibt. Das Pipeline-Analysetool 1509 wiederum kann die Anwendungsdefinition 1510, die die Konfiguration im bereitgestellten Zustand darstellt, gegen einen Regelsatz bewerten, sowie die Anwendungsdefinition 1510 mit anderen vergleichen. Das heißt, während dem LPT-Analyseverfahren greift das LPT-Tool 1515 auf die Dienste und Systeme zu und prüft diese, die als Teil der Deployment-Pipeline 1530 enthalten sind, um ein umfassendes Modell zu erstellen, das den Istkonfigurationszustand der Deployment-Pipeline 1530 widerspiegelt. Nach dem Ermitteln kann die resultierende Anwendungsdefinition 1510 unter Verwendung einer Vielzahl von Ansätzen bewertet werden, um Stärken, Schwächen oder andere qualitative oder quantitative Metriken über den Konfigurationszustand der Deployment-Pipeline 1530 zu erkennen.
Bei einer Ausführungsform kann, wie die Anwendungsdefinition 510, die im Rahmen des in 5 veranschaulichten LPT-Syntheseverfahrens erzeugt wurde, die Anwendungsdefinition 1510, die im Rahmen des in 15 veranschaulichten LPT-Analyseverfahrens erzeugt wurde, als ein Ruby-Modell definiert werden, das ein strukturiertes Dokument impliziert (z. B. ein JSON-Dokument 1512). Durch das Formatieren der Anwendungsdefinition 1510 unter Verwendung desselben Austauschformates, das auch im Rahmen des LPT-Syntheseverfahrens verwendet wurde, wird sichergestellt, dass die Softwarekomponenten des LPT-Tools 1515 und des Pipeline-Analysetools 1509 eine Anwendungsdefinition verarbeiten können, egal ob diese unter Verwendung eines der LPT-Syntheseverfahren oder LPT-Analyseverfahren erstellt wurde, ohne jedwede Übersetzungen oder Transformationen vornehmen zu müssen.
Das JSON Dokument 1512 - namens „DeployedApplication.LPT“ - veranschaulicht einen Abschnitt der Anwendungsdefinition, der von der Deployment-Pipeline 1530 durch die LPT-Analysetreiber 1517-1529 abgeleitet wurde. In dem konkreten Beispiel in 15 gehören zu dem Teil der Anwendungsdefinition 1512 Konfigurationsinformationen für einen Satz „Leistungsmetriküberwachungseinheiten“, die verwendet werden, um den Zustand von virtuellen Maschinenhosts zu überwachen, die Teil eines Datensatzes „Produktion“ sind und in einer Cloud-Computing-Region bereitgestellt werden (namens „US-Ost“). Natürlich können der konkrete Inhalt und die Struktur der im JSON-Dokument 1512 enthaltenen Informationen je nach Fähigkeiten des relevanten Blattsystems, das in der Anwendungsdefinition beschrieben ist, und je nach Bedarf eines bestimmten Falls maßgeschneidert sein.
Wie erwähnt, bietet die Ausgabe des LPT-Tools 1515 eine „Ground-Truth“-Anwendungsdefinition 1510 für die Deployment-Pipeline 1530 auf der Grundlage des Konfigurationszustandes der Blattsysteme, die in der Deployment-Pipeline 1530 enthalten sind. In diesem konkreten Beispiel gehören zur Deployment-Pipeline 1530 sieben darunterliegende Blattsysteme 1532-1544, von denen jedes eine separate Konfiguration aufweist, die in der Anwendungsdefinition 1510 zu modellieren ist. Bei einer Ausführungsform gehört zum LPT-Tool 1515 ein speicherinterner Ruby-Ablauf, der durchgeführt wird, um die Anwendungsdefinition 1510 dadurch zu erstellen, dass die LPT-Analysetreiber 1517-1529 veranlasst werden, die entsprechenden Dienste von den Blattsystemen 1532-1544 abzufragen. Die Schritte des Ablaufs können so konfiguriert sein, dass jeder Schritt erklärt, für welche Teile der Anwendungsdefinition 1510 der Ablauf erwartet, dass diese abgeschlossen sind, bevor ein bestimmter LPT-Analysetreiber 1517-1529 den Betrieb aufnimmt. Beispielsweise kann ein Bereitstellungskonfigurationstreiber 1519, der Informationen zur Bereitstellungsumgebung erzeugt, die in die Anwendungsdefinition 1510 einbezogen werden sollen, erwarten, dass der Pipeline-Treiber 1517 den Pipeline-Dienst 1532 geprüft und der Anwendungsdefinition 1510 vor der Ausführung hinzugefügt hat. Dies kann der Fall sein, da die Pipeline-Konfiguration dem entsprechen kann, was der Treiber 1519 dahingehend ermittelt, auf welche Bereitstellungsumgebungen er im Bereitstellungsdienst 1534 zugreift. Bei einer Ausführungsform wählt ein Abhängigkeitsauflöser des LPT-Tools 1515, welche LPT-Analysetreiber auszuführen sind, bis alle Blattsysteme 1530 vollständig überprüft wurden.
Bei einer Ausführungsform gehört zum LPT-Tool 555 ein Satz LPT-Analysetreiber 1517-1529. Jeder LPT-Analysetreiber 517-529 kann einen Teil der Software bereitstellen, der einem bestimmten der Blattsysteme 1532-1544 entspricht. Zudem kann jeder LPT-Analysetreiber 1517-1529 auf ein entsprechendes Blattsystem 1532-1544 in der Deployment-Pipeline 1530 zugreifen und eine Konfiguration dieses Blattsystems prüfen. Auf der Grundlage der Prüfung stellen die Blattsystemtreiber 1532-1544 Abschnitte der Anwendungsdefinition 1510 zusammen, die für den jeweiligen LPT-Analysetreiber relevant sind, (und ignorieren andere Abschnitte), um eine vollständige Beschreibung der Deployment-Pipeline 530 zu erstellen.
In dem konkreten Beispiel aus 15 gehören zu den LPT-Analysetreibern 1517-1529, die im LPT-Tool 1515 enthalten sind, ein Pipeline-Treiber 1517, ein Bereitstellungstreiber 1519, Hostklassen, Hosts und der Gruppentreiber für die automatische Skalierungsgruppe (ASG) 1521, ein Netzwerk und Sicherheitstreiber 1523, ein Identitäts- und Zugangsverwaltungstreiber (IAM) 1525, ein Leistungsüberwachungstreiber 1527 und ein Alarmüberwachungstreiber 1529.
Der Pipeline-Treiber 1517 kann eine Konfiguration eines Pipeline-Dienstes 1532 ermitteln, die verwendet wird, um ein Quellcodearchiv auf neue Versionen einer Anwendung zu überwachen und den Prozess des Übertragens dieser Anwendung in die Produktion über die Deployment-Pipeline 1530 zu beginnen. Der Bereitstellungstreiber 1519 kann eine Konfiguration des Bereitstellungsdienstes 534 ermitteln. Beispielsweise kann der Bereitstellungstreiber 1519 die Konfiguration im bereitgestellten Zustand für eine Reihe von Teststufen ermitteln, die verwendet werden, um eine Anwendung auf eine Produktionsumgebung zu verbreiten.
Die Hostklassen, Hosts und ASG-Treiber (kurz Host-Treiber 1521) können verwendet werden, um eine Konfiguration für einen Rechendienst 1536 zu ermitteln, der von der Deployment-Pipeline 1530 verwendet wird. Beispielsweise können die Host-Treiber 1521 eine Konfiguration von Instanzen der VM, Skalierungsgruppen und Hostklassen, die durch die Deployment-Pipeline 1530 verwendet werden, ermitteln (oder die durch den Produktionsdienst verwendet werden, der durch die Deployment-Pipeline 1530 verwendet wird). Die Host-Treiber 1521 könnten zudem eine Konfiguration für eine Vielzahl von anderen Rechendiensten 1536 ermitteln, die durch die Deployment-Pipeline 1530 (oder den entsprechenden Produktionsdienst) verwendet werden, z. B. Dienste wie Datenbankdienste, Speicherdienste, Messaging-Dienste, Benachrichtigungsdienste, Ablaufdienste usw.
Der Netzwerk- und Sicherheitstreiber 1523 kann verwendet werden, um eine Netzwerkkonfiguration von Netzwerkdiensten zu ermitteln, die über die Deployment-Pipeline 1530 bereitgestellt werden, wie etwa IP- und SSL-Dienste 1538. Beispielsweise könnte der Netzwerk- und Sicherheitstreiber 1523 eine Konfiguration von IP-Adressen, Domänennameninformationen, Switching- und Routing-Informationen, Regeln zum Erstellen von Firewalls oder Verkehr, Standorte für Edge-Server oder Adressen für CDN usw. empfehlen, die durch die Deployment-Pipeline 1530 verwendet werden. Zudem könnte der Netzwerk- und Sicherheitstreiber 1523 erkennen, welche Sicherheitszertifikate, z. B. SSL-Zertifikate, auf Instanzen der VM und Anwendungen bereitgestellt sind, die durch die Deployment-Pipeline 1530 bereitgestellt werden. Der Identitäts- und Zugriffsverwaltungstreiber (IAM) 1525 kann verwendet werden, um eine Konfiguration von Identitätsdiensten 1540 zu ermitteln, die auf der Deployment-Pipeline 1530 bereitgestellt werden, z. B. eine Konfiguration von Benutzerkonten, Benutzernamen, Zugriffskontrolllisten, Zugriffsregeln usw., auf den Instanzen der VM, durch die Benutzer Zugriff auf die Deployment-Pipeline 1530 erhalten.
Der Leistungsüberwachungseinheittreiber 1527 kann verwendet werden, um eine Konfiguration davon zu ermitteln, welche Leistungsüberwachungseinheiten für die Deployment-Pipeline 1530 konfiguriert wurden. Beispielsweise kann der Leistungsüberwachungseinheittreiber 1527 erkennen, welche Metriken während jeder Vorproduktions- und Produktionsteststufe gemessen werden, die durch den Bereitstellungsdienst 1534 bereitgestellt werden. Gleichermaßen kann der Alarmüberwachungstreiber 1529 eine Konfiguration davon ermitteln, welche Leistungsalarme und -grenzen in der Deployment-Pipeline 1530 konfiguriert sind, und zwar auf der Grundlage der Leistungsmetriken, die durch den Leistungsüberwachungseinheittreiber 1527 konfiguriert sind.
Wie dargestellt, kann die Anwendungsdefinition 1510 an das Pipeline-Analysetool 1509 weitergeleitet werden, das ein Berichtsdokument 1508 erstellen kann, das jedwede Regelverstöße oder Unterschiede zwischen der Anwendungsdefinition 1510 und einer anderen aufführt. In diesem konkreten Beispiel wird der Bericht 1508 zudem unter Verwendung eines Austauschformates (z. B. JSON) zusammengestellt, wodurch er durch ein Veröffentlichungstool 1507 verarbeitet werden kann. Das Veröffentlichungstool 1507 kann wiederum einen Ablaufdienst 1505 und eine LPT-Dienstkonsole 1506 übertragen (oder von diesen gelesene Meldungen ausgeben). Wie dargestellt, beschreibt der Bericht 1508 einen Regelverstoß im Zusammenhang mit einer „fehlenden“ Zurückrollüberwachungseinheit in einer Produktionsteststufe in der Region US-Ost.
Bei einer Ausführungsform kann es sich bei dem Veröffentlichungstool 1507 um einen Dienst handeln, der durch den Cloud-Computing-Anbieter gehostet wird. Ein derartiger Dienst erlaubt es anderen Systemen, sich für den Empfang von Meldungen oder Warnungen über ein bestimmtes Thema anzumelden. Im vorliegenden Zusammenhang kann das Veröffentlichungstool 1507 den Bericht 1508 der LPT-Dienstkonsole 1506 bereitstellen, die eine Schnittstelle erzeugen kann, die den Bericht einem Entwickler anzeigt (z. B. die Schnittstelle 1400 aus 14). Der Ablaufdienst 1505 könnte so konfiguriert sein, dass er automatisch Berichte verarbeitet, die durch das Veröffentlichungstool 1507 für eine Sammlung von Deployment-Pipelines veröffentlicht wurden, und Meldungen im Hinblick auf die „Gesamtgesundheit“ der Deployment-Pipeline sendet, die durch ein Unternehmen verwendet wird. Natürlich könnten andere Systeme und Dienste den Bericht 1508 verarbeiten, der durch das Veröffentlichungstool 1507 veröffentlicht wurde. Beispielsweise könnten bei einer Ausführungsform im Bericht 1508 enthaltene Verstöße für eine Korrektur durch das LPT-Tool unter automatischer Verwendung des LPT-Syntheseverfahrens eingeplant (oder zu Prüf- und Freigabezwecken an ein Entwicklungs-/Betriebsteam weitergeleitet) werden.
Es ist zu beachten, dass, wenngleich in den 5 und 15 getrennt veranschaulicht, die LPT-Synthesetreiber 517-1529 in 5 mit den LPT-Analysetreibern 1517-1529 in 15 als kombinierte LPT-Blattsystemtreiber integriert sein können, die die Funktionalität sowohl für das vorstehend beschriebene LPT-Syntheseverfahren als auch das vorstehend beschriebene LPT-Analyseverfahren bereitstellen.
Bei einer Ausführungsform kann das vorstehend beschriebene LPT-Analyseverfahren verwendet werden, um auf Änderungen zu überwachen und bei Änderungen eine Warnung auszugeben, die an einer Deployment-Pipeline durchgeführt wurden, oder um die Konfiguration einer Deployment-Pipeline entweder auf Anfrage oder periodisch zu prüfen. Beispielsweise veranschaulicht 16 ein Verfahren 1600 zum Überwachen einer Deployment-Pipeline unter Verwendung des LPT-Analyseverfahrens entsprechend einer Ausführungsform. Wie dargestellt, beginnt das Verfahren 1600 wenn ein Entwickler eine Überwachungseinheit instanziiert, die verwendet wird, um eine kontinuierliche Deployment-Pipeline zu überwachen, auf die durch die Überwachungseinheit verwiesen wurde. Beispielsweise könnte ein Entwickler nach der Bereitstellung unter Verwendung einer Live-Pipeline-Vorlage einen Überwachungsdienst so konfigurieren, dass dieser jedwede Änderungen erkennt, die an den in der Deployment-Pipeline enthaltenen Blattsystemen durchgeführt wurden. In anderen Fällen könnte das Pipeline-Analysetool so konfiguriert werden, dass es einen Chargenprozess periodisch durchführt, um eine zu diesem Zeitpunkt aktuelle Konfiguration von einer oder mehreren Deployment-Pipelines zu erkennen und zu bewerten.
Bei Schritt 1610 beobachtet die Überwachungseinheit die Deployment-Pipeline, bis sie eine Änderung in einem der überwachten Blattsysteme feststellt. Sobald die Konfiguration von einem der Blattsysteme geändert wird, kann das LPT-Tool bei Schritt 1615 eine Anwendungsdefinition erstellen, die eine aktuelle Konfiguration der Deployment-Pipeline darstellt. In anderen Fällen könnte das LPT-Tool eine Anwendungsdefinition für eine bestimmte Deployment-Pipeline auf Anfrage für einen Entwickler oder periodisch erstellen (z. B. in Abwesenheit einer Anfrage zum Modifizieren der Pipeline oder einer Überwachungseinheit, die die Pipeline beobachtet, oder als Teil einer Überprüfung aller Deployment-Pipelines für einen bestimmten Diensttyp).
Bei Schritt 1620 kann die resultierende Anwendungsdefinition unter Verwendung eines Regelsatzes bewertet werden, der die besten Vorgehensweisen oder betrieblichen Anforderungen für eine kontinuierliche Deployment-Pipeline widerspiegelt. Wie erwähnt, können die Regeln Wenn-Dann-bedingte Anweisungen auf der Grundlage der konfigurierten Blattsysteme in der Deployment-Pipeline oder allgemeine Anforderungen für eine Deployment-Pipeline vorgeben. Bei Schritt 1625 kann das LPT-Tool die bei Schritt 1615 erzeugte Anwendungsdefinition mit einer anderen Anwendungsdefinition vergleichen, wie etwa eine, die auf der Grundlage einer Live-Pipeline-Vorlage erstellt wurde, die verwendet wurde, um die betreffende Deployment-Pipeline zu erstellen, vor der erkannten Änderung.
Bei Schritt 1630 kann das Pipeline-Analysetool einen Bericht erstellen, der jedwede Regelverstöße enthält, die bei Schritt 1620 erkannt wurden, oder Unterschiede zwischen der aktuellen Konfiguration der Deployment-Pipeline und einer Referenzkonfiguration, die für die Deployment-Pipeline erstellt wurde. Wie erwähnt, kann der Bericht in einem Austauschformat erstellt werden, das durch einen Veröffentlichungsdienst verarbeitet wird (oder durch andere Systeme). Bei Schritt 1635 kann das Pipeline-Analysetool Vorschläge für Änderungen an der Deployment-Pipeline erstellen, um einen bei Schritt 1620 erkannten Regelverstoß anzugehen. Alternativ könnte das Pipeline-Analysetool so konfiguriert sein, dass es Rechendienste der Deployment-Pipeline automatisch neu konfiguriert, um jedwede Regelverstöße anzugehen (oder eine Anfrage an einen Administrator sendet, durch die dieser eine Reihe von Modifikationen an der Deployment-Pipeline freigeben soll).
Bei noch anderen Ausführungsformen kann die erneute Konfiguration erfolgen, um einen Konfigurationszustand einer bestimmten Deployment-Pipeline automatisch durchzusetzen, ungeachtet jedweder Regelverstöße. Das heißt, dass das Pipeline-Analysetool so konfiguriert sein kann, dass es Änderungen automatisch rückgängig macht, die an den in einer bestimmten Deployment-Pipeline enthaltenen Rechendiensten durchgeführt wurden. Beispielsweise könnte nach dem Erkennen einer Änderung an einem der Rechendienste, die verwendet werden, um eine Deployment-Pipeline bereitzustellen (d.h. eine Änderung an einem der Blattsysteme), das Pipeline-Analysetool eine Anwendungsdefinition auf der Grundlage der LPT-Instanz erstellen, die verwendet wird, um eine verbindliche Konfiguration für diese Deployment-Pipeline bereitzustellen. Nach dem Erstellen könnten LPT-Synthesetreiber aufgerufen werden, um den Rechendienst entsprechend der vollständig vorgegebenen Konfiguration neu zu konfigurieren, die in der Anwendungsdefinition enthalten ist.
17 veranschaulicht ein Verfahren 1700, mit dem die Konfiguration und Bereitstellung einer kontinuierlichen Bereitstellungs-Pipeline unter die Kontrolle einer Live-Pipeline-Vorlage gestellt werden soll, entsprechend einer Ausführungsform. Wie dargestellt, beginnt das Verfahren 1700 bei Schritt 1705, wo das LPT-Tool eine Anwendungsdefinition erstellt, die der kontinuierlichen Bereitstellungs-Pipeline entspricht. Beispielsweise kann das LPT-Tool eine Anwendungsdefinition für eine Deployment-Pipeline erstellen, die durch einen Entwickler manuell konfiguriert und bereitgestellt wird.
Bei Schritt 1710 kann das LPT-Tool die Eigenschaften der betreffenden Deployment-Pipeline, wie diese in der bei Schritt 1705 erstellten Anwendungsdefinition enthalten sind, mit anderen Anwendungsdefinitionen vergleichen. Jede der anderen im Rahmen der Vergleichs verwendeten Anwendungsdefinitionen kann einer Live-Pipeline-Vorlage entsprechen, die mit generischen instanzspezifischen Parametern konkretisiert werden kann, um der betreffenden Deployment-Pipeline eine LPT-Instanz bereitzustellen. In anderen Fällen können LPT-Instanzen, die vollständig konkretisiert und verwendet wurden, um eine Deployment-Pipeline zu erstellen, in den bei Schritt 1710 durchgeführten Vergleich eingeschlossen werden. Bei einer Ausführungsform können die Ergebnisse des Vergleichs auf ein Maß der Ähnlichkeit oder Kompatibilität zwischen der auf der Grundlage der betreffenden Deployment-Pipeline erstellten Anwendungsdefinition und einer bestimmten der anderen Anwendungsdefinitionen hindeuten. In anderen Fällen könnte ein Entwickler Übereinstimmungskriterien vorgeben, die verwendet werden, um eine Übereinstimmungspunktzahl oder eine Kompatibilität für einen Vergleich zwischen der auf der Grundlage der betreffenden Deployment-Pipeline erstellten Anwendungsdefinition und den anderen Anwendungsdefinitionen zu ermitteln.
Bei Schritt 1715, wenn das LPT-Tool eine kompatible Live-Pipeline-Vorlage erkennt, kann das LPT-Tool bei Schritt 1720 empfehlen, dass die betreffende Deployment-Pipeline unter Verwendung der kompatiblen Live-Pipeline-Vorlage verwaltet wird. Beispielsweise kann ein Entwickler Übereinstimmungskriterien vorgeben, die bei Schritt 175 bewertet werden, um eine kompatible Live-Pipeline-Vorlage zu ermitteln (z. B. eine Übereinstimmung für eine Pipeline für einen bestimmten Diensttyp oder für eine Pipeline mit bestimmten Stufen, Alarmen oder Bereitstellungsverfahren). Bei Schritt 1725, wenn die übereinstimmende Live-Pipeline-Vorlage ausgewählt ist, um die Deployment-Pipeline zu verwalten, kann diese Live-Pipeline-Vorlage verwendet werden, um die Konfiguration der Deployment-Pipeline unter die Kontrolle des Quellcodes zu stellen. Hierfür kann der Entwickler aufgefordert werden, eine oder mehrere Live-Pipeline-Vorlagen der Basisklasse zu konkretisieren, die mit der übereinstimmenden Live-Pipeline-Vorlage mit instanzspezifischen Einzelheiten assoziiert sind, die verwendet werden, um eine LPT-Instanz zu definieren. Die resultierende LPT-Instanz kann verwendet werden, um die Deployment-Pipeline unter Verwendung des LPT-Syntheseverfahrens erneut zu konfigurieren.
18 veranschaulicht ein beispielhaftes Rechensystem 1800, das verwendet wird, um Komponenten des in der vorliegenden Schrift erörterten Live-Pipeline-Vorlagendienstes zu hosten, entsprechend einer Ausführungsform. Wie dargestellt, gehören zum Rechensystem 1800 unter anderem ein Zentralprozessor (CPU) 1805, eine Netzwerkschnittstelle 1815, ein Speicher 1820, und ein Speicher 1830, jeweils mit einem Bus 1817 verbunden. Zu dem Rechensystem 1800 kann zudem eine E/A-Geräteschnittstelle 1810 zum Anschluss von E/A-Geräten 1812 (z. B. Tastatur, Anzeige und Mausgeräte) an das Rechensystem 1800 gehören. Im Zusammenhang mit dieser Offenbarung können die im Rechensystem 1800 dargestellten Rechenelemente einem physischen Rechensystem entsprechen (z. B. ein System in einem Rechenzentrum) oder eine virtuelle Recheninstanz sein, die in einer Computing-Cloud ausgeführt wird. Zudem, wenngleich als auf einem einzelnen Rechenserver 1800 laufend veranschaulicht, können Komponenten im Speicher 1820 und im Speicher 1830 über mehrere Rechenserver bereitgestellt werden.
Der CPU 1805 fragt Programmieranweisungen und Anwendungsdaten ab, die im Speicher 1820 und im Speicher 1830 gespeichert sind. Die Verbindung 1817 wird verwendet, um Programmieranweisungen und Anwendungsdaten zwischen dem CPU 1805, der E/A-Geräteschnittstelle 1810, dem Speicher 1830, der Netzwerkschnittstelle 1815 und dem Speicher 1820 zu übertragen. Es ist zu beachten, dass der CPU 1805 für einen einzelnen CPU, für mehrere CPU, für einen einzelnen CPU mit mehreren Prozessorkernen und dergleichen steht und dass der Speicher 1820 im Allgemeinen für einen Direktzugriffsspeicher steht. Bei dem Speicher 1830 kann es sich um ein Plattenlaufwerk oder eine Flash-Speichervorrichtung handeln. Wenngleich als eine einzelne Einheit dargestellt, kann der Speicher 1830 eine Kombination aus festen und/oder herausnehmbaren Speichervorrichtungen sein, wie etwa feste Plattenlaufwerke, herausnehmbare Speicherkarten, optische Speicher, Netzwerkspeicher (NAS) oder ein Speichernetzwerk (SAN).
Zum Zwecke der Veranschaulichung gehört zum Speicher 1820 ein LPT-Tool 1822, das selbst ein LPT-Synthesetool 1824, ein LPT-Analysetool 1826 und eine Kritisiertool 1828 umfasst. Und der Speicher 1830 enthält ein Vorlagenarchiv 1832 und eine Sammlung von Live-Pipeline-Vorlagen 1835. Wie beschrieben, kann das LPT-Synthesetool Entwicklern im Allgemeinen das Zusammenstellen einer Live-Pipeline-Vorlage 1835 durch Vorgeben einer relativ geringen Menge an Programmquellcode erlauben, der dienstspezifische Daten für eine Instanz der LPT-Vorlage vorgibt. Die übrige Live-Pipeline-Vorlage 1835 umfasst beste Vorgehensweisen zum Konfigurieren, Bereitstellen und Warten einer Instanz des Diensttyps, der der Live-Pipeline-Vorlage entspricht. Sobald ein Entwickler die instanzspezifischen Einzelheiten vorgibt, kann der resultierende Quellcode der LPT-Instanz zusammengestellt und ausgeführt werden, um eine Anwendungsdefinition zu erstellen, die eine vollständig vorgegebene Konfiguration für eine Deployment-Pipeline beschreibt, die durch das LPT-Synthesetool 1824 erstellt wurde. Beispielsweise kann das LPT-Synthesetool 1824 entsprechend der Beschreibung einen Satz LPT-Synthesetreiber enthalten, von denen jeder die relevanten Abschnitte der Anwendungsdefinition liest und ein entsprechendes der Blattsysteme konfiguriert.
In die andere Richtung kann das LPT-Analysetool 1826 die Konfiguration einer verwendeten Deployment-Pipeline prüfen und eine „Ground-Truth“-Anwendungsdefinition erstellen, die den durch die Bereitstellungskonfiguration beobachteten Konfigurationszustand abbildet. Nach der Erstellung kann das Kritisiertool 1828 die „Ground-Truth“-Anwendungsdefinition unter Verwendung eines Regelsatzes bewerten, der verwendet wird, um die besten Vorgehensweisen oder betriebliche Anforderungen zu bestimmen, die durch die Deployment-Pipeline einzuhalten sind.
Die Regeln können für das gesamte Unternehmen gelten, können spezifisch für einen Diensttyp oder anderweitig ausgewählt sein, um den Bedürfnissen in einem bestimmten Fall gerecht zu werden. Zusätzlich kann das Kritisiertool 1828 die „Ground-Truth“-Anwendungsdefinition mit Live-Pipeline-Vorlagen 1835 im Vorlagenarchiv 1832 vergleichen. Dadurch kann eine Quelle für vorgeschlagene Änderungen an der „Ground-Truth“-Anwendungsdefinition bereitgestellt werden, die verwendet wird, um die im Rahmen der kontinuierlichen Deployment-Pipeline verwendeten Blattsysteme vor einer direkten Modifikation durch Entwickler zu schützen, sowie eine der Live-Pipeline-Vorlagen 1835 vorzuschlagen, die verwendet werden könnte, um eine Deployment-Pipeline, die verwendet wird, um einen Produktionsdienst zu verwalten, unter die Kontrolle des Quellcodes einer Live-Pipeline-Vorlage zu stellen.
Vorstehend erfolgt ein Verweis auf in der vorliegenden Offenbarung dargestellte Ausführungsformen. Der Umfang der vorliegenden Offenbarung ist jedoch nicht auf spezifisch beschriebene Ausführungsformen beschränkt. Anstelle dessen wird eine beliebige Kombination der folgenden Merkmale und Elemente, egal ob im Zusammenhang mit verschiedenen Ausführungsformen oder nicht, in Betracht gezogen, um betrachtete Ausführungsformen umzusetzen und zu praktizieren. Darüber hinaus schränkt, wenngleich in der vorliegenden Schrift offenbarte Ausführungsformen Vorteile gegenüber anderen möglichen Lösungen oder gegenüber dem Stand der Technik erzielen können, die Tatsache, ob ein bestimmter Vorteil durch eine bestimmte Ausführungsform erreicht wird oder nicht, den Geltungsbereich der vorliegenden Offenbarung nicht ein. Dementsprechend sind die nachstehenden Aspekte, Merkmale, Ausführungsformen und Vorteile lediglich veranschaulichend und werden nicht als Elemente oder Einschränkungen der beigefügten Patentansprüche betrachtet, außer wenn sie ausdrücklich in einem Patentanspruch/in Patentansprüchen aufgeführt werden. Gleichermaßen soll ein Verweis auf „die Erfindung“ nicht als eine Verallgemeinerung eines in der vorliegenden Schrift offenbarten beliebigen erfindungsgemäßen Gegenstandes ausgelegt und nicht als ein Element oder eine Einschränkung der beigefügten Patentansprüche betrachtet werden, außer wenn sie ausdrücklich in einem Patentanspruch/in Patentansprüchen aufgeführt wird.
Aspekte der vorliegenden Erfindung können die Form einer gänzlich aus Hardware bestehenden Ausführungsform (einschließlich Firmware, systemeigener Software, Mikrocode usw.) oder einer Ausführungsform annehmen, in der Software- und Hardwareaspekte kombiniert sind, die in der vorliegenden Schrift alle allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Zudem können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit darauf ausgebildetem computerlesbaren Programmcode ausgeführt ist.
Es kann eine beliebige Kombination von einem oder mehreren computerlesbaren Medien genutzt werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Ein computerlesbares Speichermedium kann beispielsweise unter anderem ein System, eine Einrichtung oder eine Vorrichtung, das bzw. die nach einem elektronischen, magnetischen, optischen, elektromagnetischen, infrarotbasierten oder halbleiterbasierten Prinzip funktioniert, oder eine beliebige Kombination aus den Vorgenannten sein. Zu konkreteren Beispielen für ein computerlesbares Speichermedium gehören: eine elektrische Verbindung mit einem oder mehreren Drähten, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein lösch- und programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact-Disc-Festwertspeicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder eine beliebige geeignete Kombination der Vorgenannten. Im vorliegenden Zusammenhang kann es sich bei einem computerlesbaren Speichermedium um ein beliebiges materielles Medium handeln, das ein Programm enthalten oder speichern kann.
Die vorstehenden Ausführungen lassen sich unter Bezugnahme auf die folgenden Klauseln besser verstehen:

1. Ein computerlesbares Speichermedium, das Anweisungen speichert, die bei Ausführung auf einem Prozessor eine Operation zum Bereitstellen einer Deployment-Pipeline ausführen, die Operation umfassend:
- Empfangen einer Definition einer Instanz einer Live-Pipeline-Vorlage (LPT), wobei die Instanz der LPT unter Verwendung von wenigstens einer ersten Pipeline-Basisvorlage und einer zweiten Pipeline-Vorlage vorgegeben ist, wobei die erste Pipeline-Basisvorlage einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt, und wobei die zweite Pipeline-Vorlage die erste Pipeline-Basisvorlage um einen oder mehrere instanzspezifische Parameter für die Deployment-Pipeline erweitert;
- Erstellen, auf der Grundlage der Instanz der LPT, einer Anwendungsdefinition, die eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten sind; und
- Einführen einer ersten Instanz der Deployment-Pipeline in wenigstens einer ersten Cloud-Computing-Region durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste in der ersten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
2. Das computerlesbare Speichermedium nach Klausel 1, wobei der eine oder die mehreren instanzspezifischen Parameter der zweiten Pipeline-Vorlage wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
3. Das computerlesbare Speichermedium nach Klausel 1, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
4. Das computerlesbare Speichermedium nach Klausel 1, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.
5. Das computerlesbare Speichermedium nach Klausel 1, das mindestens eine zweite Instanz der Deployment-Pipeline in wenigstens einer zweiten Cloud-Computing-Region durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, des entsprechenden Pipeline-Synthesetreibers einführt, um einen der Rechendienste in der zweiten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
6. Das computerlesbare Speichermedium nach Klausel 1, wobei die erste Pipeline-Basisvorlage wenigstens eine dritte Pipeline-Vorlage erweitert.
7. Ein System, umfassend:
- einen Prozessor; und
- einen Speicher, der eine oder mehrere Anwendungen speichert, die bei Ausführung auf dem Prozessor eine Operation zum Erstellen einer Anwendungsdefinition durchführen, die eine Deployment-Pipeline modelliert, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen, die Operation umfassend:
  - Erkennen einer Instanz einer Live-Pipeline-Vorlage (LPT), wobei die Instanz der LPT eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert,
  - Erstellen eines Anwendungsziels auf der Grundlage der Instanz der LPT, und Aufrufen des Anwendungsziels, um die Anwendungsdefinition zu erstellen, wobei die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für jeden der Vielzahl von Rechendiensten vorgibt, die in der Deployment-Pipeline enthalten sind.
8. Das System nach Klausel 7, wobei die Operation ferner folgendes umfasst:
- Einführen einer Instanz der Deployment-Pipeline in wenigstens einer ersten Cloud-Computing-Region durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste in der ersten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
9. Das System nach Klausel 8, wobei die Pipeline-Synthesetreiber in einer Reihenfolge aufgerufen werden, die ermittelt wird, um eine oder mehrere Dienstabhängigkeiten unter den Pipeline-Synthesetreibern zu befriedigen.
10. Das System nach Klausel 8, wobei die erste Cloud-Computing-Region wenigstens teilweise auf der Grundlage von den instanzspezifischen Parametern ausgewählt ist, die verwendet werden, um die eine oder mehreren Pipeline-Basisvorlagen zu konkretisieren.
11. Das System nach Klausel 7, wobei wenigstens eine erste der Pipeline-Basisvorlagen Konfigurationsparameter für jede der einen oder mehreren Bereitstellungsstufen der Deployment-Pipeline vorgibt.
12. Das System nach Klausel 7, wobei eine zweite der Pipeline-Basisvorlagen wenigstens eine erste der Pipeline-Basisvorlagen erweitert und wobei die zweite Pipeline-Basisvorlage Anforderungen für die Deployment-Pipeline vorgibt, die mit einem Produktionsdiensttyp assoziiert sind.
13. Das System nach Klausel 7, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
14. Das System nach Klausel 7, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
15. Das System nach Klausel 7, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.
16. Ein computerimplementiertes Verfahren zum Bereitstellen einer Deployment-Pipeline, das Verfahren umfassend:
- Ermitteln, dass eine Vielzahl von Rechendiensten, auf die durch eine Anwendungsdefinition verwiesen wird, die die Deployment-Pipeline modelliert, verfügbar ist, um eine Instanz der Deployment-Pipeline zu hosten, wobei die Anwendungsdefinition auf der Grundlage einer Instanz einer Live-Pipeline-Vorlage (LPT) erstellt wird, die eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert, und wobei die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für jeden der Vielzahl von Rechendiensten bereitstellt, auf die in der Anwendungsdefinition verwiesen wird; und
- Einführen der Instanz der Deployment-Pipeline durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
17. Das Verfahren nach Klausel 16, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
18. Das Verfahren nach Klausel 16, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
19. Das Verfahren nach Klausel 16, wobei die Instanz der Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen.
20. Das Verfahren nach Klausel 16, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.

Sowie die folgenden Klauseln:

1. Ein computerlesbares Speichermedium, das Anweisungen speichert, die bei Ausführung auf einem Prozessor eine Operation zum Warten einer Deployment-Pipeline ausführen, die Operation umfassend:
- Erkennen einer Änderung an einer von einer Vielzahl von Pipeline-Vorlagen, die im Quellcode einer Instanz einer Live-Pipeline-Vorlage (LPT) enthalten sind, wobei wenigstens eine erste der Pipeline-Vorlagen wenigstens eine zweite der Pipeline-Vorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert und wobei die zweite Pipeline-Vorlage Konfigurationsparameter für jede der einen oder mehreren Bereitstellungsstufen der Deployment-Pipeline vorgibt;
- Erstellen, auf der Grundlage der geänderten Instanz der LPT, einer Anwendungsdefinition, die eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten ist; und
- Aufrufen, für einen oder mehrere der in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen entsprechenden der Rechendienste in einer ersten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu modifizieren, die in der Anwendungsdefinition bereitgestellt wird.
2. Das computerlesbare Speichermedium nach Klausel 1, wobei die Operation zudem folgendes umfasst:
- Erkennen einer aktuellen Konfiguration für jeden der Vielzahl von Rechendiensten, die in der Deployment-Pipeline enthalten sind;
- Ermitteln, welcher der einen oder mehreren Rechendienste, die in der Deployment-Pipeline enthalten sind, eine aktuelle Konfiguration aufweist/aufweisen, die sich von der vollständig vorgegebenen Konfiguration unterscheidet, die in der Anwendungsdefinition bereitgestellt wird; und
- wobei zum Aufrufen des jeweiligen Pipeline-Synthesetreibers zum Konfigurieren eines der Rechendienste in der ersten Cloud-Computing-Region das Aufrufen der jeweiligen Pipeline-Synthesetreiber gehört, die dem ermittelten einen oder den ermittelten mehreren Rechendiensten entsprechen.
3. Das computerlesbare Speichermedium nach Klausel 1, wobei die Operation zudem folgendes umfasst:
- Aufrufen, für einen oder mehrere der in der Anwendungsdefinition aufgeführten Rechendienste, des entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste in einer zweiten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
4. Das computerlesbare Speichermedium nach Klausel 1, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
5. Das computerlesbare Speichermedium nach Klausel 1, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
6. Das computerlesbare Speichermedium nach Klausel 1, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einer oder mehreren Anwendungen in einem Produktionsrechendienst bereitzustellen.
7. Ein System, umfassend:
- einen Prozessor; und
- einen Speicher, der eine oder mehrere Anwendungen speichert, die bei Ausführung auf dem Prozessor eine Operation zum Verwalten einer Deployment-Pipeline ausführen, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen, die Operation umfassend:
  - Konfigurieren einer Deployment-Pipeline durch Aufrufen, für jeden in einer Anwendungsdefinition, die die Deployment-Pipeline modelliert, aufgeführten Rechendienst, eines entsprechenden Pipeline-Synthesetreibers, um einen entsprechenden der Rechendienste entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird, und
  - Einführen einer Meta-Pipeline, die verwendet wird, um Aktualisierungen für die Deployment-Pipeline auf der Grundlage von wenigstens einer erkannten Änderung an einer Instanz einer Live-Pipeline-Vorlage (LPT) zu verbreiten, wobei die Instanz der LPT eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert und wobei die Anwendungsdefinition auf der Grundlage der LPT-Instanz erstellt wird.
8. Das System nach Klausel 7, wobei eine erste der Pipeline-Basisvorlagen einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt.
9. Das System nach Klausel 8, wobei eine zweite Pipeline-Basisvorlage wenigstens die erste Pipeline-Basisvorlage erweitert und wobei die zweite Pipeline-Basisvorlage Anforderungen für die Deployment-Pipeline vorgibt, die mit einem Produktionsdiensttyp assoziiert sind, der durch die zweite Pipeline-Basisvorlage vorgegeben ist.
10. Das System nach Klausel 7, wobei die Meta-Pipeline die Deployment-Pipeline wie folgt aktualisiert:
- Erkennen der Änderung der Instanz der LPT;
- Erstellen, auf der Grundlage der geänderten Instanz der LPT, einer aktualisierten Anwendungsdefinition; und
- Aktualisieren der Deployment-Pipeline durch Aufrufen, für einen oder mehrere der in der aktualisierten Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden der Pipeline-Synthesetreiber, um einen entsprechenden der Rechendienste in der ersten Cloud-Computing-Region entsprechend der aktualisierten Anwendungsdefinition zu konfigurieren.
11. Das System nach Klausel 10, wobei die Pipeline-Synthesetreiber in einer Reihenfolge aufgerufen werden, die ermittelt wird, um eine oder mehrere Dienstabhängigkeiten unter den Pipeline-Synthesetreibern zu befriedigen.
12. Das System nach Klausel 10, wobei zum Erkennen der Änderung der Instanz der LPT das Überwachen eines Versionierungssystems auf eine aktualisierte Version der Instanz der LPT gehört, die in das Versionierungssystem übertragen wurde.
13. Das System nach Klausel 7, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
14. Das System nach Klausel 7, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
15. Das System nach Klausel 7, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.
16. Ein computerimplementiertes Verfahren zum Aktualisieren einer Deployment-Pipeline, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen, das Verfahren umfassend:
- Erkennen einer Änderung am Quellcode einer Instanz einer Live-Pipeline-Vorlage (LPT), die in ein Versionierungssystem übertragen wurde;
- Erstellen, auf der Grundlage des geänderten Quellcodes der Instanz der LPT, einer Anwendungsdefinition, die eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten sind; und
- Aufrufen, für einen oder mehrere der in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen entsprechenden der Rechendienste so neu zu konfigurieren, dass er der vollständig vorgegebenen Konfiguration entspricht, die in der Anwendungsdefinition bereitgestellt wird.
17. Das Verfahren nach Klausel 16, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
18. Das Verfahren nach Klausel 16, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen auf den Produktionsrechendienst zu verbreiten.
19. Das Verfahren nach Klausel 16, wobei der Quellcode der Instanz der LPT wenigstens eine erste Pipeline-Vorlage enthält, wobei die erste Pipeline-Vorlage einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt.
20. Das Verfahren nach Klausel 19, wobei der Quellcode der Instanz der LPT zudem wenigstens eine zweite Pipeline-Vorlage umfasst und wobei die zweite Pipeline-Vorlage den Quellcode der ersten Pipeline-Vorlage um eine Vielzahl von instanzspezifischen Parametern für die Deployment-Pipeline erweitert.

Sowie die folgenden Klauseln:

1. Ein computerlesbares Speichermedium, das Anweisungen speichert, die bei Ausführung auf einem Prozessor eine Operation zum Bewerten einer Deployment-Pipeline ausführen, die Operation umfassend:
- Erzeugen einer Anwendungsdefinition, um einen aktuellen Betriebszustand einer Deployment-Pipeline widerzuspiegeln, wobei die Anwendungsdefinition durch Aufrufen einer Vielzahl von Analysetreibern erstellt wird und wobei jeder Analysetreiber eine Konfiguration eines entsprechenden Rechendienstes, der in der Deployment-Pipeline enthalten ist, dahingehend überprüft, dass diese wenigstens in einer ersten Cloud-Computing-Region bereitgestellt ist;
- Bewerten der Anwendungsdefinition unter Verwendung eines Satzes von einer oder mehreren Regeln, wobei jede Regel eine oder mehrere Bedingungen für die Konfiguration von einem oder mehreren der Rechendienste vorgibt, die in der Deployment-Pipeline enthalten sind; und
- Erstellen eines Berichts, aus dem hervorgeht, welche der einen oder mehreren Regeln durch den aktuellen Betriebszustand der Deployment-Pipeline erfüllt sind und welche der einen oder mehreren Regeln durch den aktuellen Betriebszustand der Deployment-Pipeline nicht erfüllt sind.
2. Das computerlesbare Speichermedium nach Klausel 1, wobei die Operation zudem folgendes umfasst:
- für wenigstens eine erste der Regeln, die nicht durch den aktuellen Betriebszustand der Deployment-Pipeline erfüllt wird, Erstellen einer vorgeschlagenen Modifikation eines oder mehrerer der Rechendienste, die in der Deployment-Pipeline enthalten sind, die erforderlich ist, um die erste Regel zu erfüllen.
3. Das computerlesbare Speichermedium nach Klausel 2, wobei die Operation zudem folgendes umfasst:
- Verbreiten der vorgeschlagenen Modifikation auf einen oder mehrere der Rechendienste.
4. Das computerlesbare Speichermedium nach Klausel 1, wobei die Analysetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
5. Das computerlesbare Speichermedium nach Klausel 1, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.
6. Das computerlesbare Speichermedium nach Klausel 1, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einer oder mehreren Anwendungen in einem Produktionsrechendienst bereitzustellen, der in der ersten Cloud-Computing-Region gehostet wird.
7. Ein System, umfassend:
- einen Prozessor; und
- einen Speicher, der eine oder mehrere Anwendungen speichert, die bei Ausführung auf dem Prozessor eine Operation zum Ermitteln eines aktuellen Konfigurationszustandes einer Deployment-Pipeline ausführen, die verwendet wird, um Aktualisierungen auf einen Produktionsrechendienst zu verbreiten, die Operation umfassend:
  - Erkennen einer Vielzahl von Rechendiensten, die in der Deployment-Pipeline enthalten ist,
  - für jeden erkannten Rechendienst:
    - Ermitteln eines aktuellen Konfigurationszustandes für einen bestimmten der Rechendienste, die in der Deployment-Pipeline enthalten sind; und
    - Erstellen einer Beschreibung des aktuellen Konfigurationszustandes des Rechendienstes, und
    - Erstellen, auf der Grundlage der erstellten Beschreibungen, einer ersten Anwendungsdefinition, wobei die erste Anwendungsdefinition eine vollständig vorgegebene Konfiguration des aktuellen Betriebszustandes der Deployment-Pipeline bereitstellt.
8. Das System nach Klausel 7, wobei zum Ermitteln eines aktuellen Konfigurationszustandes des jeweiligen Rechendienstes, der in der Deployment-Pipeline enthalten ist, das Aufrufen eines Pipeline-Analysetreibers gehört, der dem jeweiligen Rechendienst entspricht, und wobei der Pipeline-Analysetreiber den jeweiligen Rechendienst durch einen oder mehrere API-Aufrufe überprüft, um den aktuellen Konfigurationszustand des jeweiligen Rechendienstes zu ermitteln.
9. Das System nach Klausel 8, wobei die Pipeline-Analysetreiber einen oder mehrere der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
10. Das System nach Klausel 7, wobei die Operation ferner folgendes umfasst:
- Ermitteln, dass die erste Anwendungsdefinition wenigstens eine erste Regel nicht erfüllt, die eine Anforderung an den aktuellen Konfigurationszustand der Deployment-Pipeline vorgibt.
11. Das System nach Klausel 10, wobei die Operation ferner folgendes umfasst:
- Ermitteln einer Modifikation, die auf wenigstens einen ersten der Rechendienste angewendet werden soll, die in der Deployment-Pipeline enthalten sind, und die erforderlich ist, um die erste Regel zu erfüllen.
12. Das System nach Klausel 11, wobei die Operation ferner folgendes umfasst:
- Aufrufen von wenigstens einem ersten Synthesetreiber zum erneuten Konfigurieren des ersten Rechendienstes, damit dieser mit der vollständig vorgegebenen Konfiguration der Deployment-Pipeline übereinstimmt, die in der Anwendungsdefinition bereitgestellt wird.
13. Das System nach Klausel 7, wobei die Operation ferner folgendes umfasst:
- Ermitteln, auf der Grundlage der erste Anwendungsdefinition, eines Diensttyps, der mit dem Produktionsrechendienst assoziiert ist, der unter Verwendung der Deployment-Pipeline bereitgestellt wird; und
- Ermitteln, auf der Grundlage von wenigstens dem ermittelten Diensttyp, einer Live-Pipeline-Vorlage für eine Assoziierung mit der Deployment-Pipeline, wobei die Live-Pipeline-Vorlage Quellcode für eine oder mehrere Pipeline-Basisvorlagen enthält.
14. Das System nach Klausel 13, wobei die eine oder mehreren Pipeline-Basisvorlagen Quellcode einer ersten Pipeline-Basisvorlage enthalten, der einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt.
15. Das System nach Klausel 14, wobei die eine oder mehreren Pipeline-Basisvorlagen Quellcode einer zweiten Pipeline-Basisvorlage enthalten, der die erste Pipeline-Basisvorlage erweitert, und wobei die zweite Pipeline-Basisvorlage eine Vielzahl von Diensttypparametern für die Deployment-Pipeline vorgibt.
16. Das System nach Klausel 14, wobei die Operation ferner folgendes umfasst:
- Empfangen von Quellcode, der instanzspezifische Parameter vorgibt, die verwendet werden, um die Live-Pipeline-Vorlage als eine Live-Pipeline-Vorlageinstanz (LPT) zu konkretisieren.
17. Das System nach Klausel 16, wobei Änderungen an der Deployment-Pipeline dadurch vorgenommen werden, dass Änderungen am Quellcode der ersten Pipeline-Basisvorlage, der zweiten Pipeline-Basisvorlage oder an instanzspezifischen Parametern der LPT-Instanz in ein Versionierungssystem übertragen werden.
18. Ein computerimplementiertes Verfahren zum Bewerten einer Deployment-Pipeline, das Verfahren umfassend:
- Erstellen einer ersten Anwendungsdefinition durch Aufrufen einer Vielzahl von Analysetreibern, wobei jeder der Vielzahl von Analysetreibern eine Konfiguration eines jeweiligen Rechendienstes prüft, der in einer Deployment-Pipeline enthalten ist, wobei die erste Anwendungsdefinition einen aktuellen Konfigurationszustand der Deployment-Pipeline widerspiegelt;
- Empfangen von Quellcode, der einer Live-Pipeline-Vorlage entspricht;
- Erstellen, auf der Grundlage der Live-Pipeline-Vorlage, einer zweiten Anwendungsdefinition, wobei die zweite Anwendungsdefinition eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten beschreibt, die verwendet wird, um eine zweite Deployment-Pipeline bereitzustellen; und
- Ermitteln einer Reihe von Unterschieden zwischen der ersten Anwendungsdefinition und der zweiten Anwendungsdefinition; und
- Erstellen eines Berichts, der die ermittelten Unterschiede beschreibt.
19. Das Verfahren nach Klausel 18, wobei der der Live-Pipeline-Vorlage entsprechende Quellcode eine oder mehrere Pipeline-Basisvorlagen umfasst.
20. Das Verfahren nach Klausel 18, wobei die eine oder mehreren Pipeline-Basisvorlagen eine erste Pipeline-Basisvorlage umfassen, die einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt, und eine zweite Pipeline-Vorlage, die die erste Pipeline-Basisvorlage um eine Vielzahl von instanzspezifischen Parametern erweitert, die mit dem ermitteln Diensttyp assoziiert ist.

Und die folgenden Klauseln:

1. Ein computerlesbares Speichermedium, das Anweisungen speichert, die bei Ausführung auf einem Prozessor eine Operation ausführen, durch die ein Konfigurationszustand einer Deployment-Pipeline unter die Kontrolle einer Live-Pipeline-Vorlage gestellt werden soll, die Operation umfassend:
- Erstellen einer ersten Anwendungsdefinition durch Aufrufen einer Vielzahl von Analysetreibern, wobei jeder der Vielzahl von Analysetreibern eine Konfiguration eines jeweiligen Rechendienstes prüft, der in einer ersten Deployment-Pipeline enthalten ist, die in wenigstens einer ersten Cloud-Computing-Region bereitgestellt wird, wobei die erste Anwendungsdefinition einen aktuellen Konfigurationszustand der ersten Deployment-Pipeline widerspiegelt;
- Erstellen einer oder mehrerer zweiter Anwendungsdefinitionen, wobei jede zweite Anwendungsdefinition auf der Grundlage von Quellcode erstellt wird, der eine Live-Pipeline-Vorlage definiert, und wobei jede zweite Anwendungsdefinition einen potentiellen Konfigurationszustand für eine Deployment-Pipeline widerspiegelt;
- Vergleichen des aktuellen Konfigurationszustandes, der in der ersten Anwendungsdefinition widergespiegelt ist, mit der potentiellen Konfiguration, die in einer oder mehreren zweiten Anwendungsdefinitionen widergespiegelt ist;
- Ermitteln, auf der Grundlage von wenigstens dem Vergleich, dass eine der zweiten Anwendungsdefinitionen eine potentielle Bereitstellungskonfiguration für eine Deployment-Pipeline widerspiegelt, die mit der ersten Deployment-Pipeline kompatibel ist; und
- erneutes Konfigurieren der ersten Deployment-Pipeline, damit diese der potentiellen Bereitstellungskonfiguration entspricht, wie diese durch die ermittelte zweite Anwendungsdefinition vorgegeben ist.
2. Das computerlesbare Speichermedium nach Klausel 1, wobei der Quellcode, der wenigstens eine erste der Live-Pipeline-Vorlagen definiert, eine oder mehrere Pipeline-Basisvorlagen umfasst.
3. Das computerlesbare Speichermedium 1, wobei die eine oder mehreren Pipeline-Basisvorlagen eine erste Pipeline-Basisvorlage enthalten, die einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt.
4. Das computerlesbare Speichermedium nach Klausel 1, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einer oder mehreren Anwendungen in einem Produktionsrechendienst bereitzustellen, der in der ersten Cloud-Computing-Region gehostet wird.
5. Das computerlesbare Speichermedium nach Klausel 1, wobei die Operation zudem folgendes umfasst:
- Empfangen von Quellcode, der einen Satz instanzspezifischer Parameter vorgibt, die verwendet werden, um die Live-Pipeline-Vorlage zu konkretisieren, die der ermittelten Anwendungsdefinition entspricht.
6. Das computerlesbare Speichermedium nach Klausel 5, wobei die Operation zudem folgendes umfasst:
- Einführen einer Instanz der Deployment-Pipeline in wenigstens einer zweiten Cloud-Computing-Region durch Aufrufen, für jeden einer Vielzahl von Rechendiensten, auf die in der ermittelten zweiten Anwendungsdefinition verwiesen wird, eines jeweiligen Pipeline-Synthesetreibers, um einen entsprechenden der Rechendienste in der zweiten Cloud-Computing-Region zu konfigurieren.
7. Das computerlesbare Speichermedium nach Klausel 1, wobei die erste Anwendungsdefinition und die zweiten Anwendungsdefinitionen jeweils entsprechend einem gemeinsamen Austauschformat formatiert sind.
8. Ein System, umfassend:
- einen Prozessor; und
- einen Speicher, der eine oder mehrere Anwendungen speichert, die bei Ausführung auf dem Prozessor eine Operation zum Überwachen eines Konfigurationszustandes einer Deployment-Pipeline ausführen, die Operation umfassend:
  - Erkennen einer Änderung, die an der Konfiguration von wenigstens einem Rechendienst vorgenommen wurde, der wenigstens teilweise zum Bereitstellen der Deployment-Pipeline verwendet wird,
  - Erstellen einer Anwendungsdefinition auf der Grundlage einer Instanz einer Live-Pipeline-Vorlage (LPT), die mit der Deployment-Pipeline assoziiert ist, wobei die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten sind, einschließlich dem ersten Rechendienst,
  - Vergleichen der erkannten Änderung an der Konfiguration des ersten Rechendienstes mit einer Konfiguration, die für den ersten Rechendienst in der Anwendungsdefinition vorgegeben ist, und
  - Erstellen eines Berichts, der Unterschiede zwischen der geänderten Konfiguration des ersten Rechendienstes und dem Konfigurationszustand für den ersten Rechendienst beschreibt, der in der Anwendungsdefinition vorgegeben ist.
9. Das System nach Klausel 8, wobei der Bericht auf ein Maß für das Risiko für entweder die Deployment-Pipeline oder den Produktionsrechendienst hindeutet, die unter Verwendung der Deployment-Pipeline aktualisiert wurden, die sich aus der erkannten Änderung ergab.
10. Das System nach Klausel 9, wobei der Bericht auf eine Modifikation an der geänderten Konfiguration der Deployment-Pipeline hindeutet, um das Maß des Risikos zu verringern.
11. Das System nach Klausel 8, wobei die Instanz der LPT eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert und wobei die Anwendungsdefinition auf der Grundlage der LPT-Instanz erstellt wird.
12. Das System nach Klausel 8, wobei eine zweite der Pipeline-Basisvorlagen wenigstens eine erste der Pipeline-Basisvorlagen erweitert.
13. Das System nach Klausel 12, wobei die erste Pipeline-Basisvorlage einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt und wobei die zweite Pipeline-Basisvorlage Anforderungen für die Deployment-Pipeline vorgibt, die mit einem Produktionsdiensttyp assoziiert sind.
14. Das System nach Klausel 8, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Aktualisierungen einer oder mehrerer Anwendungen in einem Produktionsrechendienst zu verbreiten, der in der ersten Cloud-Computing-Region gehostet wird.
15. Das System nach Klausel 8, wobei das Vergleichen der erkannten Änderung an der Konfiguration des ersten Rechendienstes mit einer Konfiguration, die für den ersten Rechendienst in der Anwendungsdefinition vorgegeben ist, folgendes umfasst Ermitteln eines aktuellen Konfigurationszustandes des ersten Rechendienstes; und Erstellen einer Beschreibung des aktuellen Konfigurationszustandes des ersten Rechendienstes, wobei die Anwendungsdefinition und die erstellte Beschreibung jeweils entsprechend einem gemeinsamen Austauschformat formatiert sind.
16. Ein computerimplementiertes Verfahren zum Warten einer Deployment-Pipeline, die unter Verwendung einer Instanz einer Live-Pipeline-Vorlage (LPT) bereitgestellt wird, das Verfahren umfassend:
- Erkennen einer Änderung, die an wenigstens einem Rechendienst vorgenommen wurde, der zum Bereitstellen der Deployment-Pipeline verwendet wird,
- Erstellen einer ersten Anwendungsdefinition auf der Grundlage der Instanz der LPT, die mit der Deployment-Pipeline assoziiert ist, wobei die erste Anwendungsdefinition eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten ist, einschließlich dem ersten Rechendienst; und
- Aufrufen, für wenigstens den ersten Rechendienst, eines entsprechenden Pipeline-Synthesetreibers, wobei der Pipeline-Synthesetreiber den ersten Rechendienst entsprechend der vollständig vorgegebenen Konfiguration erneut konfiguriert, die in der ersten Anwendungsdefinition bereitgestellt wird.
17. Das computerimplementierte Verfahren nach Klausel 16, wobei zum Erkennen der Änderung, die an wenigstens einem ersten Rechendienst vorgenommen wurde, der verwendet wird, um die Deployment-Pipeline bereitzustellen, folgendes gehört:
- Erstellen einer zweiten Anwendungsdefinition durch Aufrufen einer Vielzahl von Analysetreibern, wobei jeder der Vielzahl von Analysetreibern eine Konfiguration eines jeweiligen Rechendienstes prüft, der in der Deployment-Pipeline enthalten ist; und
- Vergleichen der ersten Anwendungsdefinition mit der zweiten Anwendungsdefinition, um die Änderung zu erkennen, die am ersten Rechendienst vorgenommen wurde.
18. Das computerimplementierte Verfahren nach Klausel 16, wobei die Instanz der LPT Quellcode für wenigstens eine erste Pipeline-Basisvorlage enthält, die einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt, und der Quellcode einen Satz instanzspezifischer Parameter für die Deployment-Pipeline vorgibt.
19. Das computerimplementierte Verfahren nach Klausel 16, wobei die Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einer oder mehreren Anwendungen in einem Produktionsrechendienst bereitzustellen, der unter Verwendung der Deployment-Pipeline bereitgestellt wird.
20. Das computerimplementierte Verfahren nach Klausel 16, ferner umfassend, vor dem Aufrufen der entsprechenden Pipeline-Synthesetreiber, die verwendet werden, um den ersten Rechendienst erneut zu konfigurieren, das Empfangen einer Bestätigung zum Durchsetzen der Konfiguration der Deployment-Pipeline, die in der Instanz der Live-Pipeline-Vorlage vorgegeben ist.

Auch wenn sich Vorstehendes auf Ausführungsformen der vorliegenden Erfindung bezieht, können andere und weitere Ausführungsformen der Erfindung entwickelt werden, ohne von deren grundlegendem Umfang abzuweichen, und deren Umfang wird durch die nachfolgenden Ansprüche festgelegt.

Claims

System, umfassend: einen oder mehrere Prozessoren; und ein oder mehrere computerlesbare Speichermedien, die Anweisungen speichern, die bei Ausführung auf dem einen oder den mehreren Prozessoren eine Operation zum Bereitstellen einer Deployment-Pipeline ausführen, die Operation umfassend: Empfangen einer Definition einer Instanz einer Live-Pipeline-Vorlage (LPT), wobei die Instanz der LPT unter Verwendung von wenigstens einer ersten Pipeline-Basisvorlage und einer zweiten Pipeline-Vorlage vorgegeben ist, wobei die erste Pipeline-Basisvorlage einen Satz Konfigurationsparameter für eine oder mehrere Bereitstellungsstufen der Deployment-Pipeline vorgibt, und wobei die zweite Pipeline-Vorlage die erste Pipeline-Basisvorlage um einen oder mehrere instanzspezifische Parameter für die Deployment-Pipeline erweitert; Erstellen, auf der Grundlage der Instanz der LPT, einer Anwendungsdefinition, die eine vollständig vorgegebene Konfiguration für eine Vielzahl von Rechendiensten bereitstellt, die in der Deployment-Pipeline enthalten sind; und Einführen einer ersten Instanz der Deployment-Pipeline in wenigstens einer ersten Cloud-Computing-Region durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste in der ersten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
System, umfassend: einen Prozessor; und einen Speicher, der eine oder mehrere Anwendungen speichert, die bei Ausführung auf dem Prozessor eine Operation zum Erstellen einer Anwendungsdefinition ausführen, die eine Deployment-Pipeline modelliert, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen, die Operation umfassend: Erkennen einer Instanz einer Live-Pipeline-Vorlage (LPT), wobei die Instanz der LPT eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert, Erstellen eines Anwendungsziels auf der Grundlage der Instanz der LPT, und Aufrufen des Anwendungsziels, um die Anwendungsdefinition zu erstellen, wobei die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für jeden der Vielzahl von Rechendiensten vorgibt, die in der Deployment-Pipeline enthalten sind.
System nach Anspruch 2, wobei die Operation ferner folgendes umfasst: Einführen einer Instanz der Deployment-Pipeline in wenigstens einer ersten Cloud-Computing-Region durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste in der ersten Cloud-Computing-Region entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
System nach Anspruch 3, wobei die Pipeline-Synthesetreiber in einer Reihenfolge aufgerufen werden, die ermittelt wird, um eine oder mehrere Dienstabhängigkeiten unter den Pipeline-Synthesetreibern zu befriedigen.
System nach Anspruch 3, wobei die erste Cloud-Computing-Region wenigstens teilweise auf der Grundlage von den instanzspezifischen Parametern ausgewählt ist, die verwendet werden, um die eine oder mehreren Pipeline-Basisvorlagen zu konkretisieren.
System nach Anspruch 2, wobei wenigstens eine erste der Pipeline-Basisvorlagen Konfigurationsparameter für jede der einen oder mehreren Bereitstellungsstufen der Deployment-Pipeline vorgibt.
System nach Anspruch 2, wobei eine zweite der Pipeline-Basisvorlagen wenigstens eine erste der Pipeline-Basisvorlagen erweitert und wobei die zweite Pipeline-Basisvorlage Anforderungen für die Deployment-Pipeline vorgibt, die mit einem Produktionsdiensttyp assoziiert sind.
System nach Anspruch 2, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
System nach Anspruch 2, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
System nach Anspruch 2, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.
Computerimplementiertes Verfahren zum Bereitstellen einer Deployment-Pipeline, das Verfahren umfassend: Ermitteln, dass eine Vielzahl von Rechendiensten, auf die durch eine Anwendungsdefinition verwiesen wird, die die Deployment-Pipeline modelliert, verfügbar ist, um eine Instanz der Deployment-Pipeline zu hosten, wobei die Anwendungsdefinition auf der Grundlage einer Instanz einer Live-Pipeline-Vorlage (LPT) erstellt wird, die eine oder mehrere Pipeline-Basisvorlagen mit instanzspezifischen Parametern für die Deployment-Pipeline konkretisiert, und wobei die Anwendungsdefinition eine vollständig vorgegebene Konfiguration für jeden der Vielzahl von Rechendiensten bereitstellt, auf die in der Anwendungsdefinition verwiesen wird; und Einführen der Instanz der Deployment-Pipeline durch Aufrufen, für jeden in der Anwendungsdefinition aufgeführten Rechendienste, eines entsprechenden Pipeline-Synthesetreibers, um einen der Rechendienste entsprechend der vollständig vorgegebenen Konfiguration zu konfigurieren, die in der Anwendungsdefinition bereitgestellt wird.
Verfahren nach Anspruch 11, wobei die instanzspezifischen Parameter wenigstens eines der folgenden enthalten: ein Dienstname, ein administrativer Kontakt, ein Ausführungsbenutzername für einen der Rechendienste, die in der Deployment-Pipeline enthalten sind.
Verfahren nach Anspruch 11, wobei die Pipeline-Synthesetreiber wenigstens einen der folgenden umfassen: ein Pipeline-Treiber, ein Bereitstellungstreiber, ein Host-Treiber, ein Netzwerktreiber, ein Sicherheitstreiber, ein Identitäts- und Zugriffsverwaltungstreiber (IAM), ein Leistungsüberwachungseinheittreiber und ein Alarmtreiber.
Verfahren nach Anspruch 11, wobei die Instanz der Deployment-Pipeline eine kontinuierliche Deployment-Pipeline ist, die verwendet wird, um Änderungen an einem Produktionsrechendienst bereitzustellen.
Verfahren nach Anspruch 11, wobei die Anwendungsdefinition entsprechend einem strukturierten Austauschformat formatiert ist.