Fabric-Projekte in separaten Git-Repos warten

Bei unseren Projekten folgen wir einem ähnlichen Muster, aber nicht so feinkörnig. Jede SF-Anwendung ist in einem eigenen Repo enthalten, aber wir haben mehrere spezifische Microservices in einer Anwendung. Wir trennen unsere Anwendungen in bestimmte Funktionen in Bezug auf die Endanwendung (Data Tier, Middle Tier, Präsentation, Analytik usw.). Wenn wir ein Upgrade durchführen, aktualisieren wir bestimmte Anwendungen gleichzeitig, nicht unbedingt bestimmte Dienste. Die Aktualisierung bestimmter Dienste ist ein riesiger Pita-Betrieb. Wir haben immer noch ein Shared-Interface-Projekt und wir verwenden SF-Remoting für die Kommunikation zwischen den verschiedenen Anwendungen, und wir können das, weil wir Container und Schnittstellen in einem eigenen Repo verwalten, die wir dann über einen privaten Nuget-Server verteilen. Das macht die Arbeit am Workflow schwierig, aber am Ende ist es nett, weil es uns die Schnittstellen-Kompatibilität zwischen den Anwendungen bewusst macht. Wir haben auch einige Kern-Microservices, die jede Anwendung, die wir mit SF Nuget verteilen, haben wird. Es ist noch jung und hat einige scharfe Kanten, aber es ist großartig.

tl; dr : Finden Sie heraus, was am besten für Ihr Entwicklungsteam in Bezug auf die Verwaltung von Code und Releases einzelner Services funktioniert. Verwenden Sie diff-Pakete , um nur Änderungen in Ihren Service Fabric-Anwendungen zu aktualisieren. Die kleinste Repo-Größe sollte eine Service Fabric-Anwendung sein, die in einer Visual Studio-Lösung enthalten ist.

Längere Version : Es ist vollständig möglich, Ihre Service Fabric-Anwendung in mehrere Anwendungen aufzuteilen, wobei die kleinste eine Service Fabric-Anwendung für jeden vorhandenen Microservice ist. Ob dies eine gute Idee ist oder nicht, hängt vollständig von der Art der Anwendung ab, die Sie erstellen möchten. Bestehen Abhängigkeiten zwischen den Diensten? Wie partitionieren Sie Services und könnte es ein Szenario geben, wenn Sie dies in einer koordinierten Weise tun möchten? Wie planen Sie Ihre Dienstleistungen zu überwachen? Wenn Sie dies in einer koordinierten Weise tun möchten, dann könnte es wieder sinnvoll sein, mehr Dienste in der gleichen Anwendung zu haben.

Wenn Sie den Code in Repos aufteilen, die kleiner als Ihre Visual Studio-Lösung sind, würden Sie wahrscheinlich nur Probleme bekommen. Sie könnten technisch mit Git-Submodulen oder Subtrees arbeiten, aber die Art und Weise, wie Visual Studio Projektreferenzen innerhalb von Lösungen behandelt, würde Sie wahrscheinlich sehr bald in die Merge-Hölle bringen.

Wenn es um die Aktualisierung Ihrer Service Fabric-Anwendung geht, können Sie in der Regel nur die geänderten Dienste in Ihrer Anwendung auf der Grundlage der Versionsnummern im Dienstmanifest aktualisieren. Dies wird als diff-Paket bezeichnet und kann zum Bereitstellen einer Anwendung in einem Cluster verwendet werden, in dem diese Anwendung mindestens einmal bereitgestellt wurde (d. H. Es handelt sich um ein Upgrade, nicht um eine Installation). Dies kann sich erheblich auf die Aktualisierungszeit Ihrer Bereitstellung auswirken, wenn Sie nur eine Minderheit der Dienste in der Anwendung aktualisieren. Die vollständige Dokumentation hierzu finden Sie hier . Es gibt auch eine SO-Antwort , die das beschreibt.

Ich würde sagen, dass Ihre Entscheidung, so viel in der Entwicklung, ein Trade-off zwischen verschiedenen Gewinnen ist.

Die Aufspaltung der Dienste in feinkörnigere Anwendungen mit weniger Service könnte Upgrades erleichtern (aber dieser Effekt könnte technisch zum Teil auch durch die Verwendung von diff-Paketen erreicht werden). Der Nachteil dieses Ansatzes besteht darin, dass Sie Abhängigkeiten als strenge Schnittstellen zwischen Ihren Diensten verwalten müssen. Ein Ansatz hierfür wäre, Ihre Service / Actor-Schnittstellen zu einem privaten NuGet-Feed zu veröffentlichen. Dies führt wiederum zu zusätzlicher Komplexität in Ihrer Entwicklungspipeline.

Wenn Sie alles im selben Repo halten, dieselbe Visual Studio-Lösung, könnte dieselbe Service Fabric-Anwendung auch für kleinere Lösungen funktionieren, aber auf lange Sicht wird es schwierig sein, mit ihr zu arbeiten, wenn Ihre Lösung in Bezug auf Zusammenführungen, Versionierung und Releases wächst / p>     

Wenn Sie Ihre Frage lesen, scheint es, als wäre Ihre Repository-Aufteilung hauptsächlich für die Bereitstellung gedacht, also werde ich mich auf diesen Aspekt konzentrieren.

Wir verwenden ein Git-Repository pro Service Fabric-Anwendung (das mehrere Services enthält). Dies vereinfacht die Durchführung von Continuous Integration und Continuous Deployment: Wenn das Repo (Code oder Config) geändert wird, die SF-Anwendung muss erstellt und bereitgestellt werden.

Wenn Sie die Build- und Releasefunktionen von VSTS online verwenden, können Sie die für Service Fabric verfügbaren Build Tasks problemlos nutzen, um differenzielle Upgrades zu unterstützen. Verwenden Sie die Task "Update Service Fabric-App-Versionen" ( Ссылка ) ), verwenden Sie die Option "Nur bei Änderung aktualisieren" mit dem "deterministischen Compiler-Flag" ( Ссылка ), um sicherzustellen, dass die Binärdateien immer gleich sind, wenn der Code derselbe ist, können Sie leicht differenzielle Upgrades pro SF-Anwendung durchführen.

Sie sollten nicht unbedingt einen Service Fabric-Dienst als einen Microservice betrachten.

Die Service Fabric-Taxonomie von Code / Diensten / Apps usw. bietet Ihnen eine hohe Flexibilität bei der Zusammenstellung Ihrer Anforderungen (wie bereits erwähnt). Berücksichtigen Sie die Tatsache, dass Sie mehr Code-Pakete in einem Dienst ausführen können, und versuchen Sie, das in eine Microservice-Definition zu übersetzen, macht nur noch schwieriger zu bewältigen.

Da es sich bei der SF-Anwendung um eine Bereitstellungseinheit handelt (ob sie einen oder mehrere aktualisierte Dienste enthält), sollten Sie Ihre Repo / Lösung / SF-Anwendungskonfiguration so strukturieren, dass Sie die meisten Änderungen an einer SF-App ( = eine Lösung und ein Repo).

Wenn Sie in einer Situation sind, in der Sie ständig mehrere SF-Apps bereitstellen müssen, um einen Wechsel herbeizuführen, sind Sie nicht produktiv.