Wie kann ein reibungsloser Übergang vom Organisationsmodell "Ein einziges großes VCS-Repository für alle Produkte" zum Modell "Viele kleine VCS-Repositorys" erreicht werden?

Es ist ein häufiges Szenario, dass sich die Codebasis eines Produkts, das sich in einem Repository in einem VCS-System befindet, so weit entwickelt, dass diese Codebasis möglicherweise mehrere Produkte enthält. Die Aufteilung der Codebasis auf mehrere VCS-Repositorys, von denen jedes einem einzelnen Produkt zugeordnet ist, kann verschiedene Vorteile bieten (siehe Vorteile eines Produkts pro VCS-Repository gegenüber dem Bloat-Repository-Modell weiter unten). Auf der technischen Seite ist das Aufteilen der Codebasis ein ziemlich einfacher Schritt, da die meisten VCS diesen Vorgang unterstützen. Die Aufteilung kann jedoch zu technischen Problemen im Zusammenhang mit automatisierten Tests, kontinuierlicher Bereitstellung, Service-Integration oder Überwachung führen (siehe Durch die Aufteilung aufgeworfene Probleme).) Organisationen, die eine solche Aufteilung planen, müssen daher wissen, wie dieser Übergang so reibungslos wie möglich durchgeführt werden kann, dh ohne dass ihre Liefer- und Überwachungs-Pipeline unterbrochen wird. Der erste Schritt besteht wahrscheinlich darin, den Projektbegriff besser zu verstehen und die Aufteilung in eine monolithische Codebasis zu skizzieren.

Bei den Antworten auf diese Fragen würde ich gerne sehen:

1. Ein Versuch, eine funktionierende Definition des Begriffs "Produkt" zu geben, die praktische Kriterien für die tatsächliche Abgrenzung von Produkten in einer vorhandenen Codebasis enthält.

2. Erstellen Sie gemäß dieser Arbeitsdefinition einen Plan, der die Aufteilung tatsächlich ausführt. Wir können die vereinfachende Annahme treffen, dass die Codebasis von einem vollautomatisierten SDLC verarbeitet wird, der eine kontinuierliche Integration und eine kontinuierliche Lieferung implementiert . Das heißt, jeder Zweig wird von einer automatisierten Testsuite validiert, die in der aktuellen Codebasis implementiert ist, und jeder Zusammenschluss zu einem „magischen“ Zweig generiert Produktartefakte , die getestet und bereitgestellt werden. ( Produktartefakte sind zB Quell-Tarballs, Dokumentation, binäre Softwarepakete, Docker- Images, AMIs, Unikerne.)

3. Ein solcher Plan ist zufriedenstellend, wenn er erklärt, wie man das umgeht

Durch die Trennung aufgeworfene Fragen

1. Wie hängen automatisierte Testverfahren mit dem bereits vorhandenen monolithischen Repository und den geteilten Repositorys zusammen?

2. Wie hängen automatisierte Bereitstellungsverfahren mit dem bereits vorhandenen monolithischen Repository und den geteilten Repositorys zusammen?

3. Wo ist der Code für die automatisierten Bereitstellungsverfahren selbst gespeichert?

4. Wo sind Strategien für gespeicherte Infrastruktur , Überwachung und Hochverfügbarkeit ?

5. So stellen Sie sicher, dass ein Entwickler jeweils nur eine Codebasis benötigt (verwendet jedoch möglicherweise Artefakte aus anderen Codebasen).

6. Wie kann ein Werkzeug wie Git-Bisect

Randnotiz: Vorteile eines Produkts pro VCS-Repository gegenüber dem Aufblähungs-Repository-Modell

Mehrere kleine Repositories, die die Codebasis für ein bestimmtes Produkt enthalten, bieten die folgenden Vorteile gegenüber dem Ansatz des "Aufblasen-Repositorys":

1. Mit einem Bloat-Repository ist es schwierig, ein Release zurückzusetzen, wenn ein Produkt instabil ist, da die Historie mit der Historie anderer Produkte gemischt ist.

2. Bei einem Aufblähungs-Repository ist es schwierig, den Projektverlauf zu überprüfen oder Informationen abzurufen. Bei kleinen Repositorys ist es wahrscheinlicher, dass wir diese Informationen lesen. (Dies ist möglicherweise spezifisch für VCS wie git, wo wir im Gegensatz zu svn keine Teilbäume auschecken können!)

3. Mit einem Bloat-Repository müssen wir viel mehr Branch-Dance machen, wenn wir uns entwickeln. Wenn wir N Repositorys haben, können wir parallel an N Zweigen arbeiten, wenn wir nur 1 Repository haben, können wir nur an einem Zweig arbeiten, oder wir haben eine Menge Arbeitskopien, die ebenfalls mühsam zu handhaben sind.

4. Mit mehreren kleinen Repositorys geben die Protokolle eine Heatmap des Projekts. Sie können sogar als Proxy für die Wissensverbreitung im Entwicklerteam verwendet werden: Wenn ich mich seit 3 ​​Monaten nicht für repo X engagiere, kann es sinnvoll sein, mich einem Team zuzuordnen, das an repo X arbeitet, damit ich über die Entwicklungen auf dem Laufenden bin in dieser Komponente.

5. Mit kleinen Repositories ist es einfacher, sich einen klaren Überblick über eine Komponente zu verschaffen. Wenn sich alles in einem einzigen großen Speicher befindet, gibt es kein greifbares Artefakt, das jede Komponente abgrenzt, und die Codebasis kann leicht in Richtung der großen Schlammkugel driften .

6. Kleine Repositories zwingen uns, an Schnittstellen zwischen Komponenten zu arbeiten. Aber da wir eine gute Kapselung haben wollen, ist dies eine Arbeit, die wir sowieso tun sollten, deshalb würde ich dies als einen Vorteil für kleine Repositories ansehen.

7. Mit mehreren kleinen Repositories ist es einfacher, mehrere Produktbesitzer zu haben.

8. Bei mehreren kleinen Repositorys ist es einfacher, einfache Codestandards zu haben, die für ein vollständiges Repository relevant sind und die automatisch überprüft werden können.

Es ist eine faszinierende Frage, für die es möglicherweise keine wirklichen Antworten gibt. Ich weiß zu schätzen, dass Sie versucht haben, die Frage im VCS kontextualisiert zu halten, sie sich jedoch von selbst auf das Design der Infrastruktur und die Implementierungsplanung hochskalierte.

Es scheint jedoch, dass viele von uns an einem solchen Übergang arbeiten, der aufregend, aber gleichzeitig so frustrierend und schmerzhaft sein kann. und ich möchte meine Erfahrungen und Ansichten teilen und versuchen, nicht pedantisch zu sein, und nur, weil ich vielleicht kein so guter Ingenieur bin, auch nicht langweilig zu sein.

Design

Infrastruktur und Architektur sollten zusammenpassen, um eine moderne Software zu schreiben. Eng verbunden, wenn Sie wollen. Es mag seltsam klingen, diese Wörter zu verwenden, aber wir sprechen hier nicht unbedingt über Code selbst: Ich meine, sie müssen Teil desselben Bauplans sein. Als die Wolken ankamen und die Leute begannen, Software für sie zu schreiben, erkannten wie viele Leute dann, dass sie, wenn sie die Schlammbälle dorthin legten, dieselben Schlammbälle an einem anderen Ort sein würden. und sie arbeiten wahrscheinlich heute in devops. Da devops nur ein Schlagwort mit so vielen verschiedenen Bedeutungen für verschiedene Leute ist, habe ich Orte gesehen, an denen das devops-Team in jedem Architektur-Meeting saß. andere Orte, an denen nur Automatisierung ist. Um diese Art der Transformation zu erreichen, müssen wir uns den Weg erkämpfen, um dort zu sitzen.

Vertrauen

Der Übergang muss isoliert gehalten werden, in dem Sinne, dass ein konsistenter Abschnitt der Geschichte existieren muss, der den Übergang selbst und nur sich selbst ohne weitere Änderungen (nach mehreren Monaten der Vorbereitung) bereitstellt. Mit welcher Zuversicht würde man es genehmigen und den roten Knopf drücken?

Ich meine, die Codebasis muss geändert werden, um die neue VCS-Struktur aufzunehmen, und es wird sehr schwierig sein, sie während der Entwicklung zusammenzuführen. (Für dieses Problem gibt es möglicherweise vereinfachende Strategien, ich werde später über eine gemeinsame sprechen, die dazu beitragen kann, die Entwicklung ein wenig zu parallelisieren.)

Ich wette, die einzige Möglichkeit sind Verhaltenstests, und es sollte dieselbe Reihe von Verhaltenstests gestartet werden, um die alte mit der neuen Codebasis zu überprüfen. Wir überprüfen hier nicht, ob sich die Anwendung wie erwartet verhält, aber der Übergang ändert das Verhalten nicht. Nicht bestandene Tests können eine gute Sache sein! Wenn sie weiterhin scheitern!

Tatsächlich ist es sehr ungewöhnlich, dass Schlammbälle gut getestet werden. In der Regel ist der Code sehr eng gekoppelt, und wahrscheinlich wurde er für die meisten älteren Codes nicht mit einem testgetriebenen Ansatz entwickelt, auch nicht für Komponententests.

Wenn ein solcher Testcode überhaupt fehlt, muss er zuerst geschrieben werden.

Strategie

Ja, der Übergang muss isoliert bleiben. aber gleichzeitig integriert. Ich weiß, dass ich hier vielleicht verrückt klinge, aber ich würde keine anderen Worte finden, um zu beschreiben, wie Vertrauen mit dem Geschäft mithalten kann. Sehr wenige, wenn überhaupt keine, Unternehmen möchten die Entwicklung einer großen monolithischen Codebasis stoppen, um Platz für diesen Übergang zu schaffen. Möglicherweise tragen Hunderte von Entwicklern kontinuierlich zur Codebasis bei (ich würde hier das manipulierende Wort aus unserem POV verwenden). Während sich unsere Arbeit auf einen bestimmten Schnappschuss beziehen muss, um Vertrauen zu schaffen, müssen wir uns neu orientieren (nicht in einer git-Bedeutung hier), um zu vermeiden, für immer zurückzufallen.

Die Implementierungsstrategie hier kann verschiedene Erfahrungen geben. Eine übliche Entwicklungslinie besteht darin, neuere Implementierungszweige (die in diesem Fall in anderen Repositorys leben) zu verpacken / anzupassen (um Endpunkte mit optional neu angeordneten Schemata verfügbar zu machen), wenn sie mit dem Kern interagieren müssen. Ein Übergang mit einer solchen Strategie kann zusammen mit dem Refactoring gleichzeitig ein POC-Szenario für den VCS-Übergang und später einen schrittweisen Ansatz bieten. Sehen Sie, wie der Ball aus Schlamm geformt wird. Ja, das Leben bietet so viele lustigere Dinge.

Technische Schulden

Die Bereiche der Unternehmensführung begannen, die technischen Schulden zu verstehen und in Betracht zu ziehen. Nein, kratz das, nicht wahr. Während es immer häufiger vorkommt, Messungen und Qualitätsdaten in Bezug auf statische Code-Analyse, Code-Überprüfung, Verhaltenstestergebnisse und Leistung zu erfassen und nette Berichte und alles zu generieren, ist es immer noch unglaublich schwierig, das Unternehmen dazu zu bringen, eine kontinuierliche Analyse zu akzeptieren Refactoring-Ansatz. Der geschäftliche Wert davon. "Wir verfolgen einen agilen Prozess, der die Funktionen nicht verbessert, oder?" . Im Grunde genommen negieren sie damit das Bestehen einer technischen Verschuldung. Ich betrachte dies als den häufig fehlenden notwendigen Schritt, um einen Übergang von einer Monolith- zu einer Microservice-Architektur zu beginnen.

Reaggregation

Nach alledem möchten Sie möglicherweise immer noch eine einzige Repository-ähnliche Ansicht bereitstellen, in der Sie mehr als ein einziges Produkt erstellen können. Aus irgendeinem Grund, dh Curr / Next Release, Multibrand, Customer Builds. Tools wie Google Repo können in diesem Fall hilfreich sein. Ich habe noch nie einen benutzt, aber ich weiß, dass ich einen Tag brauchen werde.

Integrationstests

Integrationstests setzen bei Microservices einen anderen Kontext voraus, nämlich das Testen der eigenen API. Höhere Test-, Funktions- oder Leistungsebenen können und werden existieren, aber bedeuten sie viel ohne ordnungsgemäße Integrationstests? Es wäre wie mit Integrationstests ohne Unit-Tests. Natürlich nicht. Das ist der Grund, warum Sie, wenn Sie Bisect verwenden müssen, es in einem Microservice-Repository-Zweig ausführen. Vergessen Sie, dies im Mudball-Repository auszuführen.

PS. Dies ist ein Entwurf, mein Englisch ist schlecht und ich werde es eines Tages beheben