Eine neue Funktion für die Auftragsbearbeitung ist fertig. In der Testumgebung funktioniert alles: Mitarbeiter können Bestellungen erfassen, Daten werden verarbeitet und die vorgesehenen Tests sind erfolgreich. Nach dem Release in die Produktivumgebung treten jedoch Fehler auf. Einzelne Aufträge erreichen das ERP nicht oder eine benötigte Schnittstelle reagiert anders als erwartet. Wenn Software in der Testumgebung funktioniert, aber in Produktion nicht, liegt die Ursache häufig im Zusammenspiel von Anwendung, Konfiguration und Infrastruktur – nicht zwangsläufig im neu entwickelten Code.
1. Warum funktioniert Software im Test, aber nicht in Produktion?
Eine Testumgebung soll helfen, Fehler vor der Veröffentlichung zu erkennen. Sie bildet jedoch nicht automatisch sämtliche Bedingungen der späteren Produktivumgebung ab.
Während eines Tests werden beispielsweise vorbereitete Datensätze verwendet. Die produktive Anwendung verarbeitet dagegen echte Bestellungen, größere Datenmengen und Verbindungen zu weiteren Geschäftssystemen.
Hinzu kommen technische Unterschiede: andere Datenbankversionen, Berechtigungen, Netzwerkeinstellungen oder Konfigurationswerte.
Eine Anwendung kann deshalb erfolgreich getestet worden sein und nach dem Deployment trotzdem Probleme verursachen.
Für Unternehmen ist zunächst wichtig, zwischen zwei Situationen zu unterscheiden:
- Deployment fehlgeschlagen: Die neue Version wurde nicht wie vorgesehen bereitgestellt.
- Deployment erfolgreich, Anwendung fehlerhaft: Die neue Version läuft, aber eine wichtige Funktion arbeitet unter produktiven Bedingungen nicht korrekt.
Im zweiten Fall genügt es nicht, ausschließlich den Status der CI/CD-Pipeline zu kontrollieren.
Wenn bereits der Build oder das Deployment selbst scheitert, hilft unser Beitrag CI/CD-Pipeline: Fehler finden und beheben.
2. Welche Unterschiede zwischen Test- und Produktivumgebung sind entscheidend?
Test- und Produktivumgebung müssen nicht vollständig identisch sein. Unterschiede bei Daten, Zugangsdaten oder externen Endpunkten sind häufig notwendig.
Problematisch wird es, wenn relevante Abweichungen nicht bekannt sind oder bei der Entwicklung und Prüfung unberücksichtigt bleiben.
| Bereich | Mögliches Problem | Was geprüft werden sollte |
|---|---|---|
| Laufzeit und Bibliotheken | Eine Anwendung verwendet produktiv andere Versionen. | Laufzeitversionen, Abhängigkeiten und bereitgestelltes Artefakt |
| Konfiguration | Eine erforderliche Einstellung fehlt oder verweist auf das falsche System. | Freigegebene Umgebungswerte und Konfigurationsquellen |
| Datenbank | Abfragen oder Migrationen verhalten sich mit produktiven Daten anders. | Datenbankversion, Schema und relevante Datenbesonderheiten |
| Berechtigungen | Die produktive Anwendung darf eine benötigte Aktion nicht ausführen. | Servicekonten, Rollen und tatsächliche Zugriffsrechte |
| Schnittstellen | Ein Testsystem antwortet anders als die produktive API. | Endpunkte, Versionen, erlaubte Zugriffe und Fehlerbehandlung |
| Last und Hintergrundprozesse | Die Anwendung funktioniert mit wenigen Testdatensätzen, aber nicht unter realer Nutzung. | Ressourcen, Warteschlangen und Verarbeitung größerer Datenmengen |
Das Prinzip, Entwicklungs-, Test- und Produktivumgebungen technisch möglichst ähnlich zu halten, ist als Dev/Prod Parity bekannt. Die Methodik Twelve-Factor App beschreibt insbesondere die Bedeutung vergleichbarer Laufzeiten und angebundener Dienste.
Das Ziel ist nicht, produktive Zugangsdaten oder Kundendaten unkontrolliert in die Testumgebung zu kopieren. Entscheidend ist, relevante technische Unterschiede bewusst zu verwalten und geeignete Testbedingungen herzustellen.
3. Praxisbeispiel: Bestellungen erreichen nach dem Release das ERP nicht
Angenommen, ein mittelständischer Großhändler betreibt einen B2B-Onlineshop. Eingehende Bestellungen werden über eine individuell entwickelte Schnittstelle an das ERP-System übertragen.
Das Entwicklungsteam erweitert die Schnittstelle um ein zusätzliches Bestellfeld. In der Testumgebung funktioniert die Übertragung.
Nach dem produktiven Release werden neue Bestellungen zwar im Shop gespeichert, jedoch nicht zuverlässig im ERP angelegt.
Was ist tatsächlich passiert?
Die Untersuchung zeigt, dass die Testumgebung einen anderen API-Endpunkt verwendet als die Produktivumgebung.
Im Test akzeptiert die angebundene Anwendung das neue Feld bereits. Die produktive ERP-Schnittstelle erwartet dagegen noch die bisherige Datenstruktur.
Die Shop-Anwendung läuft technisch weiter. Auch das Deployment wurde erfolgreich abgeschlossen. Erst bei der tatsächlichen Bestellübertragung entsteht der Fehler.
Warum ist das für das Unternehmen kritisch?
Ein erfolgreicher Bestellabschluss im Shop bedeutet in diesem Fall nicht, dass der Auftrag im ERP angekommen ist.
Das kann Folgen für Auftragsbestätigung, Lagerbearbeitung und Versand haben. Außerdem besteht das Risiko, dass Mitarbeiter fehlende Bestellungen manuell nacherfassen und dadurch doppelte Vorgänge entstehen.
Deshalb muss die Untersuchung zwei Fragen beantworten: Warum wird die Bestellung nicht verarbeitet, und welche Aufträge sind seit dem Release bereits betroffen?
Wie wird die Lösung überprüft?
Nachdem die Schnittstellenversionen und das vereinbarte Datenformat abgestimmt wurden, erfolgt eine kontrollierte Korrektur.
Danach wird nicht nur ein neuer Testauftrag durchgeführt. Das Team ermittelt auch, welche früheren Bestellungen im ERP fehlen oder bereits anderweitig bearbeitet wurden.
Erst nach dieser Prüfung können ausstehende Vorgänge gezielt nachbearbeitet werden, ohne bereits vorhandene Bestellungen unkontrolliert erneut anzulegen.
Das Ergebnis ist eine nachvollziehbare Verarbeitung der betroffenen Aufträge – nicht lediglich eine fehlerfreie technische Statusanzeige.
4. Wie lassen sich Test- und Produktivumgebung sinnvoll vergleichen?
Ein zielführender Vergleich beginnt mit der betroffenen Geschäftsfunktion. Nicht jede technische Abweichung ist für den konkreten Fehler relevant.
- Geschäftsproblem eingrenzen: Welche Funktion arbeitet produktiv anders als im Test?
- Version bestimmen: Wurde tatsächlich derselbe freigegebene Softwarestand verwendet?
- Konfiguration vergleichen: Welche relevanten Einstellungen, Berechtigungen und Endpunkte unterscheiden sich?
- Abhängigkeiten prüfen: Welche Datenbanken, APIs und Hintergrundprozesse benötigt die Funktion?
- Ursache bestätigen: Lässt sich der festgestellte Unterschied mit der beobachteten Fehlfunktion verbinden?
- Änderung kontrollieren: Wird der betroffene Prozess nach der Korrektur vollständig und korrekt ausgeführt?
Bei GitLab lassen sich über Environments unterschiedliche Deployment-Ziele verwalten und bestimmte Variablen einer Umgebung zuordnen. Die offizielle GitLab-Dokumentation zu Environments beschreibt diese Möglichkeiten.
Welche Funktionen verfügbar sind, hängt vom eingesetzten CI/CD-System und gegebenenfalls vom Tarif ab.
Bei der Prüfung sensibler Konfigurationen sollten Werte nicht ungeschützt in Logs oder Fehlerberichte kopiert werden. Häufig reicht es zunächst festzustellen, ob eine erforderliche Einstellung vorhanden, korrekt zugeordnet und für die Anwendung verfügbar ist.
5. Wie lassen sich solche Probleme bei späteren Releases reduzieren?
Ein einzelner Fehler lässt sich häufig gezielt beheben. Wenn ähnliche Abweichungen regelmäßig auftreten, sollte jedoch der gesamte Umgang mit den Umgebungen überprüft werden.
Konfigurationen nachvollziehbar verwalten
Wichtige Einstellungen sollten nicht ausschließlich durch manuelle Änderungen auf einzelnen Servern entstehen.
Geeignete Konfigurationsverwaltung und wiederholbare Einrichtungsschritte können helfen, unbeabsichtigte Unterschiede zu reduzieren.
Tests an realistischen Schnittstellen durchführen
Eine vereinfachte Testantwort kann für die Entwicklung nützlich sein. Sie ersetzt aber nicht automatisch die Prüfung der tatsächlichen Schnittstellenversion und des vereinbarten Datenformats.
Bei kritischen Integrationen kann deshalb eine geeignete Testverbindung zum vorgesehenen Fremdsystem erforderlich sein.
Geschäftsprozesse nach dem Release prüfen
Technische Tests sollten um ausgewählte fachliche Prüfungen ergänzt werden.
Bei einem B2B-Shop kann das beispielsweise bedeuten:
- Eine Bestellung wird im Shop korrekt erfasst.
- Die Übertragung an das ERP funktioniert.
- Der Auftrag erhält im Zielsystem den erwarteten Status.
- Ein Fehler führt nicht unbemerkt zur doppelten Verarbeitung.
Diese Prüfungen müssen zur tatsächlichen Anwendung passen. Ein erfolgreiches Deployment garantiert weder einen fehlerfreien Geschäftsprozess noch einen unterbrechungsfreien Betrieb.
Wie Teams zusätzlich Zuständigkeiten und Release-Schritte nachvollziehbar organisieren können, erläutert unser Beitrag Software-Release dokumentieren und Abhängigkeiten reduzieren.
6. Wann ist externe DevOps-Unterstützung sinnvoll?
Externe Unterstützung kann sinnvoll sein, wenn Test- und Produktivumgebung über längere Zeit unterschiedlich eingerichtet wurden, wichtige Konfigurationsentscheidungen nicht dokumentiert sind oder wiederholt Fehler erst nach einem Release sichtbar werden.
Für eine erste technische Abstimmung sind vor allem folgende Informationen hilfreich:
- Welche Anwendung und welcher Geschäftsprozess sind betroffen?
- Welche Test- und Produktivumgebungen werden verwendet?
- Welche Softwareversion wurde veröffentlicht?
- Welche Fehler treten ausschließlich produktiv auf?
- Welche Änderungen und Prüfungen wurden bereits durchgeführt?
Kubertino unterstützt Unternehmen dabei, bestehende Test- und Produktivumgebungen aufeinander abzustimmen, Konfigurationsprobleme zu untersuchen und wiederkehrende Einrichtungsschritte zu automatisieren.
Dabei betrachten wir Anwendung, Deployment-Prozess und Infrastruktur gemeinsam. Der konkrete Umfang wird anhand der vorhandenen Systeme und des gewünschten Ergebnisses vereinbart.
Unsere Leistung DevOps-Outsourcing beschreibt die mögliche Unterstützung von der technischen Analyse bis zur Umsetzung und Übergabe.
Ein sinnvoller erster Auftrag kann darin bestehen, eine wiederkehrende Abweichung zwischen zwei Umgebungen zu untersuchen und einen klaren Prüfablauf für den nächsten Release festzulegen.
7. Häufige Fragen zu Test- und Produktivumgebungen
Warum funktioniert eine Anwendung in der Testumgebung, aber nicht produktiv?
Häufig unterscheiden sich Konfiguration, Berechtigungen, Datenbanken, Laufzeitversionen oder angebundene Systeme. Auch die Menge und Struktur produktiver Daten kann Fehler sichtbar machen, die im Test nicht aufgetreten sind.
Müssen Test- und Produktivumgebung identisch sein?
Nein. Unterschiedliche Zugangsdaten, Datenbestände und externe Endpunkte können notwendig sein. Relevante Laufzeiten, technische Abhängigkeiten und Konfigurationsregeln sollten jedoch möglichst vergleichbar und dokumentiert sein.
Kann eine erfolgreiche CI/CD-Pipeline trotzdem fehlerhafte Software veröffentlichen?
Ja. Eine erfolgreiche Pipeline bestätigt nur die vorgesehenen technischen Schritte und Prüfungen. Nicht getestete Geschäftsabläufe oder Unterschiede der Zielumgebung können weiterhin Fehler verursachen.
Hilft eine zusätzliche Staging-Umgebung?
Eine geeignete Staging-Umgebung kann helfen, produktionsnahe Bedingungen vor einem Release zu prüfen. Entscheidend ist aber ihre tatsächliche Konfiguration. Eine zusätzliche Umgebung allein verhindert keine Fehler.