Für alles über alles reichen 50 Tassen Kaffee.
Zusätzlich zu der oben beschriebenen Faustregel veröffentlichen wir eine kurze Anmerkung zu den Punkten, die genau beachtet werden müssen, damit im Kampf und in den Prozessen nichts kaputt geht. Die Notiz wurde gemacht, um die Veröffentlichung eines mobilen Dienstes zu verfolgen, der vollständig auf .Net Core migriert wurde (der Anfang wurde hier gelegt). Wir haben es geschafft, diesen Vorgang vom Kunden unbemerkt durchzuführen, fast ohne den Hauptentwicklungsprozess anzuhalten.
Unten ist ein vorgefertigter Aktionsplan, es wird eine sehr umfangreiche Testliste geben, dieses Bild wird hier für die Stimmung sein:
Also in Schritten:
1. Planen Sie einen langen Sprint mit großen Funktionen und / oder Regression
Bei grundlegenden Code-Umschreibungen benötigt der Service Zeit, um so lange wie möglich darauf zu bestehen, um Zeit zu haben, um alle Fehler in der Testumgebung zu beheben.
2. Schreiben Sie im genauen Sprint den Code auf .Net Core neu
Warum ist es wichtig, dieses Geschäft nicht im Voraus zu starten? Weil Sie mit dem neuen und dem alten .net zwei Codezweige ziehen müssen, weil jederzeit ein Dringlichkeitsvogel einfliegen kann oder Sie eine Demo neuer Funktionen durchführen müssen und dann Änderungen am alten stabilen Zweig vornehmen müssen. Um diesbezüglich nur minimale Bedenken zu haben, ist es besser, den Moment des Übergangszustands zu verkürzen.
Übrigens kamen wir bei der Arbeit mit dem Code schnell zu dem Schluss, dass es bequemer ist, zwei Kopien des Repositorys lokal aufzubewahren. Es ist einfacher und bequemer als zwei massive Zweige zu wechseln.
- Wenn möglich, schreiben Sie WCF-Schnittstellen in Webapi in den verwendeten Diensten neu
Die .Net Core-Implementierung des WCF-Clients ist noch lange nicht ideal. Trotz der Tatsache, dass die alten Wunden in irgendeiner Weise behoben sind, müssen Sie in den neuen Versionen immer noch die Problemumgehung verwenden ( 1 , 2 ).
Für die Geschichte: Unter .Net Core 2.0 ist die stabile Arbeitsversion von WCF 4.4.2 aus dem Myget-Repository. Sie hat zum Beispiel keine Probleme mit einer frühen Auszeit
Zu Beginn der Migration haben wir die Version von .Net Core 2.0 verwendet. Inzwischen hat Microsoft .Net Core 2.1 veröffentlicht. Wer die Erfolge der Redmond-Leute bei der Optimierung der Plattform bewundern möchte, sollte lesen, welche Fortschritte die Bing- Suchmaschine beim Upgrade auf die neue Version gemacht hat (Spoiler: latensi um 34% gefallen!)
Wir haben auch ein Upgrade auf .Net Core 2.1 und WCF 4.5.3 durchgeführt. Und wir haben nicht vergessen, in der Docker-Datei ein neues Basis-Microsoft / Dotnet-Image anzugeben: 2.1-Aspnetcore-Laufzeit. Was war die Überraschung, als sie anstelle von 1,4 GB eine Bildgröße von 0,5 GB sahen (wir sprechen von einem Windows-Bild, wenn auch plötzlich).
3. Machen Sie sich bereit für einen Test und eine Demo
Wir haben zwei Umgebungen zur Verfügung. Wir haben die Demo mit der alten Version als Referenz verlassen. In der Testumgebung wurde ein neuer Dienst bereitgestellt - ein Lauf für Entwickler und Tester.
Es gab einige Verwirrung aufgrund der Tatsache, dass Entwickler normalerweise mit dem Test arbeiten und Tester hauptsächlich mit einer Demo. Wenn der alte Dienst aktualisiert werden musste, war die Situation genau das Gegenteil von normal. Daher war eine Diskussion und ein Spickzettel nützlich, wo und wonach gesucht werden sollte.
Um den .Net Core-Dienst in IIS auszuführen, müssen Sie das mit der Laufzeit gelieferte Modul installieren.
AppPool wechselt zu CLR Runtime = No Managed Code.
Bei der Lösung in der Standard- web.config ist es wichtig, nicht zu vergessen, das gewünschte requestTimeout festzulegen und das WebDAV-Modul zu deaktivieren, wenn DELETE-Methoden vorhanden sind.
Darüber hinaus gibt es zwei Möglichkeiten, einen Dienst in IIS zu veröffentlichen:
- Sie führen die MSDeploy-Synchronisierung durch. Dies bedeutet, dass Sie zusätzlich den Schalter -enableRule benötigen: AppOffline
- Sie veröffentlichen Dateien - dies bedeutet, dass Sie die Datei app_offline.htm genau vor der Veröffentlichung im Dienstverzeichnis ablegen und nach der Veröffentlichung löschen müssen
Sowohl das als auch ein anderes ermöglichen es, einen Arbeitsprozess zu stoppen und ausführbare Dateien zu öffnen. Andernfalls tritt ein Fehler auf, dass die Dateien nicht zum Überschreiben verfügbar sind.
Wir haben die Protokollierung über Nlog zugunsten von Serilog abgelehnt und die automatische Komprimierung von Protokollen verloren - in Serilog gibt es einfach keine solche Funktion. In diesem Fall können Sie mit normalen Windows-Tools gespeichert und die NTFS-Komprimierung in den Verzeichniseigenschaften installiert werden.
4. Testen
Hier ist die am meisten geschrumpfte Checkliste für die fragilsten Orte:
- Überprüfen Sie die Rückgabe von Statuscodes. Ungültige Anforderung, Nicht autorisiert, Nicht geändert, Nicht gefunden - alles, was die API geben kann
- Überprüfen Sie die Anforderungsprotokollierung auf alle Statuscodes
- Erstellen Sie ein Diagramm der externen Abhängigkeiten. Alle notwendigen Informationen befinden sich in der Regel in Appsettings
- verbannen Methoden, die ihre Arbeit beeinflussen
- Überprüfen Sie die Protokollierung externer Anforderungen
- Überprüfen Sie die Funktion der Einstellungen für die App-Einstellungsparameter. Versuchen Sie, sie gegen heiß auszutauschen
- Überprüfen Sie das http-Caching auf positive und negative Statuscodes
- ETag-Header
- Header-Cache-Steuerung
- Überprüfen Sie lange Anfragen und Zeitüberschreitungen
- Überprüfen Sie Anfragen mit einer leeren Antwort
- Überprüfen Sie die DELETE-Methoden (WebDAV ist deaktiviert oder nicht).
- Überprüfen Sie die Arbeit mit Rohinhalten
- Laden Sie eine / mehrere Dateien hoch und laden Sie sie herunter
- Laden Sie Dateien mit einer Größe über dem Grenzwert hoch
- Header-Layout Inhaltsdisposition
- Überprüfen Sie alle anderen Header. Es ist ziemlich einfach, sie alle im Code zusammenzufügen
- Überprüfen Sie die bedingte Codeausführung beim Wechseln der Umgebung,
if (env.IsDevelopment()) - Überprüfen Sie die Trennung von Client und Server
- Vergleiche mit dem Standard swagger.json - hilft dabei, den Unterschied in den übertragenen Feldern zu erkennen
Unsere mobile Anwendung verwendet einen Codegenerator, um mit der API basierend auf der Beschreibung von swagger.json zu arbeiten. Daher war es wichtig, dass der Unterschied zur ursprünglichen Beschreibung minimal war. In der neuesten Version von Swashbuckle.AspNetCore haben sich die Benutzeroberfläche und die generierte Datei swagger.json stark verändert. Ich musste auf die schäbige Version von Swashbuckle.AspNetCore 1.2.0 zurückgreifen und ein paar Filter hinzufügen.
5. Machen Sie einen Kampf, während Sie Kaffee trinken
In unserem Fall besteht die Kampfumgebung aus zwei Knoten: aktiv und passiv.
Damit der Wechsel zum neuen Dienst unbemerkt bleibt, haben wir den Pool und die Site auf jedem Knoten dupliziert und ein Skript geschrieben, um die Bindung zwischen der alten und der neuen Site zu wechseln.
So konnten wir im Notfall schnell auf die alte Version umsteigen.
Nach dem Einsatz in der Schlacht waren wir innerhalb einer Woche von der Realisierbarkeit des Dienstes überzeugt und haben grünes Licht für die Veröffentlichung der mobilen Anwendung gegeben. Das Leben im Projekt kehrte sicher zu seinem vorherigen Kurs zurück.
Zwischensumme
Jetzt ist unser Service vollständig bereit, einen Docker-Container für die Lieferung an den Cluster zu erweitern. Wir sind bereit für die Bereitstellung in Kubernetes und Service Fabric.
Jetzt laufen die Vorbereitungen für die Präsentation der neuen Infrastruktur beim Kunden. Wir werden in der nächsten Serie über unsere Erfolge berichten, bleiben Sie am Puls der Zeit;)