Bereitstellungsumgebung - Wikipedia

In der Software-Implementierung einer -Umgebung oder -Stufe ist ein Computersystem, in dem ein Computerprogramm oder eine Softwarekomponente bereitgestellt und ausgeführt wird. In einfachen Fällen, z. B. beim Entwickeln und sofortigen Ausführen eines Programms auf derselben Maschine, kann es eine einzige Umgebung geben, im industriellen Einsatz jedoch die Entwicklungsumgebung (wo ursprünglich Änderungen vorgenommen wurden) und Produktion Umgebung (was Endbenutzer verwenden) ist getrennt; oft mit mehreren Stufen dazwischen. Dieser strukturierte Versionsverwaltungsprozess ermöglicht die schrittweise Bereitstellung (Rollout), das Testen und das Rollback bei Problemen.

Umgebungen können sich in ihrer Größe erheblich unterscheiden: Die Entwicklungsumgebung ist normalerweise eine Workstation eines einzelnen Entwicklers, während die Produktionsumgebung ein Netzwerk vieler geographisch verteilter Maschinen in Rechenzentren oder virtueller Maschinen im Cloud-Computing sein kann. Code, Daten und Konfiguration können parallel bereitgestellt werden und müssen nicht mit der entsprechenden Schicht verbunden sein. Beispielsweise kann Vorproduktionscode eine Verbindung zu einer Produktionsdatenbank herstellen.

Architekturen [ edit ]

Die Bereitstellungsarchitekturen variieren erheblich, aber im Großen und Ganzen sind die Ebenen buchstabiert, beginnend bei Entwicklung (DEV) und endend bei ] Produktion (PROD). Eine übliche 4-Tier-Architektur ist Entwicklung, Test, Modell, Produktion (DEV, TEST, MODL, PROD), wobei jeweils Software in der jeweiligen Reihenfolge bereitgestellt wird. Andere übliche Umgebungen umfassen die Qualitätskontrolle (Quality Control, QC) für die Abnahmeprüfung. Sandbox oder Experiment (EXP) für Experimente, die nicht in die Produktion gehen sollen; und Disaster Recovery, um bei Problemen mit der Produktion einen sofortigen Rückschlag zu ermöglichen. Eine andere gebräuchliche Architektur ist Entwicklung, Testen, Akzeptieren und Produzieren (DTAP), bestehend aus dev / test / sandbox / prod.

Diese Sprache ist besonders für Serverprogramme geeignet, bei denen Server in einem Remote-Rechenzentrum ausgeführt werden. Für Code, der auf einem Endbenutzergerät ausgeführt wird, z. B. Anwendungen (Apps) oder Clients, kann stattdessen auf die Benutzerumgebung (USER) oder die lokale Umgebung (LOCAL) verwiesen werden.

Die genauen Definitionen und Grenzen zwischen den Umgebungen variieren - der Test kann als Teil von dev angesehen werden, die Akzeptanz kann als Teil des Tests, Teil der Stufe oder separat betrachtet werden usw. Die Hauptebenen werden der Reihe nach durchlaufen, wobei neue Releases vorgesehen sind eingesetzt ( ausgerollt oder gedrückt )) ^[1][2] Experimentelle und Erholungsebenen befinden sich, falls vorhanden, außerhalb dieses Flusses - experimentelle Releases sind in der Regel eine Terminologie alte oder doppelte Version der Produktion, bereitgestellt nach der Produktion. Bei Problemen kann man auf die alte Version zurückrollen, am einfachsten, indem die alte Version wie eine neue Version verschoben wird. Der letzte Schritt bei der Bereitstellung für die Produktion ("Push-to-Prod") ist der empfindlichste, da alle Probleme unmittelbare Auswirkungen auf den Benutzer haben. Aus diesem Grund wird dies oft anders gehandhabt, zumindest sorgfältiger überwacht und in einigen Fällen ein schrittweises Rollout oder nur ein Umlegen eines Switches erforderlich, was ein schnelles Rollback ermöglicht. Es ist am besten, einen Namen wie QA zu vermeiden. QA bedeutet nicht das Testen von Software. Testen ist wichtig, unterscheidet sich jedoch von der Qualitätssicherung.

Manchmal erfolgt die Bereitstellung außerhalb dieses regulären Prozesses, hauptsächlich um dringende oder relativ geringfügige Änderungen bereitzustellen, ohne dass eine vollständige Freigabe erforderlich ist. Dies kann aus einem einzelnen Patch, einem großen Service Pack oder einem kleinen Hotfix bestehen.

Tiers können sehr unterschiedlich groß sein: dev ist normalerweise die Workstation eines einzelnen Entwicklers (obwohl es Tausende von Entwicklern gibt), während prod viele geografisch verteilte Maschinen sein kann. Test und QC können je nach den dafür zur Verfügung stehenden Ressourcen klein oder groß sein, und die Bereitstellung kann von einer einzelnen Maschine (ähnlich wie bei Canary) bis hin zu einem exakten Duplikat der Produktion reichen.

Umgebungen [ edit ]

Die nachstehende Tabelle beschreibt eine fein unterteilte Liste von Ebenen ^{Zitat benötigt} .

Name der Umgebung / Tier	Beschreibung
Lokal	Desktop / Workstation des Entwicklers
Entwicklung / Stamm	Entwicklungsserver, der als Sandbox fungiert, in der Komponententests vom Entwickler durchgeführt werden können
Integration	CI-Build-Target oder für den Entwicklertest von Nebenwirkungen
Test / QC / Interne Abnahme	Die Umgebung, in der Schnittstellentest ausgeführt wird. Ein Qualitätskontrollteam stellt sicher, dass der neue Code keinen Einfluss auf die vorhandene Funktionalität hat, und testet die wichtigsten Funktionen des Systems, nachdem der neue Code in der Testumgebung bereitgestellt wurde.
Modell / Bühne / Vorproduktion / Akzeptanz externer Kunden / Demo	Spiegel der Produktionsumgebung
Produktion / Live	Bedient Endbenutzer / Clients

Entwicklung [ edit ]

Die Entwicklungsumgebung (dev) ist die Umgebung, in der Änderungen an Software entwickelt werden, am einfachsten als Workstation eines einzelnen Entwicklers. Dies unterscheidet sich in vielerlei Hinsicht von der endgültigen Zielumgebung - das Ziel ist möglicherweise kein Desktop-Computer (es kann sich um ein Smartphone, ein eingebettetes System, einen Computer ohne Kopf in einem Rechenzentrum usw. handeln), und selbst wenn es sich ansonsten um eine ähnliche Umgebung handelt, ist dies die Umgebung des Entwicklers Dazu gehören Entwicklungstools wie ein Compiler, eine integrierte Entwicklungsumgebung, andere oder zusätzliche Versionen von Bibliotheken und Support-Software usw., die in einer Benutzerumgebung nicht vorhanden sind.

Im Zusammenhang mit der Revisionskontrolle, insbesondere bei mehreren Entwicklern, werden feinere Unterscheidungen getroffen: Ein Entwickler hat eine Arbeitskopie des Quellcodes auf seinem Computer, und Änderungen werden an das Repository übermittelt, das entweder festgeschrieben wird je nach Entwicklungsmethodik an den Stamm oder eine Niederlassung. Die Umgebung auf einer einzelnen Workstation, an der Änderungen bearbeitet und ausprobiert werden, kann als lokale Umgebung oder als Sandkasten bezeichnet werden. Das Erstellen der Kopie des Quellcodes in einer sauberen Umgebung ist ein separater Schritt, Teil der Integration (Integration unterschiedlicher Änderungen). Diese Umgebung kann als -Integrationsumgebung oder Entwicklungsumgebung bezeichnet werden ]; Bei kontinuierlicher Integration wird dies häufig und für jede Revision wiederholt. Das Konzept auf Quellcodeebene, "eine Änderung des Repositorys zu begehen", gefolgt vom Erstellen des Stamms oder Zweigs, entspricht dem Push-Release von Local (Umgebung eines einzelnen Entwicklers) auf Integration (Clean Build). Ein fehlerhaftes Release in diesem Schritt bedeutet, dass eine Änderung den Build gebrochen hat, und das Zurücksetzen des Releases entspricht entweder dem Zurücksetzen aller Änderungen von diesem Punkt an oder dem Rückgängigmachen der Änderungen, sofern dies möglich ist.

Testing [ edit ]

Der Zweck der Testumgebung besteht darin, dass menschliche Tester neuen und geänderten Code entweder durch automatisierte Prüfungen oder nicht automatisierte Techniken ausführen können. Nachdem der Entwickler den neuen Code und die neuen Konfigurationen durch Komponententests in der Entwicklungsumgebung akzeptiert hat, werden die Elemente in eine oder mehrere Testumgebungen verschoben. ^[3] Bei einem Testfehler kann die Testumgebung den fehlerhaften Code von den Testplattformen entfernen verantwortlicher Entwickler und liefern detaillierte Test- und Ergebnisprotokolle. Wenn alle Tests erfolgreich sind, kann die Testumgebung oder ein kontinuierliches Integrationsframework, das die Tests steuert, den Code automatisch in die nächste Implementierungsumgebung hochstufen.

Verschiedene Testtypen schlagen verschiedene Typen von Testumgebungen vor, von denen einige oder alle virtualisiert sein können ^[4] um ein schnelles paralleles Testen zu ermöglichen. Beispielsweise können automatisierte Benutzerschnittstellentests ^[5] auf mehreren virtuellen Betriebssystemen und Anzeigen (real oder virtuell) auftreten. Leistungstests erfordern möglicherweise eine normalisierte physische Basiskonfiguration der Hardware, damit die Ergebnisse des Leistungstests im Zeitverlauf verglichen werden können. Verfügbarkeits- oder Haltbarkeitstests können von Fehlersimulatoren in virtueller Hardware und virtuellen Netzwerken abhängen.

Die Tests können seriell (hintereinander) oder parallel (einige oder alle gleichzeitig) durchgeführt werden, abhängig von der Komplexität der Testumgebung. Ein wichtiges Ziel für agile und andere hochproduktive Softwareentwicklungspraktiken besteht darin, die Zeit vom Softwaredesign oder der Spezifikation bis zur Auslieferung in der Produktion zu verkürzen. ^[6] Hoch automatisierte und parallelisierte Testumgebungen tragen wesentlich zur schnellen Softwareentwicklung bei.

Staging [ edit ]

Eine Bühnen- oder Staging-Umgebung ist eine Umgebung zum Testen, die einer Produktionsumgebung genau ähnelt. ^[7] Sie versucht, eine tatsächliche Produktionsumgebung so genau wie diese zu spiegeln möglich und kann eine Verbindung zu anderen Produktionsdiensten und -daten herstellen, z. B. Datenbanken. Server werden beispielsweise auf Remote-Computern ausgeführt und nicht lokal (wie auf einer Entwickler-Workstation während der Entwicklungsumgebung oder auf einer einzelnen Testmaschine während des Tests), um die Auswirkungen des Netzwerkbetriebs auf das System zu testen.

In einer Staging-Umgebung werden in erster Linie alle Installations-, Konfigurations- und Migrationsskripts und -verfahren getestet, bevor sie auf eine Produktionsumgebung angewendet werden. Dadurch wird sichergestellt, dass alle größeren und kleineren Upgrades einer Produktionsumgebung zuverlässig, fehlerfrei und in kürzester Zeit abgeschlossen werden.

Eine weitere wichtige Verwendung von Staging sind Leistungstests, insbesondere Lasttests, da diese häufig von der Umgebung abhängig sind.

Staging wird auch von einigen Organisationen verwendet, um eine Vorschau der neuen Funktionen zur Auswahl von Kunden anzuzeigen oder um Integrationen mit Live-Versionen externer Abhängigkeiten zu überprüfen.

Production [ edit ]

Die Produktionsumgebung ist auch als live bekannt, insbesondere für Server, da dies die Umgebung ist, mit der Benutzer direkt interagieren.

Die Bereitstellung in der Produktion ist der empfindlichste Schritt. Dies kann durch direktes Bereitstellen von neuem Code (Überschreiben von altem Code, sodass jeweils nur eine Kopie vorhanden ist) oder durch Bereitstellen einer Konfigurationsänderung ausgeführt werden. Dies kann verschiedene Formen annehmen: Bereitstellen einer parallelen Installation einer neuen Codeversion und Wechseln zwischen diesen mit einer Konfigurationsänderung; Bereitstellen einer neuen Code-Version mit dem alten Verhalten und einem Merkmalsflag und Umschalten auf das neue Verhalten mit einer Konfigurationsänderung, die ein Flag-Flip durchführt; oder indem Sie separate Server bereitstellen (einen, der den alten Code ausführt, einen den Neuen) und das Umleiten des Datenverkehrs von alten auf neue mit einer Konfigurationsänderung auf der Ebene des Datenverkehrsroutings. Diese können wiederum auf einmal oder schrittweise in Phasen erfolgen.

Die Bereitstellung einer neuen Version erfordert im Allgemeinen einen Neustart, es sei denn, Hot Swapping ist möglich und erfordert daher entweder eine Dienstunterbrechung (normalerweise für Benutzersoftware, bei der Anwendungen neu gestartet werden) oder Redundanz - entweder Neustarten von Instanzen hinter einem Lastverteiler. oder starten Sie neue Server im Voraus und leiten Sie einfach den Datenverkehr auf die neuen Server um.

Wenn Sie eine neue Version in der Produktion bereitstellen und nicht sofort für alle Instanzen oder Benutzer bereitstellen, wird sie möglicherweise zuerst für eine einzelne Instanz oder einen Bruchteil von Benutzern bereitgestellt und anschließend entweder für alle oder schrittweise in Phasen bereitgestellt fangen Sie alle Last-Minute-Probleme auf. Dies ist ähnlich der Inszenierung, außer dass sie tatsächlich in der Produktion durchgeführt wird, und wird als Kanarienfreisetzung bezeichnet, analog zum Kohlebergbau. Dies erhöht die Komplexität, da mehrere Releases gleichzeitig ausgeführt werden, und ist daher normalerweise schnell vorbei, um Kompatibilitätsprobleme zu vermeiden.

Siehe auch [ edit ]

Referenzen [ edit

1. ^ Traditionelle Entwicklung / Integration / Staging / Produktionspraxis für Softwareentwicklung
   


2. ^ Sandboxes für die Entwicklung: Eine agile "beste" Praxis
   


3. ^ Ellison, Richard (2016-06-20). "Best Practices für Softwaretestumgebungen". Software Testing Magazine . Martinig & Associates . Abgerufen 2016-12-02 . Sobald der Entwickler die Unit-Testfälle ausgeführt hat, wird der Code in die Qualitätssicherung verschoben, um mit dem Testen zu beginnen. Oft haben Sie einige Umgebungen zum Testen. Zum Beispiel haben Sie eine Einrichtung für Systemtests und eine andere für Leistungstests und eine weitere für Benutzerakzeptanztests (UAT). Dies wird durch die besonderen Bedürfnisse für jede Art von Prüfung verursacht.
   


4. Dubie, Denise (2008-01-17). "So halten Sie virtuelle Testumgebungen in Schach". Network World, Inc. . IDG . Abgerufen 2016-12-02 . Die virtuelle Servertechnologie macht es Unternehmen leicht, Testumgebungen einzurichten und abzubauen, in denen sie sicherstellen können, dass Anwendungen auf Produktionsservern und Client-Rechnern auf Augenhöhe ablaufen Automatisierung der Benutzeroberfläche zum Testen Ihres Codes ". Microsoft.com . Microsoft . Abgerufen 2016-12-02 . Automatisierte Tests, mit denen Ihre Anwendung über ihre Benutzeroberfläche (UI) gesteuert wird, werden als codierte UI-Tests (CUITs) bezeichnet. Diese Tests umfassen Funktionstests der UI-Steuerelemente. Damit können Sie überprüfen, ob die gesamte Anwendung einschließlich der Benutzeroberfläche ordnungsgemäß funktioniert. Tests mit codierten UI sind besonders nützlich, wenn Validierung oder andere Logik in der Benutzeroberfläche vorhanden ist, beispielsweise in einer Webseite. Msgstr "Testen Sie Ihre Software?" CIO.com . IDG . Abgerufen 2016-12-03 . Das Testen von Release-Kandidaten dauert zu lange. Für viele agile Teams ist dies die größte Herausforderung. Ältere Anwendungen beginnen mit einem Testfenster, das länger als der Sprint ist.
   


5. ^ Sharma, Anurag (2018). Testumgebungsverwaltung . ITSM Press. p. 11. ISBN 9781912651269.