Ich arbeite in einem kleinen Programmierteam, das eine größere Organisation unterstützt. In diesem Jahr hat unser Manager entschieden, dass wir Oracle Apex-Technologien einsetzen, um den Großteil unserer Unternehmensdaten zu verarbeiten.

Dies wäre in Ordnung, außer wir haben nur einen Apex-Server. Unser Manager hat beschlossen, dass alles in dieser einen Instanz geschieht. Unser Team entwickelt Apps, während unser Manager sie vorführt, und unsere internen Kunden verwenden sie, was aus offensichtlichen Gründen bereits zu Problemen führt!

Ich kann nur erwarten, dass sich dies verschlechtert, wenn wir stärker in Apex investieren, die Apps komplexer werden und die Anzahl der Benutzer steigt. Ich habe gehört, dass die beste Vorgehensweise darin besteht, separate Entwicklungs-, Test- und Produktionsumgebungen zu verwenden. Warum ist dies der Fall?

Die Frage: Warum sollten wir separate Entwicklungs-, Test- und Produktionsumgebungen haben?

Warum sollten wir separate Entwicklungs-, Test- und Produktionsumgebungen haben?

Sie haben mehrere Aktivitäten gleichzeitig im Gange:

• Entwicklung - wo Entwickler Code schreiben, Fehler machen, experimentieren, etc ...
• Testen - Wenn Tests manuell oder automatisiert ausgeführt werden und aufgrund der Komplexität viele Ressourcen verbraucht werden.
• Produktion - wo Wert für Kunden und / oder Unternehmen geschaffen wird

Möchten Sie, dass all dies in derselben Umgebung geschieht? Möchten Sie, dass das Geschäft zum Erliegen kommt, weil ein neuer Test Ihre Server dazu veranlasst hat, auf Festplatten auszutauschen und alle Kerne des Prozessors zu belasten? Wollen Sie, dass Ihre Tests zum Stillstand kommen, weil ein Entwickler aus einem Skalierungsexperiment eine gewundene Gabelbombe gemacht hat? Möchten Sie, dass Code, von dem Sie dachten, dass er aufgrund der Schnur und des Klebebands eines Entwicklers in den Tests funktioniert, in der Produktion ausgeführt wird? Möchten Sie, dass Entwickler mit potenziell sensiblen Produktionsdaten arbeiten (ich weiß, dass dies nicht in allen Unternehmen von Belang ist, aber in vielen von ihnen)?

Was verhindert, dass diese Probleme auftreten?

Getrennte Umgebungen.

Also was brauchst du?

Sie benötigen separate Umgebungen.

Um es formal auszudrücken

Aus folgenden Gründen benötigen Sie separate Umgebungen:

• das Risiko der Blockierung von Geschäftsprozessen und der Softwareentwicklung zu verringern.
• Reduzieren des Risikos, dass Code in die Produktion aufgenommen wird, der aufgrund der Ad-hoc-Takelage der Entwickler die Tests bestanden hat.
• um das Risiko zu verringern, dass Produktionsdaten in die falschen Hände geraten (sehr wichtig, wenn Unternehmen mit sensiblen Daten wie ID-Nummern und Finanz- und Gesundheitsinformationen umgehen) oder sich mit Testdaten vermischen oder diese zerstören.

Für Ihren Kontext eine neue Technologieplattform

Vielleicht ist dies noch keine echte Produktion (da es sich um eine relativ neue Plattform handelt), aber Sie erhalten Ihre separaten Umgebungen, wenn sich das Unternehmen darauf verlässt und sie sind entweder klug genug, um das Risiko vorherzusehen oder es zu erkennen, indem sie sich anstrengen Weg.

Ich habe gehört, dass die beste Vorgehensweise darin besteht, separate Entwicklungs-, Test- und Produktionsumgebungen zu verwenden. Warum ist dies der Fall?

Es ist heutzutage nicht so eindeutig.

Viele Orte führen keine manuellen Tests mehr durch. Sie haben also keine Testdaten mehr per se. Viele weitere Orte sind so groß, dass sie ihre Produktionsumgebung aus Kostengründen nicht reproduzieren können. Und vor allem angesichts des explosionsartigen Wachstums von Microservices wird es schwierig, schnell wechselnde Umgebungen so synchron zu halten, dass sichergestellt ist, dass Tests in einer QS-Umgebung die Dinge genau wiedergeben, um Fehler zu erkennen, die in der Produktion auftreten würden.

Warum sollten wir separate Entwicklungs-, Test- und Produktionsumgebungen haben?

• Wenn Ihre Testdaten von Benutzern gesehen werden, wäre dies sehr schlecht.
• Wenn Ihre Produktdaten von Entwicklern / Testern gesehen werden, wäre dies sehr schlecht.
• Wenn Sie Ihren Entwicklern nicht vertrauen können, dass sie nichts schlechtes tun, können Sie diese Situation nicht schnell beheben.
• Wenn Sie CI so automatisiert haben, dass das Bewerben von Code schnell und einfach ist.

Im Wesentlichen , wenn die Kosten die Umgebungen, die geringer ist als die Kosten für die nicht die Umgebungen mit .

Der Hauptgrund (und der offensichtlichste) ist, dass Sie niemals Test- und Produktionsdaten mischen möchten. Dies kann sowohl für Benutzer des Systems als auch für Entwickler sehr schnell unglaublich verwirrend werden. Wenn Sie Qualitätssicherung und Unit-Tests durchführen (was auch immer Sie tun sollten), müssen Sie sicherstellen, dass sie sich in einer vollständig getrennten Umgebung befinden. Wenn etwas in Ihrer Entwicklungsumgebung oder in der Qualitätssicherung explodiert, wirkt sich dies nachteilig auf die Produktion und damit auf die aktiven Benutzer und ihre wichtigen Daten aus! Sie wollen absolut nicht, dass dies die Produktion beeinflusst!

Dies erstreckt sich auf die normalen Dienste, die Sie in Ihrer täglichen Arbeit verwenden sollten, z. B. Ihre Versionskontrolle. Sie können die Versionskontrolle möglicherweise nicht richtig nutzen, wenn sich der Code, den Sie steuern, in einer Live-Umgebung befindet! Ihre Benutzer werden wahnsinnig - was ist, wenn Sie zurücksetzen oder ein Rollback durchführen müssen? Was ist, wenn Sie einen drastischen Fehler machen, der 15 Commits tief geht? Wie gehen Sie mit der Verzweigung um?

Zumindest sollten Sie Ihre Umgebung in mehrere virtuelle Instanzen aufteilen, aber Sie müssen wirklich genau das tun, was Sie gesagt haben, und für jede Umgebung vollständig separate Instanzen haben. Idealerweise Entwicklung, Qualitätssicherung, Inszenierung und Produktion.

All dies führt letztendlich zu einem erheblichen Nachteil nicht nur für Ihre Front-Facing-Anwendung (und damit für Ihren Ruf bei Ihren Benutzern), sondern auch für die Effizienz Ihres Teams.

Nur eine einzige Oracle-Instanz verfügbar zu haben, bedeutet nicht das Gleiche wie "Keine Trennung zwischen Entwicklungs-, Test- und Produktionsumgebung"!

Du hast in einem Kommentar geschrieben

Derzeit verwenden wir verschiedene Schemata für verschiedene Projekte

Ok, also durch einige Projekte widmen nur für die Entwicklung, und einige für die Prüfung, Sie können Ihre Umgebungen bis zu einem gewissen Grad trennen, die von verschiedenen Schemata verwenden. Ich vermute, Sie haben dies bereits getan, da dies der einzig sinnvolle Ansatz ist, den ich kenne, wenn keine Instanzentrennung geplant ist. Ich kann mir nicht vorstellen, dass Ihr Manager so verrückt ist, dass er möchte, dass Sie Entwicklerdaten, Testdaten und Kundendaten auf beliebige Weise in einem Schema mischen. Er möchte wahrscheinlich nur Geld sparen, indem er keinen zweiten Server kauft oder Geld in die Lizenz für eine zweite Instanz investiert.

Die eigentliche Frage, die Sie stellen müssen, lautet daher:

Müssen unterschiedliche Instanzen und / oder Server zum Trennen von Entwicklungs-, Test- und Produktionsumgebungen verwendet werden, oder ist eine Schematrennung ausreichend?

Das macht die Antwort nicht so eindeutig wie in den anderen Antworten hier. Unterschiedliche Schemata ermöglichen unterschiedliche Zugriffsrechte, sodass Sie innerhalb einer Oracle-Instanz zumindest eine gewisse Isolation erzielen können. Ihre Entwickler benötigen jedoch höchstwahrscheinlich einige Administratorrechte innerhalb "ihres" Schemas, sodass es schwieriger wird, sicherzustellen, dass sie keinen Zugriff auf Produktionsdaten haben, wenn Sie nur eine Instanz verwenden.

Darüber hinaus bedeutet eine Instanz / ein Server auch gemeinsame Ressourcen zwischen Entwickler, Test und Produktion - gemeinsame Benutzer- / Schema-Verwaltung, gemeinsamer Speicherplatz, gemeinsame CPUs, gemeinsame Netzwerkbandbreite. Kombinieren Sie dies mit dem "Gesetz der undichten Abstraktionen" , und es wird klar sein, dass die Verwendung von nur einer Instanz ein gewisses Risiko birgt, unerwünschte Nebenwirkungen zwischen der Entwicklungs-, Test- und Produktumgebung zu bekommen.

Letztendlich müssen Sie selbst entscheiden: Können Sie effektiv mit den Nachteilen des Ansatzes arbeiten? Ist Ihre Anwendung nicht so ressourcenintensiv und Ihre Produktionsdaten nicht so "geheim", dass eine geringere Trennung zwischen Entwickler, Test und Produktion tolerierbar ist als die, die Sie von "drei Instanzen / drei Servern" erhalten würden? Ansatz? Wenn Sie auf diese Weise nicht effektiv arbeiten können oder nicht ohne ein hohes Risiko, die Produktion zu stören und Kunden zu verlieren, haben Sie alle Argumente, die Sie benötigen, um Ihren Manager davon zu überzeugen, mindestens einen zweiten Server zu kaufen.

Sie benötigen mehrere Umgebungstypen und möglicherweise sogar mehrere Server in jeder Umgebung.

Entwickler können Code in der Entwicklung aktualisieren. Der Code funktioniert möglicherweise nicht einmal - möglicherweise startet die Anwendung nicht einmal.

Dies hat keine Auswirkungen auf die Qualitätssicherung, die den neuesten stabilen Build in ihrer eigenen Umgebung testet.

Da sowohl die Entwicklung als auch die Qualitätssicherung ihre Umgebungen aktualisieren, ist die Produktion auf dem neuesten Release-Stand von vor sechs Monaten und wird von den Änderungen in anderen Umgebungen nicht beeinflusst.

Diese Änderungen, die in verschiedenen Umgebungen eingeführt werden, können Code oder Daten sein. Möglicherweise muss QA ein Datenbankskript testen, mit dem fehlerhafte Daten in der Produktion behoben werden können. Vielleicht verschlimmert das Skript das Problem - stellen Sie eine Datenbanksicherung wieder her und versuchen Sie es erneut. Wenn das in der Produktion passiert, könnten Sie ein ernstes finanzielles Problem haben.

Was passiert, wenn Sie mehrere Releases haben? Möglicherweise entwickeln Sie Version 2.0, benötigen jedoch weiterhin Fehlerbehebungsversionen für den 1.0-Wartungszweig. Jetzt benötigen Sie mehrere Entwicklungs- und QS-Umgebungen, um sicherzustellen, dass Sie immer einen Zweig entwickeln und testen können, wenn ein kritischer Fehler entdeckt wird, der gestern behoben werden muss.

Sie haben bereits die Probleme bemerkt , die nicht getrennten Umgebungen Ursachen haben. Genau da haben Sie den fundamentalen Grund für separate Umgebungen: die Beseitigung der Probleme, die durch die Konflikte verursacht werden, die unvermeidlich auftreten, wenn Sie versuchen, Entwicklungs-, Test- und Produktionsvorgänge in einer einzigen Umgebung durchzuführen. Die gleiche Überlegung gilt für die Bereitstellung individueller Sandboxes für Entwickler. Sie verhindert, dass die Fehler eines Entwicklers oder auch nur inkompatible Änderungen das gesamte Entwicklungsteam lahm legen.

Dies ist auch das beste Argument, das Sie gegenüber dem Management vorbringen können, wenn Sie sich von einer einzelnen Umgebung entfernen: Zeigen Sie auf die Probleme, die eine einzelne Umgebung bereits verursacht, und zeigen Sie die Trendlinie Ein Problem, dessen Bereinigung viel mehr kostet (sowohl direkter Aufwand als auch das verlorene Vertrauen der Kunden in die Fähigkeit Ihres Unternehmens, Dienste bereitzustellen), als die Neukonfiguration von Dingen für separate Umgebungen.

Es gibt viele entgegengesetzte Kräfte und Dynamiken. Viele Server und nur ein einziger Server sind mit Kosten verbunden. Ich denke, diese Frage kann weiter gehen als nur die Datenbank? Ich mag missverstehen, aber es handelt sich um ein systembedingtes Missverständnis, das sich aus den Kosten von Sachgegenständen im Vergleich zu abstrakt ergibt

Typischerweise sind die offensichtlichen Kosten leicht zu verstehen.

Abstrakte Kosten sind schwerer zu quantifizieren und damit schwerer zu verstehen. Technische Schulden, Fehlerkosten, Stresskosten, Belastung der Entwickler, Auswirkungen von Änderungen, Regressionstests, Auswirkungen von Ausfallzeiten usw. sind schwerer zu erklären.

Unterschiedliche Umgebungen Umgebungen werden normalerweise nach Daten und / oder Zweck getrennt. Jede Umgebung hat eine andere Funktion. Die Änderungsrate auf einem System, dh. Wie oft wird es aktualisiert, welche Art von Änderungen und Auswirkungen von Änderungen werden alle berücksichtigt.

Wir verwenden verschiedene Umgebungen, um Veränderungen zu trivialisieren.

Wir verwenden unterschiedliche Umgebungen und bieten daher Robustheit und Sicherheit für die Umgebung, die sich nicht geändert hat.

Wir verwenden Umgebungen, um die Auswirkungen einer Änderung zu berücksichtigen.

Wir verwenden Umgebungen, um die mit Änderungen verbundenen Kosten zu senken.

Das Testen und Stabilisieren eines Systems kostet viel. Sie erstellen Umgebungen, um die Investition in die stabile Umgebung zu sichern.

Sie sind nie zu klein, um sich an pragmatische, kostensparende, sorgfältige und bewährte Prozessmuster zu halten.

Wenn Sie eine Umgebung für alles verwenden, können Sie alle Ihre Fotos auf einer Festplatte speichern, aber Sie werden es bereuen.

Einige Leute brauchen Beweise Ich habe in vielen Situationen mit Kunden zu tun gehabt oder andere, die die Kosten für die Gewährleistung von Robustheit und die Befolgung von Best Practices nicht zu schätzen wussten. Ich würde vorschlagen, dass Sie einige Beispiele für reale Fälle zusammenstellen, in denen die Kosten klar definiert sind.