it-swarm.com.de

Der Manager möchte eine kombinierte Entwicklungs- und Produktionsumgebung

Ich arbeite in einem kleinen Programmierteam, das eine größere Organisation unterstützt. In diesem Jahr hat unser Manager beschlossen, Oracle Apex-Technologien zu verwenden, um die überwiegende Mehrheit unserer Unternehmensdaten zu verarbeiten.

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

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

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

19
Anon

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

Sie haben mehrere Aktivitäten gleichzeitig im Gange:

  • entwicklung - wo Entwickler Code festschreiben, Fehler machen, experimentieren usw.
  • testen - Wenn Tests manuell oder automatisiert ausgeführt werden und aufgrund der Komplexität viele Ressourcen verbrauchen können.
  • produktion - wo Wert für Kunden und/oder das Unternehmen geschaffen wird

Möchten Sie, dass all dies in derselben Umgebung geschieht? Möchten Sie, dass das Geschäft zum Stillstand kommt, weil ein neuer Test Ihre Server dazu gebracht hat, auf Festplatten zu tauschen, und jeden Kern des Prozessors verbraucht? Möchten Sie, dass Ihre Tests zum Stillstand kommen, weil ein Entwickler aus einem Skalierungsexperiment eine verschlungene 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 ein Problem darstellt, aber in vielen von ihnen)?

Was verhindert, dass diese Probleme auftreten?

Separate Umgebungen.

Also was brauchst du?

Sie benötigen separate Umgebungen.

Um es formal auszudrücken

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

  • um das Risiko einer Blockierung des Geschäfts und der Softwareentwicklung zu verringern.
  • reduzierung des Risikos, Code in die Produktion zu bringen, der aufgrund des Ad-hoc-Rigging der Entwickler 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 sowie Finanz- und Gesundheitsinformationen umgehen) oder sich mit Testdaten vermischen oder zerstört werden.

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 vorauszusehen oder es durch Erlernen des Schwierigen zu erkennen Weg.

19
Aaron Hall

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

Es ist heutzutage nicht so eindeutig.

Viele Orte führen keine manuellen Tests mehr durch, haben also keine Testdaten an sich. Viele weitere Orte sind so groß, dass sie ihre Produktionsumgebung aus Kostengründen nicht reproduzieren können. Und gerade mit dem explosiven Wachstum von Microservices wird es schwierig, sich schnell verändernde Umgebungen so synchron zu halten, dass sichergestellt ist, dass Tests in einer QS-Umgebung die Dinge genau reproduzieren, um Fehler zu erkennen, die in der Produktion auftreten würden.

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

  • Wenn es sehr schlecht wäre, wenn Ihre Testdaten von Benutzern gesehen würden.
  • Wenn es sehr schlecht wäre, wenn Ihre Produktdaten von Entwicklern/Testern gesehen würden.
  • Wenn Sie Ihren Entwicklern nicht vertrauen können, dass sie nichts schlecht machen, und Sie diese Situation nicht schnell beheben können.
  • Wenn Sie CI so automatisiert haben, dass die Werbung für Code schnell und einfach ist.

Im Wesentlichen, wenn die Kosten für die Umgebung geringer sind als die Kosten für nicht für die Umgebung.

7
Telastyn

Der Hauptgrund (und 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ätssicherungs- und Komponententests durchführen (was 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, würde dies die Produktion und damit die Live-Benutzer und ihre wichtigen Daten beeinträchtigen! Sie möchten 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 verwenden, wenn sich der von Ihnen kontrollierte Code in einer Live-Umgebung befindet! Ihre Benutzer werden verrückt - was ist, wenn Sie zurücksetzen oder zurücksetzen müssen? Was ist, wenn Sie einen drastischen Fehler machen, der fünfzehn Commits tief ist? Wie werden Sie mit der Verzweigung umgehen?

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 wirkt sich letztendlich nicht nur nachteilig auf Ihre nach vorne gerichtete Anwendung (und damit auf Ihren Ruf bei Ihren Benutzern) aus, sondern auch auf die Effizienz Ihres Teams.

3
Brian Wilbur

Nur eine einzige Oracle-Instanz verfügbar zu haben, bedeutet nicht dasselbe wie "keine Trennung zwischen Entwicklungs-, Test- und Produktionsumgebungen"!

Du hast in einem Kommentar geschrieben

Wir verwenden derzeit verschiedene Schemata für verschiedene Projekte

Ok, wenn Sie einige Projekte nur für die Entwicklung und einige für das Testen verwenden, können Sie Ihre Umgebungen bis zu einem gewissen Grad trennen, indem Sie verschiedene Schemata verwenden. Ich denke, 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 Entwicklungsdaten, Testdaten und Kundendaten auf willkürliche Weise in einem Schema mischen. Er möchte höchstwahrscheinlich nur Geld sparen, indem er keinen zweiten Server kauft oder Geld in die Lizenz für eine zweite Instanz investiert.

Daher lautet die echte Frage, die Sie stellen müssen:

Müssen wir verschiedene Instanzen und/oder Server verwenden, um Entwicklungs-, Test- und Produktionsumgebungen zu trennen, oder ist die Schema-Trennung ausreichend?

Das macht die Antwort nicht so eindeutig wie in den anderen Antworten hier. Unterschiedliche Schemas ermöglichen unterschiedliche Zugriffsrechte, sodass Sie innerhalb einer Oracle-Instanz zumindest bis zu einem gewissen Grad isoliert werden können. Ihre Entwickler benötigen jedoch höchstwahrscheinlich einige Administratorrechte in "ihrem" Schema. Daher ist es schwieriger sicherzustellen, dass sie keinen Zugriff auf Produktionsdaten haben, wenn Sie nur eine Instanz verwenden.

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

Am Ende 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 es tolerierbar ist, dass die Trennung zwischen Entwickler, Test und Produktion geringer ist als bei "drei Instanzen/drei Servern"? Ansatz? Wenn Sie nicht effektiv auf diese Weise arbeiten können oder nicht ohne ein hohes Risiko, die Produktion so zu stören, dass Sie Kunden verlieren, haben Sie alle Argumente, die Sie benötigen, um Ihren Manager davon zu überzeugen, mindestens einen zweiten Server zu kaufen.

2
Doc Brown

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 wird die Anwendung nicht einmal gestartet.

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, befindet sich die Produktion auf der neuesten Version 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 die Qualitätssicherung ein Datenbankskript testen, um einige fehlerhafte Daten in der Produktion zu beheben. Möglicherweise verschlimmert das Skript das Problem - stellen Sie eine Datenbanksicherung wieder her und versuchen Sie es erneut. Wenn dies in der Produktion passiert, könnten Sie ein sehr ernstes finanzielles Problem haben.

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

1
user22815

Sie haben bereits die Probleme bemerkt, die nicht mit separaten Umgebungen verursacht. Genau dort haben Sie den Grund für separate Umgebungen: die Probleme zu beseitigen, 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 Sandboxen für Entwickler, in denen die Fehler eines Entwicklers oder auch nur inkompatible Änderungen das gesamte Entwicklungsteam lahm legen.

Dies ist auch das beste Argument, das Sie dem Management vorbringen können, um sich von der einzelnen Umgebung abzuwenden: Zeigen Sie auf die Probleme, die eine einzelne Umgebung bereits verursacht, zeigen Sie die Trendlinie und argumentieren Sie, dass es früher oder später eine geben wird, wenn die Dinge so weitergehen, wie sie sind Ein Problem, dessen Bereinigung viel mehr kostet (sowohl durch direkten Aufwand als auch durch das verlorene Vertrauen der Kunden in die Fähigkeit Ihres Unternehmens, Services bereitzustellen), als die Neukonfiguration von Dingen für separate Umgebungen.

0
Todd Knarr