Best Practices für die Bereitstellung / Wartung von ASP.NET

Ich bin seit ungefähr 5 Jahren in der Webentwicklungsbranche tätig und arbeite immer in einer Open Source-Umgebung. Meistens Apache, MySQL und PHP mit etwas Rubin, wobei Git zur Versionskontrolle verwendet wird. Aber vor kurzem nahm einen Job auf, bei dem die Entwicklung vollständig C # ASP.NET MVC ist.

Während ich in der Lage war, die Sprache usw. ziemlich leicht zu erlernen, haben die anderen Mitglieder meines Teams (mit viel mehr Erfahrung in der MS-Entwicklung als ich) alle eine andere Denkweise, wenn es um die Veröffentlichung und Bereitstellung der endgültigen Site geht, und insbesondere zukünftige Änderungen.

Die Mentalität mit den anderen Entwicklern ist, dass eine veröffentlichte Website endgültig ist. Es können keine Änderungen mehr an der Site vorgenommen werden. Wenn ich nach den Gründen gefragt habe, war die Antwort, dass sie zu gefährlich, zeitaufwändig oder schwierig ist.

Nach meiner bisherigen Erfahrung besteht das Aktualisieren einer Site lediglich darin, die geänderten Dateien hochzuladen, was normalerweise recht schnell geschieht, wenn es sich um eine kleine Änderung handelt, oder die Site während des Updates in den Wartungsmodus zu versetzen.

Wir haben kürzlich eine MVC-Site veröffentlicht, und das Unternehmen hat uns kontaktiert, um einen Teil des Textes zu aktualisieren und einen Link zu einem neuen PDF-Dokument hinzuzufügen. Der Rest meines Teams sagte schnell, dass dies nicht getan werden sollte, da die Site jetzt live ist und nicht geändert werden sollte. Gibt es etwas, das ich verpasst habe, weil ich nicht als Microsoft-Entwickler "erzogen" wurde?

Was ist das Argument gegen Änderungen an einer Live-Webanwendung in der Produktion und ist diese Denkweise einzigartig für .NET-Entwickler?

Ich würde diese Denkweise wirklich gerne verstehen und ob sie in einer Microsoft-Entwicklungsumgebung gerechtfertigt ist oder ob dies nur eine ältere Denkweise ist.

HINWEIS: Wir verwenden TFS zur Versionskontrolle und verwenden Veröffentlichungsprofile, um zu bestimmen, wo die Site bereitgestellt wird (UAT oder Produktion).

ASP.NET MVC-Anwendungen werden kompiliert. Dies bedeutet, dass Sie die geänderten Dateien nicht einfach hochladen können, wie dies beispielsweise bei einer PHP-Website der Fall ist. Dies bedeutet auch, dass aktuelle Benutzer beim Aktualisieren der Website verworfen werden (z. B. verlieren sie ihre Sitzungen).

Es gibt auch viel mehr zu tun, als nur die Dateien zu aktualisieren: Sie müssen damit umgehen:

• Berechtigungen

  Für die neue Version sind möglicherweise andere Berechtigungen auf dem Server erforderlich.

• Aufbau

  In der neuen Version muss möglicherweise der MSDTC-Dienst (Distributed Transaction Coordinator) installiert sein oder Sie möchten möglicherweise einen anderen SMTP-Server verwenden oder Zugriff auf Active Directory usw. haben. Dazu müssen Sie sowohl die Konfiguration der Anwendung als auch des Servers selbst ändern .

• Abhängigkeiten

  Eines der Probleme, auf die Anfänger häufig stoßen, ist beispielsweise, dass sie alte DLLs beibehalten /binund neue mit unterschiedlichen Namen hinzufügen: Die Anwendung verwendet möglicherweise weiterhin die alten, was zu einer verrückten Situation führt, in der Sie den Code des ändern Anwendung, aber das Anwendungsverhalten bleibt gleich.

• Daten

  Was passiert, wenn sich das Datenbankschema ändert und die Anwendung einen normalen SQL Server anstelle von NoSQL verwendet? Wie führe ich die Änderung im Schema durch? Wie kann ich die Daten während der Änderung korrekt halten?

Der Übergang zwischen einer alten und einer neuen Version der Anwendung ist eine schwierige Aufgabe. Vor einigen Jahren war dies eines der Probleme, bei denen eine neue Version der Anwendung bereit war, die Bereitstellung für Systemadministratoren jedoch Tage oder Wochen dauerte. DevOps behebt dieses Problem, erfordert jedoch, dass die Entwickler (durch Code oder Konfiguration) das System beschreiben, auf dem die Anwendung gehostet wird.

Je größer die Anwendung ist, desto komplizierter ist diese Aufgabe.

• Für eine winzige Web-App reicht es aus, Quelldateien auf den Server zu kopieren.

• Für etwas Größeres müssen Sie einen automatisierten Prozess haben, der sich mit dem Aktualisierungsprozess und dem Rollback befasst, falls etwas schief geht.

• Bei noch größeren Systemen werden bei jeder neuen Version neue VMs erstellt und bereitgestellt, und alte werden recycelt, um einen nahtlosen Übergang der Benutzer von der alten zur neuen Version zu gewährleisten.

Kompilierte Anwendungen erzwingen / ermutigen einfach, den Prozess früher zu automatisieren.

Das Unternehmen hat uns kontaktiert, um einen Teil des Textes zu aktualisieren und einen Link zu einem neuen PDF-Dokument hinzuzufügen. Der Rest meines Teams sagte schnell, dass dies nicht getan werden sollte, da die Site jetzt live ist

IMO, es gibt keine wirklichen technischen Gründe für diese Ablehnung; Sie möchten dies nur vermeiden, da die Aufgabe fehleranfällig ist , wenn sie nicht gut automatisiert ist .

Was normalerweise passiert, ist Folgendes:

1. Die Anwendung wird zum ersten Mal bereitgestellt.

2. Das Team verbringt einige Stunden damit, die Konfiguration zu optimieren, damit sie funktioniert. Da das Team vor drei Wochen voraussichtlich liefern wird, eilen alle und niemand macht sich Notizen über die Änderungen.

3. Die Anwendung ist jetzt betriebsbereit.

4. Für einige Wochen, Monate oder Jahre ändern einige zufällige Personen zufällige Dinge auf dem Server: Zum Beispiel haben sie eine Datenbank an einen anderen Speicherort verschoben, oder das SMTP-Kennwort wurde geändert, was zu den Änderungen in Web.config führte.

Wenn Sie die neue Version jetzt aktualisieren, kehren Sie zum ersten Schritt zurück. Es kann Tage dauern, bis die richtige Konfiguration wiederhergestellt ist. Da die Website live ist, sollte dies unbedingt vermieden werden.

Haben Sie Projektmanager, einen Entwicklungsmanager oder eine andere Person als die anderen Entwickler?

Es macht NULL Sinn, dass Sie nach der Inbetriebnahme keine Bereitstellung mehr durchführen können.

Natürlich müssen diese Änderungen unter anderem geplant, kalkuliert und mit Ressourcen ausgestattet werden, aber nur "Nein" zu sagen, ist Unsinn.

Der Hauptgrund für das angezeigte Verhalten ist, dass diese Art von Änderungen fehleranfällig sind. Das manuelle Aktualisieren der Anwendung führt dazu, dass Dinge vergessen werden und nicht mehr synchron sind. Sie sollten weiterhin in der Lage sein, neue Releases zu erstellen (und es sollte einfach sein) , nur keine Teil-Patches.

Teilaktualisierungen wie das Ändern von CSS oder Text auf einer Live-Site können dazu führen, dass das Überspringen von Tests, Test- oder Bühnenumgebungen nicht mehr synchron ist oder sogar kein Code für die Quellcodeverwaltung festgeschrieben wird. Wenn dies eine Codeänderung ist, können Sie sogar die Live-Site ohne Wiederherstellungsplan beschädigen.

In .NET können andere Probleme auftreten, z. B. lange Ladezeiten und der Verlust von Benutzersitzungen, da Code kompiliert wird. Diese Probleme könnten dadurch verringert werden, dass ich in eine warme Umgebung wechsle und den Sitzungsstatus außerhalb des Prozesses verwende. Es sei denn, Sie möchten bei jeder Bereitstellung über diese Art von Problemen und andere anwendungsspezifische Probleme nachdenken. Dann ist das Patchen von Live-Websites eine schlechte Idee.

Wenn Ihre Anwendung größer wird und die Leute kommen und gehen, kann dies von einer Unannehmlichkeit zu einem ernsten Problem werden. Um die Sicherheit zu erhöhen, befolgen wir folgende Regeln: Um eine Live-Website zu aktualisieren, muss es sich um eine vollständige Bereitstellung handeln, die niemals nur gepatcht wird.

Wenn Sie Ihre Bereitstellungen noch nicht automatisieren (wodurch es einfach und schnell ist, die Regel zu befolgen). Neue Bereitstellungen werden normalerweise neben der vorhandenen Version durchgeführt, und Ihre Website ist nur ein Zeiger auf die gewünschte Version (Hinweis: Das Datenbankschema macht dies etwas komplexer).

1.0.0  // Old version you can roll back to   
2.0.0 <-- IIS points here

In Wirklichkeit denke ich, dass alle Bereitstellungen wirklich automatisiert werden sollten, und dies schließt aus ähnlichen Gründen auch Nicht-.NET-Bereitstellungen ein. Sobald Sie mit der Automatisierung von Bereitstellungen beginnen, können Sie sicherstellen, dass diese konstant schnell und zuverlässig sind.

Ich veröffentliche regelmäßig einige ASP.NET MVC-Websites, die auf Amazon AWS, Windows Azure und privaten Webservern bereitgestellt werden, erneut und stelle keine Gründe fest, warum Ihr Team so viel daraus macht.

Sie sollten Ihre Websites jedoch so gestalten, dass Aufgaben wie das Aktualisieren von Texten und Links über die Datenbank über die Website-Administrationsoberfläche ausgeführt werden.

Mein Punkt ist, dass Änderungen an einer Live-Website zwar in Ordnung sind (dies wird als Entwicklung bezeichnet), die erneute Bereitstellung der Anwendung zum Ändern einer Textzeichenfolge jedoch wahrscheinlich auf ein schlechtes Design hinweist. Ich schlage nicht vor, dass die Neuveröffentlichung ohne Sorgfalt erfolgen könnte.