Gute, einfache Gründe für mehrere Umgebungen

Während meiner gesamten Karriere arbeitete ich in Unternehmen mit unterschiedlichen Umgebungen für unterschiedliche Zwecke. Wir hatten immer mehr oder weniger unsere Desktop-Umgebung, eine Testumgebung, eine QS-Umgebung, eine Staging-Umgebung und eine Produktionsumgebung. Dies galt sowohl für Server / Anwendungen als auch für alle von uns verwendeten Datenquellen.

Als ich in meiner jetzigen Firma anfing, stellte ich fest, dass 90% der Apps entweder auf einer Desktop-Umgebung mit Produktionsdatenquellen oder je nach Plattform direkt auf dem Produktionsserver entwickelt wurden. Dies war nicht besonders überraschend, da ich teilweise eingestellt wurde, um Änderungen vorzunehmen, um die Funktionsweise des Entwicklungsteams zu verbessern, was aus meinem Interviewprozess hervorgeht. Wir begannen langsam, die Philosophie zu ändern, und schon bald ließen sich die meisten Apps entweder in einer Desktop-, Test- oder Produktionsumgebung ausführen. Nicht lange danach kam auch die Inszenierung.

Jetzt sehen die meisten unserer Entwickler den Nutzen dieser Methodik und verteidigen sie wachsam. Wir haben jedoch eine Reihe von Legacy-Apps, die nie migriert wurden. Wir haben auch eine Reihe älterer Programmierer, die dies als Zeitverschwendung betrachten. Leider bekamen wir ein Lippenbekenntnis, aber nie das volle Buy-In des Managements. Wir haben vor etwa einem Jahr die Zusage erhalten, substanziell in dieses Projekt zu investieren, aber trotz der umfangreichen Planung, die wir in dieses Projekt gesteckt haben, ist nichts zustande gekommen. Jetzt stellen wir fest, dass wir immer mehr Umgebungen benötigen. Für die Einrichtung benötigen wir die Unterstützung der Server- / Netzwerkadministrationsteams und die Beteiligung der Geschäftsakteure, um den Release-Zyklus zu unterstützen. Wir sind jetzt an einem Ort, an dem ein Projekt funktionieren kann, was vernünftige Entwickler als "normal" betrachten würden.

Ich würde gerne ein vollständiges Argument vortragen, aber das Management hat wirklich keine Zeit und kein Interesse, mich anzuhören, bis es ein kritisches Problem gibt. Ich kann die Vorteile nicht so richtig ausdrücken, weil es mir immer nur selbstverständlich erschien. Ich habe mich gefragt, ob es gute, einfache und unwiderlegbare Gründe für die Trennung von Umgebungen gibt, die Manager ohne Entwicklungserfahrung dazu bringen würden, diese Idee zu unterstützen. . Gibt es gute Ressourcen / Literatur zum Thema?

Die Antwort: Geld

Es ist mir egal, was der eigentliche Grund ist. Geld MUSS die Wurzel all Ihrer Überlegungen sein, insbesondere im Umgang mit dem Management.

Wenn wir beide 2 Stunden in einem Raum saßen, könnten wir uns Dutzende Gründe ausdenken, warum es besser ist, mehrere Umgebungen zu haben.

Hier ist das Problem: Wenn die Gründe nicht auf Geld beruhen, ist keiner von ihnen von Bedeutung .

Programmierer sind nicht angeheuert, um klug zu sein. Sie werden nicht angeheuert, um kreativ zu sein. Sie werden angeheuert, um die Einnahmen zu steigern - entweder indem sie Geld verdienen oder Geld sparen. Wenn Sie keinen dieser Schritte ausführen, sollten Sie Ihren Lebenslauf zusammenstellen.

Wenn man es von diesem Standpunkt aus betrachtet, ist die Antwort einfach:

Nur eine einzige Umgebung erhöht unsere Ausfallzeiten und führt zu Umsatzverlusten. In mehreren Umgebungen können wir unsere Gewinne schützen, indem wir unseren Benutzern ein Front-End bieten, das genauso zuverlässig und zuverlässig ist wie unser Unternehmen.

Wiederholen Sie es jeden Tag.

Es gibt einige großartige Kommentare, die dieser Antwort einen echten Mehrwert verleihen. Deshalb werde ich sie erwähnen:

• Karl Bielefeldt hatte ein gutes Argument, als er erwähnte, dass die Kosten-Nutzen-Analyse ein wichtiger Faktor ist. Ein Ökonom könnte es als Opportunitätskosten für die Verfolgung mehrerer Umgebungen bezeichnen. Es mag zwar überraschend sein, aber es gibt Szenarien, in denen mehrere Umgebungen möglicherweise nicht die Antwort sind! Wenn es sich bei der Website Ihres Unternehmens nur um eine sehr geringfügige Erweiterung handelt, sind unerwartete Ausfallzeiten möglicherweise die kostengünstigere Art, Geschäfte zu tätigen. Das hört sich nicht nach Ihrer Position an, ist aber erwähnenswert.

• BlairHippo hatte den guten Grund, dass Sie sich frei fühlen sollten, es wie eine Katastrophe erscheinen zu lassen (und wenn Sie Ihre Daten verlieren, ist es das!). Haftung ist ein großartiges Instrument, um Manager zu überzeugen, aber immer noch aus dem gleichen Grund - Prozesse sind teuer. Sie zu vermeiden, spart Geld.

Als Ergänzung fand ich diesen Artikel recht gut. Es beantwortet Ihre Frage nicht direkt, sondern ermöglicht es Ihnen zu erkennen, wie Programmierer dem Management gegenüber gesehen werden, was wiederum zu dieser Antwort führt. Gut zu lesen.

Der Punkt des Versagens

Wenn Sie keine Entwicklungs- oder Staging-Umgebung haben, haben Sie einen Single Point of Failure für diese Legacy-Anwendungen. Das Management wird Sie hören, wenn Sie die Legacy-Anwendungen in diesen Begriffen beschreiben.

Sie müssen in der Lage sein, Ihre Nachricht in für sie sinnvolle Klangbytes zu unterteilen. Nehmen Sie das " Programmer Speak " aus der Diskussion und ersetzen Sie es durch " Manager Speak ". Stellen Sie sich auch vor, Sie hätten eine 30-Sekunden-Fahrt mit dem Aufzug, um Ihren Punkt zu erreichen.

Ich hatte eine Situation, in der mein Chef ein Infanteriemarine war. Ich sagte ihm immer wieder, ich brauche Softwaretools und Computerschulungen für meine Marines, um produktiver zu sein. Er hat es nicht verstanden. Eines Tages ging ich schließlich in sein Büro und sagte ihm, die Dinge seien erledigt.

Ich sagte etwas zu dem Effekt ... "Wenn ich einen Krieg führen würde, würde ich Stöcke, Steine ​​und Äste benutzen. Was ich brauche, sind Granaten, Panzerfäuste und Maschinengewehre." Er hat die Nachricht bekommen.

Ist es tatsächlich kritisch?

Ich kann den Wunsch verstehen, getrennte Umgebungen zu verwenden. Die nicht offensichtliche Frage ist:

Ist es tatsächlich wichtig, ein Altsystem zu migrieren ?

Ich denke, die meisten technisch orientierten Leute konzentrieren sich auf die akademische Frage, welcher Weg besser ist, was in der akademischen Welt in Ordnung ist. Im Geschäft siegt aber nicht immer das Beste. Ich sage das nicht als negativ oder als Flammenkrieg. Ich sage das Offensichtliche oder was für diejenigen von uns offensichtlich sein sollte, die seit einigen Jahren im Softwaregeschäft tätig sind .

Alle Geschäftsentscheidungen werden in der Regel auf der Grundlage des wahrgenommenen Kosten-Nutzen-Verhältnisses getroffen. Die Frage, die sich das Unternehmen wahrscheinlich stellt, lautet also:

Sind die Kosten für das zusätzliche System und die Entwicklungsinvestition in eine Altanwendung den Nutzen wert, verglichen mit der Investition in ein anderes Projekt / Produkt?

Ich habe und mache regelmäßig eine Kosten-Nutzen-Analyse, um nicht nur bei der Migration / Umschreibung von Software, sondern auch bei alltäglichen Entscheidungen Entscheidungen zu treffen, an denen in der Regel ein Vorsprung beteiligt ist daher Wert.

Umgebungen trennen

Die geschäftlichen Gründe für die Trennung von Umgebungen.

• Geringeres Risiko in Releases und Fehlerkorrekturen. Beweisen Sie es mit Zahlen. Wie oft ist das Produkt ausgefallen und hat den Kunden aufgrund eines schlechten Releases / Fehlers Umsatz gekostet?
• Geringeres Risiko in der Entwicklung. Das versehentliche Wegblasen der Entwickler-Datenbank unterscheidet sich vom versehentlichen Wegblasen der Produktions-Datenbank
• Die Fähigkeit, Rollen und Zugriff klar zu trennen, dh. bessere Sicherheit. Es ist eine gute Sache, die Anzahl der Finger im Produktionskuchen zu begrenzen
• Die Fähigkeit, Umgebungen zu trennen, sowie die Vorgehensweisen und Prozeduren, die mit dieser Art der Entwicklung einhergehen, ermöglichen die zukünftige Integration in Cloud-Systeme.
• Die Trennung der Umgebung sollte die Effizienz von Replikationsumgebungen erhöhen, was sowohl bei der geplanten als auch bei der dynamischen Skalierung nützlich sein kann.

Es hört sich so an, als ob Sie bereits alle "richtigen" Argumente an der richtigen Stelle haben. Stattdessen erleben Sie, wenn Sie so wollen, einen "roten Hering". Oder "die Karotte jagen"

Das Management hat wirklich keine Zeit und kein Interesse, mich anzuhören, bis ein kritisches Problem vorliegt

Das halte ich für das eigentliche Problem. Nach meiner Erfahrung, wenn ein Unternehmen so schlechte Entwicklungspraktiken hat, wie Sie es beschreiben. Es geht nicht nur darum, "wir hätten es nicht besser gewusst". Vielmehr handelt es sich um eine Zusammenstellung von technischen Schulden, die von einem oberen Management-Team verursacht wurden, das nicht über die Probleme Bescheid weiß (sich darum kümmert?).

In solchen Fällen wird ein gutes Aufmunterungsgespräch die Dinge nicht plötzlich in Ihre Richtung lenken. Möglicherweise ein schwerwiegendes Trauma (Produktfehler, der für den Kunden sichtbar und direkt mit schlechten Praktiken verbunden ist), aber ich bin mir sicher, dass Sie vernünftige Techniker sind, bevor Sie das Gesprächssache ausprobiert haben.

Mein Vorschlag ist, entweder zu saugen und Dinge für das zu halten, was sie sind, oder nach einer neuen Position zu suchen.

Wie viele Personengruppen planen, gleichzeitig an der App zu arbeiten? Normalerweise habe ich für jede Gruppe von Menschen eine Umgebung gesehen. Dies sind die Entwickler (sie erhalten eine DEV-Umgebung und eine DEV-Integrationsumgebung - einige würden sagen, dass dies nicht zu 100% notwendig ist, ich würde sagen, es variiert je nach Projekt), zwei Testumgebungen (eine Gruppe von Testern führt sehr detaillierte Tests durch, die andere für Hochrangige QS-Tester - in der Regel sind dies tatsächliche Geschäftsanwender, keine geschulten Tester. In der Regel gibt es auch eine isolierte Umgebung für Leistungstests (so können Sie große Datenmengen testen, große Benutzermengen simulieren usw.).

Warum all diese Umgebungen? So können verschiedene Gruppen verschiedene Funktionen testen, ohne sich gegenseitig auf die Zehen zu treten. Wenn Entwickler und Tester in derselben Umgebung arbeiten, ist dies ein Albtraum: Ein Tester kann einen Fehler in einer Funktion aufdecken, die von einem Entwickler jede Minute aktiv geändert wird. Wenn es zwei Testebenen gibt, können sie sich auf unterschiedliche Aktivitäten konzentrieren und müssen sich nicht gegenseitig die Daten verderben. In einer isolierten Leistungsumgebung können Sie Tests ausführen, bei denen die Maschine möglicherweise hängen bleibt. Wenn Sie jedoch isoliert ist, sind keine anderen Tester betroffen.

Wenn zu viele Personen versuchen, zu viele verschiedene Aufgaben in derselben Umgebung auszuführen, wird viel Zeit verschwendet, da eine Gruppe darauf wartet, dass der Test einer anderen Gruppe abgeschlossen wird, damit sie ihren Test ausführen können. Und das verschwendet Zeit, und verschwendete Zeit kann zu verschwendetem Geld führen, worauf Stargazer712 hinwies, dass es das stärkste Argument sein könnte.

Ein weiterer Grund (nicht so häufig) sind Daten: Wenn Ihre Anwendung vertrauliche persönliche Daten oder Kreditkartendaten enthält, können Sie diese normalerweise nicht in Testumgebungen einbinden, und es gibt normalerweise Maskierungsanforderungen für alles außer den QA- und Produktionsumgebungen.

Sie scheinen große Anstrengungen unternommen zu haben, um einen kulturellen Wandel an Ihrem Arbeitsplatz herbeizuführen. Dies ist eine großartige Leistung, da Veränderungen im besten Fall schwierig sind. Bei kulturellen Veränderungen geht es jedoch nicht nur darum, die Meinung der Menschen zu ändern, sondern auch darum, Gewohnheiten zu ändern, Vorurteile abzubauen und letztendlich potenziell verschlossene Köpfe für größere Möglichkeiten zu öffnen. Die Frage, die Sie sich an dieser Stelle stellen sollten, lautet "Was habe ich vermisst?". Die einfache Antwort lautet, dass Sie sich möglicherweise nicht vollständig mit dem Management befasst haben.

Es ist einfach, sich beim Management einzukaufen, aber noch schwieriger ist es, Akzeptanz zu erlangen. Unabhängig von den Argumenten zu Geld usw. müssen Sie in der Lage sein, die Prioritätsauffassung des Managements zu beeinflussen. Ihr Vorgesetzter hat ein Budget und möchte zeigen, dass das Budget sinnvoll und im Einklang mit den Unternehmenswerten und -prioritäten eingesetzt wurde. Einige dieser Prioritäten werden fiskalischer Natur sein, andere dienen anderen Bedürfnissen. In einigen Fällen kann dies bedeuten, die Handflächen anderer Manager einzufetten, um die Beförderung zu erreichen, die Ihr Chef immer gewollt hat. In den meisten Fällen geht es jedoch wahrscheinlich darum, Wege zu finden, um mehr Geschäfte zu machen oder die Beziehungen zu Partnern und Kunden zu verbessern. Wenn Sie sich in diesen Begriffen nicht durchsetzen können, können Sie nur so weit gehen, bis Sie in eine Sackgasse geraten.

Mein Vorschlag ist, zu versuchen, die Produktivität und die Auswirkungen auf das Budget zu untersuchen, wie andere vorgeschlagen haben, aber auch die Prioritäten Ihres Unternehmens und die möglichen direkten Auswirkungen Ihrer Produktivität auf die Beziehungen des Unternehmens zu anderen Unternehmen herauszustellen.

Hier ist eine: Testbarkeit.

Mit einer Testumgebung haben Sie die Freiheit, Tests in einer Datenbank durchzuführen, die in einer Produktionsumgebung nicht empfohlen werden.

Sie möchten ändern, wie Ihre Organisation ihre Software entwickelt? Machen Sie sich keine Gedanken über "Gründe" dafür, "Dinge anders zu machen". Menschen ändern ihr Verhalten nicht aufgrund rationaler Argumente. Sie ändern sich aufgrund psychologischer Einflüsse auf ihre Gewohnheiten.

Also, wohin gehe ich damit?

Während Sie gelegentlich das Verhalten einer Organisation durch Argumentation erfolgreich ändern können, gibt es andere Taktiken, die besser funktionieren. Diese schließen ein:

• Basisunterstützung: Finden Sie EINEN anderen "Legacy" -Entwickler, der bereit ist, Ihnen eine Chance zu geben. Arbeiten Sie mit ihm zusammen und ändern Sie die Funktionsweise. Kündigen Sie die Änderung nicht an. Nehmen Sie einfach die Änderung vor. Wenn dich jemals jemand danach fragt, sag einfach "Oh ja, so machen wir das jetzt."

• Verantwortung übernehmen. Helfen Sie freiwillig mit Einsätzen für die alten Leute. Benimm dich so, wie du es liebst. Sie können glücklich sein, diese Verantwortung abzugeben. Führen Sie es dann aus, wie Sie möchten.

• Beschuldige die richtigen Leute für ihre Fehler. Wenn das nächste Mal ein älterer App-Fehler aufgrund Ihres Steinzeit-Bereitstellungsmechanismus in die Produktion eingeführt wird, weisen Sie darauf hin. Mach es auf subtile Weise ... Nicht in einer E-Mail. Wenn Sie das nächste Mal in einer Besprechung mit einem Manager sind, erwähnen Sie nur beiläufig das Beispiel eines Grundes für die problematische Bereitstellung. "Ja, erinnerst du dich daran, wie wir letzten Freitag wegen des Foo-Fehlers in die Produktion gegangen sind? Ja, das war eine Menge vergeblicher Mühe!"

• Machen Sie es sich einfach, es besser zu machen. Schauen Sie sich zum Beispiel das iPhone an. Darauf befindet sich EINE Taste. (Na ja, zwei). Es ist sehr einfach einzuschalten. Machen Sie Deployment-to-Multiple-Environment-Verrückte einfach blöd. Machen Sie es sich so einfach, dass alle Manager es können!

Es ist ein größeres Problem, wenn Sie mit vernetzten oder älteren Systemen arbeiten. Systeme, auf deren Funktion und Genauigkeit das Geschäft angewiesen ist. Es ist wichtig, weil es eine Trennung zwischen den Phasen geben muss, und es ist der Grund, warum Sie sich nicht für PROD entscheiden, weil es das Potenzial hat, in der verlorenen Zeit Schaden in Millionenhöhe zu verursachen .

Wir machen immer DEV -> QA -> PROD (gelegentlich werden diese Schritte in kleinere Teile zerlegt) mit identischer Hardware dahinter. Aktuelle Produktionsdaten werden immer von PROD zu QA zu DEV übertragen.

DEV: soll die Entwicklungs-Sandbox sein, in der Dinge ausprobiert, iteriert und auf Daten in dieser Umgebung geschlagen werden, die niemals als vertrauenswürdig eingestuft werden dürfen. DEV wird regelmäßig von Entwicklern verworfen, die lediglich nach Wegen suchen, um ein Problem zu lösen.

Frage: Sobald Ihre Entwickler mit dem Unit-Test zufrieden sind, ist es an der Zeit, dass die Testgruppe es sieht. Sie führen Testfälle aus, testen die Leistung und finden Fehler. Diese Fehler / Verbesserungen werden an DEV zurückgemeldet und der Zyklus wird fortgesetzt, bis alle zufrieden sind.

PROD: Wenn Sie diese Phase erreicht haben, sollten Sie sicher sein, dass der Code mit den aktuellen Daten zusammenarbeitet und Ihre QA-Gruppe / Geschäftsbenutzer mit der Implementierung zufrieden sind. Wenn Sie alles richtig gemacht haben, sollten Sie einfach in der Lage sein, den Code zu aktualisieren und damit fertig zu sein.

Auf die gleiche Weise, wie Sie niemals ein nicht getestetes Produkt für Kunden freigeben würden, sollten Sie niemals nicht getesteten Code für eine Produktionsumgebung freigeben.

Wenn das Unternehmen nicht bereit ist, die Zeit für eine ordnungsgemäße Durchführung zu investieren, zahlt es die Kosten für die Notfallwartung und die 10-fache Fehlerquote zurück.

Als kleines Beispiel: Wir hatten eine Firma, die beschlossen hat, einen Bericht in der Produktion selbst zu ändern. Niemand wusste, dass es sich geändert hatte, bis wir uns ein oder zwei Jahre später mit einer Reihe von Problemen befassten.

Als wir auf die Unregelmäßigkeit im Bericht hinwiesen, wurde das Gesicht des CFO weiß, und es stellte sich heraus, dass er ~ 250.000 USD pro Quartal verlor, weil jemand eine schnelle Änderung vornahm.

Passiert öfter als Sie denken, wenn Sie es sich nicht leisten können, es richtig zu machen, dann tun Sie es nicht.

Das Management hat einen großen Anteil am Erfolg der Softwareunternehmen und Softwareprodukte, die für die Generierung dieser Umgebungen erforderlich sind. Nehmen wir ein Beispiel für Ihr Projekt. Wenn Ihre Software in großem Maßstab entwickelt wurde und Sie Ihre Projektanforderungen, Prozesssteuerung, Test Builds usw. nicht verwalten, besteht die Gefahr, dass dies fehlschlägt. damit es Projektmanagement gibt.

Ich bin mit @ Stargazer712 einigermaßen einverstanden, dass Ihre Aussage auf das Geld verweist, aber überprüfen Sie die folgende Aussage, die ich aus Marc Hamiltons Buch über Softwareentwicklung erhalten habe: Building Reliable Systems (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Nach all diesen Faktoren suchen; Meine Meinung zu Ihrer Frage ist, dass Single Environment Ihnen keine Einsparungen bringt, sondern einen langfristigen Prozess zur Fertigstellung des Projekts / der Software erfordert. Verteilte Umgebungen sparen Zeit und Geld, da ich gelernt und gesehen habe, was mit den Start-up-Software-Unternehmen passiert ist, von denen ich meinen Carrier gestartet habe.

Es gibt viele Artikel zeigen , dass das, was Sache Erfolg, diesmal Überprüfen Organisation für erfolgreiche Entwicklungssoftware

Jede Person in einer Organisation verfügt über bestimmte Fähigkeiten. Diese Fähigkeiten werden in der Regel an formellen oder informellen Leistungskennzahlen gemessen, die zu Belohnungen (Vergütungen) als Anreiz für zukünftige Leistungen führen. Die Menschen in einer Organisation etablieren ihre Kultur - jene Verhaltensmuster und Werte, die allgemein als angenommen anerkannt werden.

Eine große Anzahl von Softwareentwicklern wird Schwierigkeiten haben und letztendlich ihre Ziele verfehlen, wenn sie ihre ganze Zeit damit verbringen müssen, gegen eine unangemessene Organisationsstruktur zu kämpfen.

So manches Software-Startup beginnt mit nur ein paar Entwicklern, die in einer Garage arbeiten. Zu diesem Zeitpunkt in der Unternehmensgeschichte ist nicht viel Organisationsstruktur erforderlich, aber die Organisationsstruktur ist noch vorhanden. Zum Beispiel hatte das Unternehmen 1977, als Bill Gates und Paul Allen ihre Partnerschaft gründeten und offiziell Microsoft nannten, eine minimale Organisationsstruktur. In Microsofts erstem Büro in Albuquerque, New Mexico, arbeiteten weniger als ein Dutzend Mitarbeiter, und jeder wusste, wer dafür zuständig war. Es waren keine komplizierten Organigramme erforderlich, um die Berichtsstruktur aller zu ermitteln. Gleichzeitig kannten alle Mitarbeiter ihre Rolle im Unternehmen und wussten, was sie erreichen wollten. Dies lag daran, dass jede erforderliche Organisationsstruktur zwischen den einzelnen Mitarbeitern informell kommuniziert werden konnte.

Vergessen Sie Zeit, Geld, Testbarkeit, Qualität ... wie wäre es mit Reputation .

gute, einfache, unwiderlegbare Gründe für die Trennung von Umgebungen, die Manager mit mangelnder Entwicklungserfahrung dazu veranlassen würden, diese Idee zu unterstützen.

Uber hat kürzlich Code an github gesendet, der Passwörter für seine Live-Umgebung enthielt , sodass "Hacker" alle Kundendaten herunterladen können. Uber sagt, es sei ein Verstoß gewesen, alle anderen sagen: "Verschiebe die Schlüssel zu deinen Sperren nicht in die Öffentlichkeit. Wenn ihre Entwickler vollständig an einer Entwicklungsumgebung gearbeitet hätten, hätten sie die Schlüssel möglicherweise auf github für ihre Entwicklungsumgebung freigegeben, aber das ist völlig harmlos Dass die produktiven veröffentlicht wurden, zeigt, wie schlecht diese Vorstellung ist, Entwickler in der Produktionsumgebung auszuführen.

Erinnern Sie Ihren Vorgesetzten einfach daran, dass Fehler passieren. Sie können also verhindern, dass er vor den CEO gebracht wird, der vor Journalisten grillen wird und von der Fachöffentlichkeit ausgelacht wird, indem Sie einfache, offensichtliche Schritte einleiten, um zu verhindern, dass diese Fehler katastrophal sind Einsen.

Klingt so, als ob Sie in vielen verschiedenen Umgebungen arbeiten und die Einrichtung einer "Umgebung" zu viel Zeit kostet.

Sie sollten die geringste Anzahl unterschiedlicher "Umgebungen" haben , mit denen Sie durchkommen können, aber in der Lage sein, viele Kopien aus beliebig vielen Gründen zu klonen ("Umgebung" bedeutet Systemkonfiguration)!

Optimalerweise sollten die einzigen Unterschiede sein:

1. Größe (minimal, empfohlen, am meisten unterstützt / getestet);
2. Inszenierung und Produktion haben keine Entwicklungswerkzeuge
3. Die Produktion ist gegen versehentliches Überschreiben von Daten geschützt
4. Sie können sehr einfach Demo-, Test- oder [anoymisierte] Clientdaten auf Entwicklungs- oder Staging-Server laden

DANN ist die Frage, wie viel und welche Art von Tests durchgeführt werden sollten, eine Risiko-Kosten-Bewertung, die auf Unternehmensebene festgelegt wird, da das gesamte Unternehmen darunter leidet, wenn erhebliche Fehler bei einer Reihe von Kunden auftreten .

Später bearbeiten: Dies veranlasste mich, meine Namenskonventionen mit meinen Web-Produkten zu rationalisieren (danke für die Frage). Ich habe mich für vier "Umgebungen" entschieden, bei denen das Testen zwischen qa (minimale Einzelschicht für das Testen der Funktionalität) und Staging (dieselbe Architektur wie die Produktion für das Testen von Last / Leistung / Volumen) aufgeteilt ist.

Der einzige wirkliche Unterschied bei der Bereitstellung besteht darin, dass die Produktion / Bereitstellung eine Datenbank auf einem separaten System installiert, auf dem ich steuere, in welchen Gruppen sich die verschiedenen Server befinden. Qa / dev hat sowohl die Webserver- als auch die Datenbankrolle. Der Lastausgleich erfolgt über Cloudflare.

Ich habe auch eine ENV_NO-Variable, die an die Systeme übergeben wird, damit ich wählen kann, wie viele "QA" - oder "Staging" -Beispiele ich möchte.

Zum Einrichten einer zweiten qa-Umgebung, einschließlich meines letzten Live-Backups, lauten die Befehle:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Zuletzt habe ich einen zusätzlichen (optionalen) Server namens "readonly" als letztes Sicherheitsnetz, bevor ich auf den Boden stoße. Es wird wie ein QA-System bereitgestellt, jedoch mit deaktivierter Sicherung und Aktualisierung in den letzten Nächten (die Software wird auch auf die letzte Nacht aktualisiert).

Es wird der Ansatz "Alle Eier in einem anderen Korb" verwendet: Es wird ein anderer Standort / DNS-Registrar, DNS-Host und Systemhostdienstanbieter bereitgestellt. Dies ist das ultimative / letzte Sicherheitsnetz. Wenn also alles in Flammen aufgegangen ist, können Sie zumindest bis letzte Nacht auf die Daten zugreifen. Die Bereitstellungsskripte isolieren den Unterschied zwischen den verschiedenen Anbietern, sodass 99% gleich sind, nur das Readonly-Flag. Cloudflare Load Balancer leitet den Datenverkehr an die schreibgeschützte Site um, wenn alle Live-Server ausgefallen sind.

Wenn es darum geht, Änderungen vorzunehmen, haben Sie das Glück, jemanden zu haben, der nur auf Ihre professionelle Meinung hört und vorgeschlagene Änderungen umsetzt.

Nach meiner Erfahrung musste ich jedes Mal, wenn ich eine größere Änderung vornehmen musste, dies in Bezug auf die Einsparungen, die das Unternehmen erzielen wird, begründen. Zum Beispiel war die Einführung von ReSharper in die Entwicklungspipeline ziemlich einfach, da ich in der Lage war, Folgendes zu sagen:

ReSharper kostet ca. £ 50 pro Entwickler. Die durchschnittlichen Entwicklerkosten pro Jahr betragen 40.000 GBP. ReSharper sollte die Produktivität der Entwickler um mindestens 20% steigern, wenn das volle Potenzial ausgeschöpft wird. Angenommen, der Entwickler verbringt 75% seiner Zeit damit, Code in IDE zu schreiben. 75% von 40.000 € sind 30.000 €. 30.000 GBP sind jetzt die Kosten für die Produktivität des Entwicklers. Ein zusätzlicher Prozentsatz der Produktivität (1%) pro Jahr kostet 300 GBP. Um zusätzliche 20% Produktivität zu erzielen, müsste das Unternehmen 6.000 GBP ausgeben.

Wenn Sie dies ins rechte Licht rücken, können Sie sagen, dass Sie jemand anderen einstellen und zusätzliche 20% Produktivität für £ 6k erzielen können, oder Sie können das gleiche Ergebnis erzielen, indem Sie £ 50 für eine ReSharper-Lizenz ausgeben. Sobald die Zahlen vorliegen, ist die Entscheidung leicht zu treffen.

Wenn Sie nun Fragen zu mehreren Umgebungen haben, müssen Sie nur noch berechnen, wie viel es das Unternehmen jedes Jahr kostet, diese Umgebungen zu haben.

Sie können Ihre Kollegen bitten, die wöchentlichen Stunden zu protokollieren, die für die Konfiguration von Anwendungen für die Entwicklung, Bereitstellung usw. aufgewendet werden. Zehn Stunden der Zeit eines erfahrenen Entwicklers können beispielsweise 500 GBP kosten. Das sind 10 Stunden, die für die Entwicklung oder etwas viel Wichtigeres aufgewendet werden können. Sie erfassen die Zahlen für einen bestimmten Zeitraum und geben dem Unternehmen jährliche Kosten.

Ich persönlich hasse diese Art von Politik, aber sie ist normal und wir müssen damit leben.