Dev Server gegen lokale Entwicklung

In den letzten zwei Projekten, an denen ich gearbeitet habe, bevorzugen Teams eine lokale Entwicklungsumgebung gegenüber einem Entwicklungsserver.

Der eine Projektleiter gab an, dass lokal besser sei, da keine Internetverbindung erforderlich sei. Dies scheint jedoch bei der Entwicklung vorausgesetzt zu werden.

Welches ist normalerweise besser?

Der Vorteil des lokalen Betriebs besteht darin, dass Sie arbeiten können, ohne andere zu beeinflussen / zu behindern. Der Vorteil eines zentralen Entwicklungsservers besteht darin, dass Sie testen können, wie Ihre Änderungen die Änderungen beeinflussen und mit ihnen interagieren, während sie vorgenommen werden.
Idealerweise möchten Sie beides haben. Entwickeln und führen Sie Ihre Komponententests lokal aus, damit Sie Ihre Änderungen isolieren können, bis Sie mit ihnen vertraut sind, und integrieren Sie sie dann auf dem Teamserver, damit Sie die Integration von Änderungen überprüfen können, bevor die Testsysteme ausgeführt werden.

Ein weiterer Vorteil eines lokalen Servers auf Ihrem Laptop besteht darin, dass Sie remote arbeiten können, wo Sie keinen Zugriff auf das Unternehmensnetzwerk haben und daher nicht auf den Entwicklungsserver zugreifen können.

Eigentlich gibt es 3 Möglichkeiten:

Lokale Entwicklung

• Vorteile:
  • einfach mit den meisten Entwicklungswerkzeugen zu arbeiten
  • Keine Internetverbindung erforderlich
  • andere Entwickler nicht beeinflussen
• Nachteile:
  • hängt vom zugrunde liegenden Betriebssystem ab
  • Möglicherweise müssen alle Arten von Serverdiensten auf Ihrem lokalen Computer ausgeführt werden
  • Die Umgebung unterscheidet sich möglicherweise erheblich von der Produktion

Lokale virtuelle Maschine

• Vorteile:
  • Die Arbeit mit den meisten Entwicklungstools ist recht einfach, vorausgesetzt, Sie haben die Ordnerfreigabe ordnungsgemäß eingerichtet
  • Keine Internetverbindung erforderlich
  • andere Entwickler nicht beeinflussen
  • Umgebung kann praktisch identisch mit Produktion sein
  • Serverdienste wurden in der virtuellen Maschine gestartet / gestoppt
• Nachteile:
  • etwas mehr Ressourcen erforderlich (hauptsächlich RAM, CPU ist kein Problem bei der Unterstützung moderner Hardwarevirtualisierung).
  • Einige lokale Debugging-Tools, die direkt an den Server angehängt werden, funktionieren nicht

Gemeinsamer Entwicklungsserver

• Vorteile:
  • Umgebung kann praktisch identisch mit Produktion sein
  • Serverdienste auf dem Server
• Nachteile:
  • Fernzugriff
  • Änderungen, die andere Entwickler betreffen
  • viel schwierigeres Debuggen (entweder mithilfe von Remote-Tools oder mithilfe von Protokollen)

Optimale Lösung

Verwenden Sie eine der lokalen Entwicklungsoptionen und senden Sie sie an den gemeinsam genutzten Entwicklungsserver, sobald Sie einen eigenständigen Teil der Funktion abgeschlossen und überprüft haben, dass Ihr Code nicht vollständig fehlerhaft ist.

Ihre Entwicklungsumgebung hängt wirklich davon ab, wie Ihre IT-Abteilung / Ihr IT-Unternehmen organisiert und betrieben wird. Im Allgemeinen ist es jedoch umso besser, je geschlossen Ihre Entwicklungsumgebung mit der Ihrer Produktionsumgebung übereinstimmt.

Wenn Sie beispielsweise eigenständige Desktop-Anwendungen entwickeln, für die kein Internetzugang erforderlich ist, ist natürlich eine lokale Entwicklungsumgebung akzeptabel.

Wenn Sie jedoch eine Desktop-Anwendung entwickeln, die die Kommunikation mit einem Remote-Server / einer Remote-Datenbank usw. erfordert, und keine Netzwerkverbindung haben, um dies bei der Arbeit zu simulieren, können aufgrund von Netzwerklatenz und Sicherheitsproblemen zusätzliche Fehler in der Produktion auftreten.

Wenn Sie eine Internet- / Cloud-Anwendung entwickeln, benötigen Sie möglicherweise Zugriff zum Testen und Überprüfen, während Sie möglicherweise das Internet zum Entwickeln der Anwendung benötigen.

Übrigens benötigen Sie keine Internetverbindung, um einen Entwicklungsserver zu haben, sondern nur eine lokale Netzwerkverbindung.

Tue beides,

Lokale Entwicklung, bis alles, woran Sie arbeiten, erledigt und getestet ist.

Drücken Sie am Ende des Tages auf den freigegebenen Server und führen Sie Integrationstests durch, um sicherzustellen, dass Sie nichts kaputt gemacht haben.

Warum?

• Es ist schneller, lokal zu codieren. Weniger Schritte zwischen den Tests, weniger Integrationsprobleme.

• Die Fehlerisolierung ist einfacher, wenn etwas erst dann kaputt geht, wenn Sie es auf den gemeinsam genutzten Server übertragen. Sie wissen, dass es lokal gut funktioniert, daher muss es etwas damit zu tun haben, wie es in den gemeinsam genutzten Server integriert wird. Wenn Sie direkt auf dem gemeinsam genutzten Server arbeiten, ist es besonders schwierig, Fehler einzugrenzen.

Ich würde es so machen:

Nachdem jede Person am Ende des Tages Änderungen vorgenommen hat, werden alle Integrationstests ausgeführt. Wenn ein Fehler auftritt, wissen Sie genau, wer den Code für das Projekt gebrochen hat. Führen Sie die Änderungen zurück, beheben Sie das Problem lokal, und versuchen Sie erneut, es zu verschieben. Wiederholen Sie den Vorgang, bis alle Tests bestanden sind, und wechseln Sie dann zur nächsten Person.

Viel hängt davon ab, wie Sie Ihre Projekte liefern. Einige Argumente für eine zentrale Entwicklungsumgebung könnten sein:

Qualitätskontrolle: Wie weit möchten Sie weiter testen? Lokale Entwicklungsumgebungen unterliegen Einschränkungen hinsichtlich der Testfunktionen. Virtuelle Testumgebungen eignen sich besser für Lasttests und automatisierte Systemtests.

Die zentrale Infrastruktur kann dazu beitragen, den Entwicklungszyklus für Entwicklertests zu verkürzen. Somit wird eine kontinuierliche Lieferung implementiert.

Zusätzliche Vorteile des zentralen Entwicklungsservers können Quellcodeverwaltung, Aufgabenverwaltung, zentrale Builds usw. sein.