Laden...

VS Solution-Verwaltung: CI / CD best practices für GIT

Erstellt von t2t vor 5 Jahren Letzter Beitrag vor 4 Jahren 1.964 Views
T
t2t Themenstarter:in
415 Beiträge seit 2007
vor 5 Jahren
VS Solution-Verwaltung: CI / CD best practices für GIT

Folgendes vereinfachtes Szenario: Ich habe mehrere Services in meiner Visual Solution. Dies gibt mir den großen Vorteil mehrere oder alle Services gleichzeitig zu starten und auch zu debuggen.

Nun möchte ich gerne eine CI / CD Pipeline basierend auf GitLab aufbauen, die bei jedem Checkin neue Docker-Images meiner Services baut. Nachteil hier ist, dass mir nun alle Services neu erstellt werden, wobei ich vielleicht nur einen von zehn verändert habe, da sie alle in einer Solution liegen.

Daher meine Frage: Gibt es Ansätze beide Vorteile zu verbinden? Alle Services in einer Solution fürs debugging und gleichzeitig eine CI / CD Pipeline, die nur die geänderten Services erstellt?

W
113 Beiträge seit 2006
vor 5 Jahren

Hallo t2t,

du könntest jeden Service in ein eigenes Repository legen.

Und zusätzlich ein Repository dass alle anderen als submodule enthält und deine Solution zum Debuggen.

sg

T
t2t Themenstarter:in
415 Beiträge seit 2007
vor 5 Jahren

Danke für den Hinweis. Kann Visual Studio damit denn umgehen und funktioniert die Git Integration dann noch wie gewohnt? Also, dass Visual Studio die commits in die entsprechenden submodule absetzt, wenn ich die Haupt-Solution auf habe?

16.807 Beiträge seit 2008
vor 5 Jahren

Wenn die Services den Micro Service Gedanken verfolgen, dann müssen sie in 99% der Fälle in einem eigenen Repository liegen.
Alle Services in visual studio direkt zu starten bis du evt. noch von einer "alten Gewohnheit" gewohnt; aber produktiv im Sinne von Microservices und Independence ist das halt nicht.
Services sollten sich nicht direkt kennen, wenn möglich.
Wenn sich alle Services kennen, dann baust du ein Monolith, der halt auf Prozesse verteilt ist - nicht ganz Sinn der Sache 😃

T
t2t Themenstarter:in
415 Beiträge seit 2007
vor 5 Jahren

Kennen tun sich die Services nicht. Aber für den Entwicklungs-Workflow finde ich es super smart, wenn ich beispielsweise das Frontend, die API und nen Worker-Service zusammen starten kann. Dann lade ich im Frontend eine Datei hoch, die API verarbeitet diese und legt eine Nachricht auf den Service Bus, worauf hin sich der Worker Service die Nachricht greift und ich bin überall in der Lage in diesen Workflow zu debuggen.

Daher stimme ich dir zu, ich will dahin jeden Servcie separat in einem eigenen Repo abzulegen, aber gleichzeitig diesen Entwicklungs-Workflow beibehalten. Wie würdest du sowas konkret lösen?

16.807 Beiträge seit 2008
vor 5 Jahren

Geht in der Form nicht 100%, weil es widersprüchlich ist.

T
t2t Themenstarter:in
415 Beiträge seit 2007
vor 4 Jahren

For the record: Ich hab diesen Anwendungsfall tatsächlich recht gut mittels Git Submodules lösen können. Ein push vom Submodule landet dann im jeweiligen Repo des Services und wird dann nach dem Merge auf den Master automatisch von der GitLab CI Pipeline verarbeitet.
Ich hab eine Haupt-Solution, welche die unterschiedlichen Services zusammenfasst, die per Submodule referenziert sind. Dadurch bin ich in der Lage alle benötigten Services in der Entwicklung gleichzeitig zu starten und zu debuggen. Ziemlich komfortabel.
Einzige Wermutstropfen ist, dass Visual Studios Git Integration damit nicht mehr umgehen kann. Das löse ich über die CommandLine oder GitKraken.

Daher noch mal ein spezieller Dank an WarLorD_XaN