Polyrepo<\/b><\/a> ist ein Repository, das mehrere Projekte enth\u00e4lt. <\/b>Wir verwendeten einen Polyrepo-Organisationsstil, was einfach bedeutet, dass jedes Frontend-Projekt sein eigenes Repository hatte, obwohl viele der Projekte die gleichen Aufgaben wiederholten und dieselben Funktionen reproduzierten. Als zentraler Knotenpunkt k\u00f6nnen Polyrepos zu einer Herausforderung bei der Wartung werden, wenn die Anzahl der gespeicherten Projekte w\u00e4chst. In vielen F\u00e4llen mussten wir jedes Polyrepo gleichzeitig mit denselben Updates bereitstellen, um ein konsistentes Erlebnis \u00fcber unsere Produkte hinweg zu gew\u00e4hrleisten.<\/p>\n\n\n\n Aus Wartungssicht machte es dies f\u00fcr Teams schwierig, den ben\u00f6tigten Code zu finden und damit zu arbeiten. Die Verwaltung mehrerer Repos mit redundanten Funktionen bedeutet normalerweise, dass sie langsamer reagieren und<\/i> ressourcenintensiver sind, was ein gro\u00dfes Problem darstellt, wenn Sie h\u00e4ufig Code pushen und pullen. Da Funktionen \u00fcber mehrere Codebasen verteilt sein k\u00f6nnen, k\u00f6nnen Polyrepos die Fehlersuche schwieriger machen als die Suche nach der sprichw\u00f6rtlichen Nadel im Heuhaufen.<\/p>\n\n\n\n
Mit unserer Polyrepo-Struktur vor dem Rebuild wussten wir, dass die Zukunft eine Realit\u00e4t sein w\u00fcrde, in der wir mit einer Taschenlampe durch Repos jagen und nach dem suchen, was wir brauchten, und dass es eine Herausforderung sein w\u00fcrde, zusammenzuarbeiten, zu skalieren und Code zu teilen, w\u00e4hrend wir wuchsen.<\/p>\n\n\n\n
Dies waren unsere Hauptbedenken:<\/b><\/p>\n\n\n\n\nHerausfordernde gemeinsame Entwicklung<\/li>\n\n\n\n Enge Kopplung<\/li>\n\n\n\n Skalierbarkeits-, Verf\u00fcgbarkeits- und Leistungsmanagement<\/li>\n\n\n\n Schwierig, Code zu teilen<\/li>\n\n\n\n Duplizierung<\/li>\n\n\n\n Inkonsistentes Tooling<\/li>\n<\/ul>\n\n\n\nWenn es um die Verwaltung von Quellcode geht, gibt es viele L\u00f6sungen, aber wir haben entschieden, dass eine modulare Monorepo-Struktur den Gro\u00dfteil unserer Entwicklungsprobleme in Zukunft lindern w\u00fcrde.<\/p>\n\n\n\n
Pl\u00e4ne f\u00fcr ein schickes neues Repo: Ein modularer Ansatz<\/h2>\n\n\n\n Ein Monorepo-Ansatz beinhaltet das Speichern des gesamten Codes des Projekts in einem einzigen, gro\u00dfen Repository<\/b>. Dies w\u00fcrde die Probleme mit dem Teilen von Code und der Duplizierung l\u00f6sen, die wir bei unserer Polyrepo-Organisation erlebt haben, aber Monorepos sind kein Allheilmittel. Wenn der Code eng gekoppelt ist, m\u00fcssen Monorepos auch modular konzipiert sein.<\/p>\n\n\n\n
Ein modularer Ansatz beinhaltet die Aufteilung eines gro\u00dfen Projekts in kleinere, unabh\u00e4ngige Module, die separat entwickelt, getestet und gewartet werden k\u00f6nnen<\/b>. Dies erm\u00f6glicht eine gr\u00f6\u00dfere Flexibilit\u00e4t und Wiederverwendbarkeit sowie die M\u00f6glichkeit, einzelne Module einfach zu aktualisieren, ohne den Rest des Projekts zu beeintr\u00e4chtigen.<\/p>\n\n\n\n
Wir wussten, dass eine modulare Monorepo-L\u00f6sung es uns erm\u00f6glichen w\u00fcrde, effizienter zu sein bei:<\/p>\n\n\n\n
\nCode-Generierung<\/li>\n\n\n\n Code-Sharing<\/li>\n\n\n\n Verteilte Aufgabenausf\u00fchrung und Orchestrierung<\/li>\n\n\n\n Caching<\/li>\n\n\n\n TypeScript<\/li>\n<\/ul>\n\n\n \r\n\r\n
TypeScript ist eine Obermenge von typisiertem JavaScript, die es Entwicklern erleichtert, Projekte in gro\u00dfem Ma\u00dfstab zu erstellen.<\/b> Es verbessert die Entwicklererfahrung durch die Bereitstellung von Schnittstellen, Typ-Aliasen, statischer Code-Analyse zur Entwicklungszeit und anderen Tools, w\u00e4hrend es Entwicklern erm\u00f6glicht, ihren Projekten Typen hinzuzuf\u00fcgen. F\u00fcr unser Team ist TypeScript eine F\u00e4higkeit, von der wir wussten, dass wir sie suchen wollten, wenn es darum ging, unserem Team neue Mitglieder hinzuzuf\u00fcgen.<\/div>\r\n <\/div>\r\n\n\n\nAuf die F\u00fc\u00dfe treten: Der Deployment-Tanz<\/h2>\n\n\n\n Zweifellos besteht die gr\u00f6\u00dfte Herausforderung beim Leben in einem Monorepo (monolithisch oder anders) darin, dass das Potenzial, uns gegenseitig auf die F\u00fc\u00dfe zu treten, umso gr\u00f6\u00dfer ist, je mehr Leute dazu beitragen. Was n\u00fctzt eine \u00fcberarbeitete Entwicklererfahrung, wenn Ihr Code bei einem schlechten Merge \u00fcberschrieben wird? Wenn wir wirklich eine ganzheitliche \u00dcberarbeitung unseres Stacks vornehmen, m\u00fcssen wir uns auch ansehen, wie wir unseren Deployment-Prozess verbessern k\u00f6nnen. Dies waren die dringendsten Herausforderungen:<\/p>\n\n\n\n
\nSkalierbarkeit: <\/b>Es w\u00e4re eine schlechte Idee, den gesamten Code im Mono-Repo f\u00fcr die kleinsten \u00c4nderungen, wie z. B. die Behebung eines Tippfehlers in einem Text, neu zu erstellen. Genau das haben wir in unserem alten System gemacht. Der neue Prozess w\u00fcrde die integrierten Funktionen von NX nutzen, um die von der \u00c4nderung betroffenen Dateien zu bewerten und nur diese auf granularster Ebene neu zu erstellen.<\/li>\n\n\n\nDeployment: <\/b>Wir haben das meiste Zubeh\u00f6r unserer Deployment-Pipeline beibehalten. Sobald das Image erstellt ist, landet es im GitHub Container Repository. Unser SRE-Team hat unser Deployment-System w\u00e4hrend der Migration von AWS zu GCP optimiert. Wir k\u00f6nnen ganz einfach jeden Branch aus unserem Slack-Deployment-Kanal bereitstellen, mit einem sch\u00f6neren Bericht dank einer k\u00fcrzlichen Erg\u00e4nzung, die wir w\u00e4hrend der Migration erhalten haben.<\/li>\n\n\n\nCI;CD:<\/b> Unser altes System nutzte eine wirklich alte Version von Jenkins, um Tests auszuf\u00fchren und unsere App-Images hinter einem VPN zu erstellen\/verteilen. Wenn der Build fehlschlug, brauchten wir einen hochrangigen Senior-Entwickler, der mit den alten Methoden vertraut war, um ihn zu reparieren. In unserem neuen System planten wir den Wechsel zu GitHub Actions, wo Konfigurationen zug\u00e4nglich, deklarativ und gut dokumentiert sind.<\/li>\n<\/ul>\n\n\n\nMiese Herausforderungen und exzellenteste L\u00f6sungen<\/h2>\n\n\n\n Projekte jeder Art haben Herausforderungen, erwartete und \u00fcberraschende. Wir wussten, dass wir planen mussten, um einige Probleme zu \u00fcberwinden, und dass sich die neue Version der App aus mehreren Blickwinkeln auf die Leistung konzentrieren musste.<\/p>\n\n\n\nIdentifizierte Probleme<\/th> Vorgeschlagene L\u00f6sungen<\/th><\/tr><\/thead> Unklare Code-Konventionen<\/strong>Code-Styleguide<\/strong>\u00dcberlasteter State<\/strong>Trennung von Netzwerk-Cache und App-State<\/strong>Mehrschichtige Netzwerkarchitektur<\/strong>\u00d6ffentliche API zuerst<\/strong>Werfen Sie das Kind nicht mit dem Bade aus<\/h3>\n\n\n\n Wir haben im letzten Jahrzehnt Hunderttausende von Zeilen Code geschrieben. Angesichts des Ma\u00dfstabs und Umfangs dieses neuen Plans w\u00fcrde es fast genauso viele Jahre dauern, unsere alten Funktionen zu portieren und in das neue Paradigma umzuschreiben. Das w\u00e4re von vornherein zum Scheitern verurteilt. Wir mussten einen Weg finden, diese bestehenden Funktionen weiterhin einzubinden, ohne unsere Ziele f\u00fcr den neuen Stack zu beeintr\u00e4chtigen. Wir fanden eine L\u00f6sung in einer Technologie namens Module Federation.<\/p>\n\n\n\n
Mit dem Module Federation Plugin von Webpack konnten wir einen neuen Build unserer alten Anwendung mit minimalen \u00c4nderungen erstellen<\/b>, der in der Lage w\u00e4re, bestehende Funktionen in den neuen Portal-Stack zu integrieren. Wir h\u00e4tten weiterhin das langfristige Ziel, den nun veralteten Code auf neuere Standards zu portieren, aber dies w\u00fcrde es uns erm\u00f6glichen, sofort damit zu beginnen, neue Funktionen mit den neuen Vorteilen zu schreiben.<\/p>\n\n\n\nWir haben einen Plan, aber k\u00f6nnen wir ihn verwirklichen?<\/h2>\n\n\n\n
Wir wussten, dass die Konsolidierung unserer Plattformen bei gleichzeitigem kontinuierlichen Wachstum von Funktionen und Produktgruppen einen massiven Aufwand erfordern w\u00fcrde, und unsere Planung beeinflusste, was wir f\u00fcr unseren neuen Frontend-Stack wollten und wie wir das unsterbliche Erbe von antiquierten CSS-Styling-Systemen, veralteten Klassenkomponenten-Mustern und einem klobigen App-State-Management bew\u00e4ltigen w\u00fcrden.<\/p>\n\n\n\n
Weil wir von Grund auf neu gebaut haben \u2013 insbesondere mit dem Wechsel von AWS zur Google Cloud \u2013 war die beste L\u00f6sung ein sauberer Schnitt<\/b>. Ein neues Repo mit besseren, h\u00f6heren Standards, Module Federation, modularen, gemeinsam genutzten Bibliotheken und einer umfassenderen nutzerorientierten und internen Dokumentation.<\/p>\n\n\n\nEs\u00a0war eine intensive Planungs- und Vorbereitungsphase. Wie bei allen gro\u00dfen Projekten war die Generierung der Ideen und des Proof of Concept ein technisches und kreatives Unterfangen, an dem nur wenige ausgew\u00e4hlte Personen beteiligt waren.<\/p>\n\n\n\n
Phase 2? Die Idee in die Realit\u00e4t umsetzen \u2013 und daran waren noch viel mehr Teams beteiligt. Entwickler, ich glaube, unser Abenteuer nimmt gleich eine h\u00f6chst interessante Wendung. <\/p>\n\n\n\r\n