Wie man kontinuierliche Lieferung mit Mikrodienstleistungen verwaltet?

Question

Im Moment arbeiten wir mit Jenkins als CI und CD, wir verwenden auch eine Agile-Methode (Sprint). Ich habe mich gefragt, wie ich die Releases meiner Software verwalten kann.

Zum Beispiel entwickeln wir eine Shopping Site für ein Geschäft. Die Entwicklung besteht aus einer Anwendung, die 3 Mikrodienste verbraucht.

Komponenten:

Anwendung: Ist die Benutzeroberfläche
Micro Service 1: Umsatz
Micro Service 2: Benutzer
Micro Service 3: Produkte

Anfangszustand die einkaufsseite:

Wir beginnen mit der Entwicklung der Shopping-Site von Grund auf neu. Wie ich bereits sagte, arbeiten wir mit einer Agilen Methodologie (Sprints).

Sprint 1:
- Entwickeln Sie Produkte Micro Service.
- Entwickeln Sie Benutzer Micro Service.
Ende des Sprints 1

Zu diesem Zeitpunkt kann ich nur Mikro-Service-Tests gilt, wie Unit-Tests, Vertragsprüfung, usw. Weil ich nicht die Anwendung bereit ich nicht End-Tests Ende machen kann oder Funktionstests, die auf dem gesamten System basieren, kann ich auch nicht in der UAT-Umgebung bereitstellen (zeige den Benutzern eine Beta-Version), da der Benutzer nicht in der Lage ist, explorative Tests durchzuführen. Jetzt muss ich warten, bis der Anwendungs- und Vertriebsmikroservice beendet ist, sodass ich dem Nutzer die Beta-Version zeigen und jede andere Art von Test anwenden kann.

Sprint 2:
- Entwickeln Sie Verkaufs-Mikro-Service.
- Entwickeln Sie die Anwendung.
Ende der Sprint 2

Nun, da alle benötigten Komponenten fertig sind die Anforderungen der Anwender zu erfüllen, können wir mit der Pipeline weiter. Anwendung aller erforderlichen Tests, bevor wir dem Benutzer eine Beta-Version zeigen.

Also die Millionen-Dollar-Frage ist, wie würden Sie dieses Szenario mit Jenkins und GitLab tun?

Ich verstehe, dass Mikro-Dienste für jede Komponente im System unabhängig sein sollten, aber am Ende hängt das gesamte System voneinander ab, zum Beispiel wenn ich einen neuen Mikro-Service wie "Versand" hinzufüge, sollte diese neue Funktionalität sein In der Anwendungsoberfläche gesehen, bedeutet dies, dass ich vor der Freigabe des neuen Systems eine Abhängigkeit vom "Versand" -Mikroservice und der Anwendungsschnittstelle habe, denn ohne beide Entwicklungen kann ich die Benutzeranforderungen vor der Bereitstellung in der Produktion nicht vollständig testen.

P.S. Es tut mir leid für jede Verwirrung in diesem Beitrag, aber ich bin völlig neu in diesem Thema.

Answer 1

Der "unabhängige" Aspekt von Microservices ist hier essentiell.Grundsätzlich sollten Sie in der Lage sein, jeden Service als eigenständige App zu behandeln, und Ihre Benutzeroberfläche sollte nicht von den "Sales/Users/Products Services" als "libs" (zB C# DLL, Java Jars, etc.) abhängig sein, sondern stattdessen eine Art von API (zB REST API) um sich gegenseitig anzurufen.

den Unterschied zu verdeutlichen, sollten Sie diese nicht haben:

Aber stattdessen sollten Sie etwas davon haben.

Nun nehmen wir an, Sie in die wunderbare Welt mit Microservices REST API zwischen UI und jede Ihrer Dienstleistungen.

In Jenkins wird es ziemlich einfach. Für jeden Service (+ Hauptanwendung) möchten Sie einen Job, der kompiliert, testet und Ihren Dienst auf dem Zielserver bereitstellt.

Solange Ihre Dienste sind unabhängig, und wenn Sie app behandeln versionning richtig, sollten Sie nicht jede Art von Synchronisation zwischen jedem Ihrer Jenkins Jobs benötigen.

Natürlich würde der Build/Test/Deploy-Prozess in einer gemeinsamen Pipeline-Datei externalisiert werden, so dass Sie ihn für Ihre verschiedenen Jobs wiederverwenden können. Setzen Sie einfach einen neuen API-Endpunkt im Vertriebsservice fest, bevor Sie den UI-Teil festschreiben, der den neuen Verkaufsendpunkt verwendet ... aber ich denke, das ist nur gesunder Menschenverstand!

Wenn Sie neu bei Jenkins sind, ist ein guter Anfang die pipeline documentation!