Jedes Firma hat eine Testumgebung. Gewisse Firmen haben den Luxus einer getrennten Produktivumgebung
Freies Zitat nach "Level1Techs" von Youtube.
Was dieser Satz aussagen soll, ist: Hat man als Firma keine Testumgebung, so weis man erst ob etwas funktioniert, wenn man die ungetesteten Änderungen an der Produktivumgebung durchführt. Jedem ITler sollten sich jedoch die Nackenhaare aufstellen, wenn man auch nur daran denkt. Jedoch gibt es wirklich nicht viele Firmen welche sich eine saubere Testumgebung leisten. Bei meinem Arbeitgeber fehlen uns eindeutig die Arbeitszeit und das Geld um eine Testumgebung betreiben zu können. Jedoch ist unser Team genügend klein und flexibel, das mögliche Probleme während der Arbeitszeit durch Anpassen der momentanen Arbeit abgefangen werden können.
Ein wichtiger Punkt für diesen Artikel ist der Unterschied zwischen Testumgebung und Laborumgebung. Daher werde ich diesen Unterschied in den folgenden Artikeln erleutern. Es kann sein das offiziele Begriffserklärungen nach Duden oder ähnlichen nicht meinen Erleuterungen übereinstimmen. Das hat mich bisher noch nie gross gestörrt :-)
Die Begriffserklärungen basieren auf meiner Meinung, sollten jedoch die Idee des Artikels erleutern und verdeutlichen können.
Laborumgebung
Eine Laborumgebung wird genutzt, um Hard- und Software zu testen. Dabei geht es meistens nicht um ein perfekt optimiertes System, sonder darum zu testen ob mit der Gewählten Kombination von Hardware, Betriebssystem und Anwendersoftware die gewünschte Wirkung erzielt werden kann.
Auch kann eine Laborumgebung genutzt werden um neuen Mitrabeitenden den Toolstack des Arbeitgebers zu zeigen und sie in einer getrennten Umgebung lernen zu lassen. Dies ist vor allem wichtig, wenn man als Arbeitgeber nicht die Industriestandards benutzt.
Testumgebung
Die Testufmgebung sollte eine möglichst komplette Kopie der produktiven Umgebung sein. Sobald auch nur kleine Unterschiede bestehen, kann dies zu Problemen beim deployen der Software führen. Auch sollte eine Testumgebung nicht für Hardwaretests oder Einführungen von neuen Mitarbeitern benutzt werden.
Aufbau
Der Aufbau der Testumgebung hängt von der Produktiven Umgebung ab. So kann man in der Testumgebung die Anzahl Nodes eines Kubernetes-Cluster reduzieren. So kann man direkt die Software schneller an ihre Grenzen treiben. Jedoch können sich auch Probleme erst aufzeigen, wenn man eine grosse Anzahl von Nodes zur Verfügung hat. Hier kann ich kein Beispiel anführen. Jedoch hat die Geschichte immer wieder gezeigt, dass Problem durch die unerwartesten Dinge auftauchen können.
Wird keine Clusterlösung wie Kubernetes genutzt, so sollte die Anzahl an Servern mit der produktiven Umgebung identisch sein. Man kann vielleicht gewisse Software in der Testumgebung auf den gleichen Servern installieren, während sie in der Produktiven Umgebung auf unterschiedlichen Servern laufen. Auf den ersten Blick sollten dabei die Probleme in der Testumgebung entstehen, wenn die Softwaren gegeneinander kämpfen. Jedoch wird in einer solchen Konfiguration das Netzwerk nicht sauber getestet, da die beiden Softwaren den Server nicht verlassen müssen um miteinander zu reden. Auch können Szenarrien entstehen, wo die sich zwei Softwaren in der Rechte- oder Dateiverwaltung unterstützen und bei einer getrennten Installation müssten die Rechte von Hand angepasst werden.
Die Hardware sollte identisch mit der Produktiven Umgebung gewählt werden. Dies Betrifft nicht nur die Hardware von Servern, sondern auch die Netzwerkinfrastruktur. So kann ein Netzwerkswitch problemlos eine Verbindung mit dem Server über ein DAC aufbauen, während ein anderes Switchmodel mit dem gleichen DAC probleme macht. siehe: SFP - Ein Standard ohne Rückgrat.
Wird ein Hybervisor benutzt, so sollte die Version in der Test- und der Produktivumgebung identisch sein. Problematisch wird es, wenn beide Umgebunden unterschiedliche Hypervisor benutzten. So konnte ich im lokalen XCP-ng ein K3s Cluster mit redundanten Master-Nodes ohne Probleme hochziehen. Als ich jedoch im die gleiche Konfiguration in einer gemieteten Cloudumgebung unter VMWare anwendete, funktionierte das Netzwerk nicht mehr. Schlussendlich musste ich die Netzwerkverbindung von VXLAN auf Wireguard wechseln.
Konfiguration
Sobald man eine getrennte Test- und Produktivumgebung aufbauen möchte, muss man sich Gedanken über die Konfiguration der Umgebung machen. Werden beide Umgebungen von Hand aufgebaut und konfiguriert, so werden sich zwangsläufig Fehler einschleichen. Besser ist hier eine Automatisierungslösung oder der Ansatz von Infrastructure as Code (IaC). Dabei gibt es verschiedene Stuffen. Teilweise wird nur die Softwareinstallation automatisiert. Bei grösseren Infrastrukturen zum Teil direkt schon das deployen und installieren des Serverbetriebssystems. Wie weit man die Automatisierung treiben möchte, ist jedem selber überlassen.
Bei uns wird der grösste Teil noch von Hand eingerichtet, jedoch werden die mühsameren Konfigurationen durch Ansible-Playbooks erledigt. Dabei muss aber das Betriebssystem schon installiert und ein SSH-fähiger Benutzer vorhanden sein.
Werden die Server automatisch konfiguriert, so kann die Testumgebung mit den gleichen Automatisierungen gebaut werden. Dies führt automatisch dazu, das beide Umgebungen identisch sind. Je mehr Automatisiert wird, desto weniger Unterschiede existieren.
Tests
Eine Testumgebung ohne Tests nützt nicht viel. Beim Bau der Testumgebung muss darauf geachtet werden, wie allfällige Tests ausgeführt werden. Beim einers einfachen Umgebung kann ein Mensch die Oberfläche einer Webapp von Hand durchklicken und testen. Sobald die Umgebung komplexer werden und zum Teil über Schnittstellen zu fremden Systemen Verfügen, kann dies nicht mehr sinnvoll durch einen Menschen überprüft werden.
Diese Tests erfolgen am Besten automatisiert, damit auch bei jedem Test das gleiche Ergebniss herauskommt. Ist die Software genügend modular gebaut, können die meisten Test auf der Modulebene erfolgen. Trotzdem sollte das gesamte System auch Tests unterzogen werden.
Sind die Tests automatisert, kann der Wechsel von der Test- zur Produktivumgebung automatisch erfolgen. Dies sollte nur erfollgen, wenn keiner der Tests von Hand ausgeführt werden muss und erfordert eine genügen gute Testabdeckung.
Je nach Testlösung, muss eine Testumgebung darauf ausgelegt sein. So kann man einen Belastungstest nur durchführen, wenn auch das Netzwerk identisch ist mit der produktiven Umgebung. Dabei ist nicht nur die "Verdrahtung" sondern auch die Bandbreite Wichtig. In der Theorie ist eine 10Gbit Leitung 10x schneller wie eine 1Gbit Leitung. Jedoch ist die Last einer 10Gbit Leitung für die CPU auch grösser. Des weitern wird bei einem langsameren Netzwerk der Server nicht voll ausgelastet. Dabei kann es sein das die Softwarre bei 1Gbit ohne probleme läuft. Werden jedoch plötzlich 10Gbit geflutet, kann dies zu plötzlich die CPU an den Anschlag bringen. Nutzt die Software nur einen einzelnen Thread, kann dies schnell zu Problemen führen. So kann eine schneller Netzwerkverbingung einen Kernen voll auslasten und trotz theoretischen 10Gbit nur ca. 3-4Gbit durchlassen.
Der Kunde testet
Eine Bewegung in der Softwareentwicklung, welche ich nicht beführworte, ist die, dass der Kunde die Software testet. Ein Beispiel dafür ist zum Beispiel das Windows Insider Program. Ist man dort angemeldet, bekommt man die Updates vor allen anderen und kann Rückmeldung dazu geben. Dabei ist dem Programm zugute zu halten, dass man sich anmelden muss und nicht automatisch zugeteilt wird. Sprich der Nutzer hat die Wahl.
Jedoch ist euch auch schon aufgefallen, das gewisse Nutzer Änderungen im Windows vor den anderen haben, ohne im Insider Programm zu sein. Dabei sorgt Microsoft dafür, dass die Updates schrittweise an die Nutzer ausgeliefert werden. So kann man die Stimmung einfangen, bevor überhaupt alle Nutzer betroffen sind.
Auch ein gutes Beispiel ist YouTube. Dabei werden Änderungen, zum Beispiel an der Oberfläche, zuerst einem kleinen Teil der Nutzer zur Verffügung gestellt. Sollten die zu keinem Aufschrei führen, so werden die Änderungen schrittweise weiteren Nutzern zur Verfügung gestellt. Haben jedoch die Änderungen jedoch zu Problemen und negativen Meldungen geführt, so sind nicht alle Nutzer betroffen.
Eine vollkommen ander Praxis ist, dass man die Software dem Nutzer zum vollen Preis verkauft, aber von Anfang an klar stellt, dass die Software nicht getestet ist. Ich kann hier keine Beispiele anführen, ohne gewissen Personen Probleme zu bereiten.
Jedoch hat diese Programmfamilie auch im normalen Betrieb immer wieder Probleme, welche durch eine bessere Testabdeckung abgefangen werden können.
Fazit
Ob man sich die Arbeit einer Testumgebung macht oder nicht muss man selber entscheiden. Jedoch hat eine saubere Testumgebung klare Vorteile und kann auch den Eindruck beim Nutzer verbessern.
Der Aufbau kann am Anfang viel Zeit kosten, vorallem, wenn man au Automatisierung setzt. Jedoch ist diese Zeit schnell wieder eingeholt, wenn man die Produktivumgebung mit den Automatisierungen der Testumgebung in einem Bruchteil der Zeit eingerichtet hat. Auch verringert eine gute Automatisierung den Wartungsaufwand von beiden Umgebungen.