Entwicklung auf einem Produktionsserver

35

Heute wurde ich wegen der Entwicklung einer Anwendung auf einem Produktionsserver angeschrien. Zitat: "Die Entwicklung auf einem Produktionsserver ist nicht akzeptabel - niemals! "

Hier ist die Situation.

  1. Ich habe eine Entwicklungsinstanz eingerichtet: http://example.com:3000
  2. Die Produktionsinstanz ist: http://example.com
  3. Ich beende alle meine Entwicklungsarbeiten an http://example.com:3000und wenn der Kunde mit den Änderungen zufrieden ist, verschiebe ich sie zu http://example.com.

Die Anwendung, mit der ich arbeite, ist eine alte Ruby on Rails- Anwendung, und ich muss sagen, dass ich anfangs versucht habe, eine Entwicklungsumgebung lokal einzurichten, aber ich konnte sie nie zum Laufen bringen. Nachdem ich es eine Weile versucht hatte, gab ich es auf und beschloss, mich auf dem Produktionsserver zu entwickeln.

Bin ich wieder ein Idiot? Wahrscheinlich schon, aber ich mache jetzt seit ein paar Jahren Webentwicklung und bin noch nie auf eine solche Situation gestoßen. Wer hat Recht und warum?

luk3thomas
quelle
46
Die einzig gültige Antwort wäre: "Einen Produktionsserver zu haben, der in der Entwicklung nicht reproduziert werden kann, ist nicht akzeptabel - niemals."
Blrfl
49
Für mich ist das eigentliche Problem, dass Sie ein Produktionssystem haben, in dem Sie keine Ahnung haben, was läuft oder wie es konfiguriert ist. Was würden Sie tun, wenn Ihre Produktionsmaschine abstürzt und alle Daten verliert? Wenn Sie jetzt keine ordnungsgemäße Entwicklungsumgebung einrichten können, was werden Sie tun, wenn dies Ihre einzige Option ist?
Greg Hewgill
@ GregHewgill, ja, das ist ein guter Punkt
Luk3thomas
25
Greg hat recht, wenn Sie nicht genug über die Anwendung wissen, um die Umgebung auf einem Entwicklungscomputer zu reproduzieren, sollten Sie nicht nur nicht auf dem Produktionscomputer entwickeln und testen, sondern auch keinen Zugriff auf diesen Computer erhalten. Sie haben sich eindeutig geirrt, aber ich hätte Ihren Chef angebrüllt, dass er Ihnen Zugang gewährt hat, bevor Sie vollständig verstanden haben, was Sie getan haben.
maple_shaft
3
Wenn Sie keine lokale Entwicklungsumgebung einrichten können, sollten Sie überhaupt nicht entwickeln.
Jas

Antworten:

58

Früher habe ich auf dem Produktionsserver entwickelt. Es kann gut funktionieren, ist jedoch aus mindestens zwei Gründen nicht zu empfehlen:

  1. Entwicklungscode kann Endlosschleifen, Speicherverluste oder andere Probleme verursachen, die die CPU blockieren, den gesamten Speicher belasten oder den Server auf andere Weise so beeinflussen, dass sich dies auf Ihren Produktionscode auswirkt.
  2. Wenn Sie im Rahmen Ihrer Entwicklungsarbeit Änderungen an Komponenten der Serverumgebung vornehmen müssen, z. B. an der Version von Ruby oder MySQL oder was auch immer, sind Sie in der Klemme.
Jacob Terry
quelle
1
Ja, das ist ein guter Punkt. Je mehr ich darüber nachdenke, desto besser.
Luk3thomas
6
Es gibt ein drittes Problem: Sicherheit. Was passiert, wenn jemand den Produktionsserver portscannt und Ihre (Entwicklungs-) Anwendung entdeckt - und dadurch die Produktionsanwendung gefährdet? Auch wenn dies kein wahrscheinliches Szenario ist, sagt das jeder, nachdem ein Server oder ein System kompromittiert wurde.
Marco
Das berüchtigte Endlosschleifenproblem ...
Mansuro
3
@Marco Eigentlich ist das sehr wahrscheinlich, wenn der Server öffentlich zugänglich ist. Entwicklungsserver weisen in der Regel eine sehr schlechte Sicherheit auf (da Bequemlichkeiten wie Debugger und Stack-Traces in Bezug auf die Sicherheit eine Verpflichtung darstellen). Wenn ein Angreifer durch Ausnutzen des Entwicklerservers die Rechte erhöhen kann, kann er die Produktions-App vollständig besitzen.
Mark E. Haase
29

Wie bereits erwähnt, sind Ihre Benutzer durch die Codierung in der PROD-Umgebung Ihren Fehlern ausgesetzt. Auch wenn Sie eine andere Instanz gestartet haben, verfügen Sie weiterhin über gemeinsam genutzte Hardwareressourcen und können weiterhin auf Produktionsdateien und -datenbanken zugreifen. Und wie in einigen Kommentaren darauf hingewiesen wird, haben Sie jetzt einen öffentlich zugänglichen Computer, auf dem Ihre App agiert , wenn Ihre Dev-Instanz gehackt wird (zum Beispiel, weil Sie vergessen haben, sie zu löschen, und jemand einen massiven Sicherheits-Exploit in Rails entdeckt) als Tor in. Was ... unglücklich wäre.

Unterschiedliche Unternehmen haben unterschiedliche Reaktionen darauf, die sich jedoch im Allgemeinen wie folgt aufteilen lassen:

  • Ist ein Fehler aufgetreten?
  • Wie lange würde es dauern, eine Änderung rückgängig zu machen? (Ich arbeite hauptsächlich in C ++, daher kann das Zurücksetzen einer Binärdatei erheblich länger dauern als in Ruby, insbesondere wenn Sie die alte Binärdatei "verloren" haben und neu kompilieren müssen.)
  • Was die Auswirkung der Änderung ist (grobe Richtlinie: Das Versauen gespeicherter Daten ist so viel schlimmer als das Nicht-Speichern oder Anzeigen von Daten, was wiederum schlimmer ist, als die Seite überhaupt nicht anzuzeigen)
  • Wenn du es vermasselt hast und dann zur Tür hinausgegangen bist, würde jemand wissen, was du getan hast?
  • Gab es eine andere Einsatzoption, die das Versagen vor dem Aufprall verhindert / minimiert / erkannt hätte?

Dies gibt Ihnen die endgültige Berechnung:

  • Wie viel hätte dieses völlig vermeidbare Durcheinander das Geschäft gekostet?

Dies ist jetzt, wie viel weniger Ihre gesamte Managementstruktur für den Typ wert ist, der Budgetentscheidungen trifft. Daher schreien.

Wenn Sie auf der internen "Über uns" -Seite des Unternehmens arbeiten und Ihren eigenen Namen als "L" eingeben, ist das ein peinliches Spitznamenproblem. Wenn Sie an der geschäftskritischen Einkaufs-App arbeiten und sie versehentlich im Klartext debuggt, werden die Kreditkartendaten auf der Startseite ausgegeben. Zwischen diesen Extremen liegt alles, was die Produktivität beeinträchtigt, lähmt und all die anderen Dinge, die Kunden vertreiben können.

Der Grund, es nicht einmal für die Seite "Über uns" zuzulassen, ist, dass das Codieren direkt in der Produktion süchtig macht . Sie tun dies zunächst nur für Minderjährige, aber mit der Zeit ist es so viel schneller, wenn Sie das DEV-Env nicht auf den neuesten Stand bringen müssen.

Darüber hinaus kann die Größe des Unternehmens einen großen Einfluss haben. In einem Zwei-Mann-Team lehnt man sich über die Schulter, wenn etwas schief geht, und sagt: "Oh, Dummkopf, leg es zurück". In einem Unternehmen mit 300 Mitarbeitern muss man sich Sorgen machen, ob es sich um Inkompetenz oder Böswilligkeit handelte. Manager können für Dinge verantwortlich gemacht werden, über die sie keine Kontrolle hatten usw.

Am Ende des Tages, wenn Sie die Prozedur befolgen und es vermasseln, überprüfen sie, was mit der Prozedur falsch ist. Wenn Sie die Prozedur umgehen und es vermasseln, liegt es jetzt in Ihrer alleinigen Verantwortung, auch wenn die Schuld sich ein wenig ausbreitet. Ob du würfeln willst, liegt ganz bei dir.

entwurde
quelle
Dies ist eine gute Zusammenfassung von Fallen bei der in einer Produktionsentwicklungsumgebung , aber die Frage war in einem über die Entwicklung von separaten Umgebung auf die Produktion Hardware .
Carson63000
@ Carson63000 Einverstanden, und Jacobs Antwort ist definitiv die bessere auf dieser Seite. Ich habe meine leicht verändert.
Deworde
13

Ich habe versucht, lokal eine Entwicklungsumgebung einzurichten, konnte sie jedoch nie zum Laufen bringen. Nachdem ich es eine Weile versucht hatte, gab ich es auf und beschloss, mich auf dem Produktionsserver zu entwickeln.

Ich unterstütze die Anweisungen zur AVOID- Entwicklung auf einem Produktionsserver. Sie sind möglicherweise nur berechtigt, unter der Waffe etwas zu tun, wenn es sich um eine Tippfehlerbehebung in der Konfigurationsdatei handelt und Ihr Manager darauf besteht.

WHY NOT?- Weil es sehr riskant ist, später zur Gewohnheit zu werden, die Sie schlecht einholen würde. Denn schwerwiegende Produktionsfehler / -ausfälle können dazu führen , dass Sie von Ihrer Arbeit entlassen werden.

Lassen Sie mich wieder Iterierte es wieder, sogar obwohl , wenn Sie aufgefordert Tippfehlerkorrektur auf zu tun , productionServer, zuerst tun es auf Staging. Mit anderen Worten: Testen Sie Ihre Änderungen, testen Sie sie und testen Sie sie erneut, bevor Sie sie in Produktion geben.

Dies geschieht häufig an Orten, an denen die Kultur des "Mach es schnell und schmutzig " anscheinend eine Norm ist.

Bearbeiten: Die Entwicklung auf einem Produktionsserver als separate Umgebung ist ebenfalls NICHT akzeptabel . Alle Probleme, die bei Ihrer Arbeit auftreten, können den Produktionsserver herunterfahren und die Leistung der Produktionsanwendung beeinträchtigen . Als Beispiel erinnere ich mich an einen Fall, in dem es eine Sicherheitslücke gab, als mein früherer Kollege versuchte, den Produktionsserver WinServer 2003 für Entwicklungszwecke zu verwenden.

EL Yusubov
quelle
Dies ist eine gute Zusammenfassung von Fallen bei der in einer Produktionsentwicklungsumgebung , aber die Frage war in einem über die Entwicklung von separaten Umgebung auf die Produktion Hardware .
Carson63000
Vielen Dank, ich habe eine Bearbeitung hinzugefügt, die Bedenken behebt, es zu tun.
EL Yusubov
10

Dies ist wirklich ein Protokollproblem. Im Allgemeinen ist dies nicht etwas, was Sie tun möchten. Sie wollen die Produktionsmaschinen in Ruhe lassen. Sie können vertrauliche Daten enthalten, und Sie möchten die Leistung oder Stabilität von Produktionsstandorten nicht durch nicht produktionsfertigen Code beeinträchtigen.

Das heißt, es gibt Zeiten, in denen dies häufig gemacht wird. Wenn Sie sich in einer Position befinden, in der Brouchureware mit geringem Datenverkehr oder einfache CMS-Websites herausgepumpt werden, ist dies wahrscheinlich weniger problematisch. Wenn Sie jedoch mit vertraulichen Daten oder "geschäftskritischen" Prozessen arbeiten, sollten Sie nicht riskieren, Entwicklungscode auf demselben Computer zu haben.

Mistkerl
quelle
OK danke. Kann Entwicklungscode eine Maschine instabil machen? Ich arbeite an einer alten Rails-App. Es scheint mir (naive Person), dass Entwicklungscode für http://example.com:3000nicht beeinflussen würde http://example.com.
Luk3thomas
2
@ luk3thomas: na klar, sollte es nicht. Was ist, wenn es einen Fehler im Webserver oder Rails-Framework gibt, der den Server zum Absturz bringt? Was ist, wenn, wie Jacob Terry in seiner Antwort angedeutet hat, eine Endlosschleife oder ein Speicherverlust in Ihrem Entwicklungscode alle Ressourcen auf dem Produktionsserver aufzehrt und die Leistung der Live-Site beeinträchtigt?
Carson63000
1
Manchmal ist es eine Voraussetzung. Zum Beispiel Läden, die teure Software lizenzieren und nicht das Budget für eine zweite Kopie haben, nur für Entwicklerarbeiten.
Brian Knoblauch
8

Ein weiterer wichtiger Grund, nicht direkt in der Produktion zu entwickeln, ist, dass eine Entwicklungsinstanz normalerweise ausführliche Fehler und Stapelspuren erzeugt und anzeigt. Sie möchten dies niemals dem Benutzer anzeigen.

Ja, können Sie sie log , anstatt sie an den Client zu zeigen, aber das macht das Debuggen , dass viel weniger amüsant , als es ohnehin schon ist.

Hinzugefügt: Behebung Ihres Nebenproblems mit Problemen mit Ihrer Entwicklungsinstanz: Ich hatte großen Erfolg mit der Bereitstellung einer VirtualBox- basierten VM, die unsere Produktionsumgebung (natürlich ausschließlich Hardware) mit einem Ubuntu-Server dupliziert .

msanford
quelle
3
zur Kenntnis genommen, danke für den Rat w / VirtualBox
Luk3thomas
1
@ luk3thomas Es ist auch kostenlos! Es gibt Tonnen von Online - Tutorials für VirtualBox + Ubuntu (wahrscheinlich eines der am häufigsten verwendeten Virtualisierungs Kombinationen).
Msanford
8

Ich bin ziemlich erstaunt, dass noch niemand den wichtigsten Grund genannt hat, warum es absolut verboten ist, auf Produktionsservern zu entwickeln:

Verwirren Sie sich nicht mit Produktionsdaten, was ach so leicht passieren kann!

Ein kleiner Fehler an einer Stelle führt zu riesigen Problemen bei anderen Berechnungen, und am nächsten Tag sind alle Daten Müll und der Kunde ist sauer. Dies ist viel, viel schlimmer als ein Fehler in der Benutzeroberfläche oder ein kleiner Absturz hier und da.

Bei den meisten Anwendungen liegt der Wert in den Daten und nicht in den Routinen.

Falke
quelle
1
Sie lernen dies ziemlich schnell, nachdem Sie die Produktionsdaten vermasselt haben. Ich vermute, er hat keine DB.
Rocklan
8

Ich versuche immer, andere Entwickler zu fragen, welche Verfahren für das jeweilige Unternehmen gelten. Im Allgemeinen ja, sollten Sie immer:

  1. Lokal bauen.
  2. Schieben Sie es zu einer Art Box, die die Produktion so gut wie möglich nachahmt, um zu sehen, ob es dort gut läuft.
  3. Senden Sie es möglicherweise an eine QS- oder Zertifizierungsinstanz, um es an das Client- / QS-Team weiterzuleiten und die Änderungen zu überprüfen.
  4. Push to Production.

Sie können Capistrano- Rezepte zusammen mit GitHub verwenden , um all diese Dinge für Sie zu erledigen. Wenn Sie dies jedes Mal von Hand tun müssen, kann es schnell veralten.

lscott3
quelle
Schienen 2.3.11, werde ich wahrscheinlich am Ende so etwas tun
Luk3thomas
1

Ein weiteres Problem bei der Entwicklung auf Prod ist, dass diese Dinge in der Quellcodeverwaltung manchmal übersehen werden und eine zukünftige Version möglicherweise Ihre Schnellkorrektur rückgängig macht.

Wenn Sie in einem börsennotierten Unternehmen in den USA tätig sind, sollten Sie aus regulatorischen Gründen nicht einmal Zugriff auf Produkte haben. Im Allgemeinen sollte in keinem Unternehmen ein Entwickler Zugriff auf Produkte haben (aus den in allen Antworten angegebenen Gründen sowie aus möglichen rechtlichen Gründen), sodass Ihr Manager auch im Unrecht ist, Ihnen die Rechte für diesen Server zu gewähren.

HLGEM
quelle
0

Regeln, die "immer" oder "nie" verwenden, sind normalerweise schlecht definiert. Es wird Randfälle geben, in denen ein Verstoß gegen eine bewährte Methode gerechtfertigt ist. Viel bessere Ratschläge sind: "Berühren Sie die Produktionsserver nur, wenn Sie gute Gründe haben."

In meiner Karriere habe ich nur zwei Gründe gefunden, um den Code auf Produktionsservern zu ändern:

  1. Fehler oder Verhaltensweisen, die nur dort auftreten und in der Entwicklungsumgebung nicht reproduzierbar sind. Diese sind selten, können aber sehr ärgerlich und schwer zu finden sein.

  2. Behebung eines kritischen Fehlers, den Sie sich nicht leisten können, wenn der normale Bereitstellungsprozess länger als ein paar Minuten dauert. Nachdem dies mit dem Management geklärt wurde. Wenn Sie Glück haben, sollten Sie nur wenige davon für Ihre gesamte Karriere haben.

Beide werden am besten älteren Entwicklern überlassen, die die Systeme genau kennen.

Daniel Iankov
quelle
Wenn Sie Fehler haben, die nur in der Produktionsumgebung auftreten, ist Ihre Entwicklungsumgebung nicht nah genug an der Produktionsumgebung. Sie sollten MINDESTENS über eine Staging-Umgebung verfügen, die genau die gleiche Konfiguration wie die Produktionsumgebung aufweist, bis hin zu den genauen Betriebssystemeinstellungen, der Verarbeitungshardware und der installierten Software.
Nzall