Entwicklung auf einem Produktionsserver

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?

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.

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.

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.

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.

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 .

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.

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.

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.

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.