Implementatietechnieken voor algemene referentiearchitectuur
Er zijn verschillende manieren om code opnieuw te gebruiken met Adobe Commerce. Deze vier implementatietechnieken hebben elk hun eigen voordelen. De voorbeelden in dit artikel zijn van eenvoudige naar complexere volgorde geordend. Kies de strategie die het beste bij uw project en toekomstige routekaart past. Een migratie van de ene strategie naar de andere kan tijdrovend zijn.
Wanneer gebruikt u de globale referentiearchitectuur
De globale verwijzingsarchitectuur kan waardevol zijn, afhankelijk van het aantal instanties u bezit. Een instantie is een standalone installatie van Adobe Commerce die zijn eigen gegevensbestand gebruikt. Tel het aantal productiedatabanken om te weten hoeveel instanties u bezit. Als u meer dan één instantie handhaaft, of als u dit scenario in de toekomst voorziet, kunt u van globale verwijzingsarchitectuur profiteren. Hoe meer functionaliteit de instanties delen, hoe meer waarde een algemene verwijzingsarchitectuur toevoegt.
In elk van deze scenario's is het raadzaam te onderzoeken met behulp van meerdere instanties van Adobe Commerce.
- Verschillende Eigenaars van de Opslag: Als u code voor veelvoudige opslageigenaars handhaaft, elk met hun eigen afzonderlijke opslag, kunnen de afzonderlijke instanties nodig zijn om hun individuele vereisten effectief te handhaven.
- Naleving van Nationale Regels: Bepaalde verordeningen vereisen dat de klantengegevens binnen specifieke gebieden moeten worden opgeslagen. In dergelijke gevallen zijn afzonderlijke gevallen van essentieel belang om de naleving van deze verordeningen te waarborgen.
- Operationele Variaties over Geografische Regio's: Het werken in veelvoudige gebieden kan verschillende onderhoudsprogramma's en vereisten betekenen. Door afzonderlijke instanties te gebruiken, kunt u deze variaties op een efficiënte manier beheren.
- de Verkoop van de Flits van hoge intensiteit: De opslag die grote flitsverkoop leidt vereist vaak geoptimaliseerde serverprestaties. De specifieke infrastructuur die door afzonderlijke instanties wordt verstrekt verzekert optimale prestaties tijdens dergelijke hoge vraagperiodes.
- Belangrijke Verschillen tussen Merken of Landen: Wanneer het verschil tussen merken of landen groot is, leidt het gebruiken van één enkele instantie in code die slechts voor sommige merken of landen wordt gebruikt. De afzonderlijke instanties kunnen prestaties en stabiliteit verbeteren door onnodige code voor merken en landen te elimineren die het niet nodig hebben.
Algemene referentiearchitectuur
Naast 'geen GRA-patroon' zijn er vier stijlen van GRA-patronen.
Geen GRA-patroon
Wanneer geen GRA-patroon wordt gebruikt, is elke Adobe Commerce-instantie een unieke toepassing. Er is geen hergebruik van code, behalve door code handmatig van de ene instantie naar de andere te verplaatsen. Deze kopieën lopen altijd uiteen. De hoeveelheid inspanning om ervoor te zorgen dat elke instantie de zelfde veranderingen maar nog werkt zoals verwacht kan overweldigend worden. In dit scenario hebben drie instanties driemaal de onderhoudsinspanning van één instantie nodig.
Het gesplitste Git GRA-patroon
Dit patroon bestaat uit Git-opslagplaatsen voor ontwikkeling en één Git-opslagplaats per instantie. Elk bestand in de instantie wordt onderhouden in een van de opslagplaatsen voor ontwikkelaars. Ze komen samen als een vlecht die de hele GRA vormt. Elke coderegel bestaat alleen in één ontwikkelingsopslagplaats en wordt met behulp van de omschakelingstechniek op de instanties geïnstalleerd, wat leidt tot hergebruik van code.
Het GRA-patroon van bulkpakketten
De Adobe Commerce-kernmodules en modules van derden worden rechtstreeks geïnstalleerd via Composer-opslagruimten. Git-opslagruimten kunnen worden gebruikt als composer-opslagruimten. In dit patroon wordt de gehele gedeelde GRA-codebase gehost in één of enkele Git-opslagruimten en geïnstalleerd via Composer. Het belangrijkste kenmerk is dat meerdere modules, taalpakketten of thema's in één composerpakket worden ondergebracht, waardoor de ontwikkeling wordt vereenvoudigd.
Het GRA-patroon van de afzonderlijke pakketten
Elke Adobe Commerce-module, taalpakket of elk thema wordt geïnstalleerd als een apart composerpakket. Elke aanpassing heeft een eigen Git-opslagplaats. Dit betekent ultieme flexibiliteit in de samenstelling van de instanties en heeft een betrouwbaar beheer van composerafhankelijkheid. Voor het optimaliseren van prestaties, worden alle pakketten weerspiegeld in één enkele privé composer bewaarplaats.
Het monorepo GRA-patroon
Alle ontwikkeling vindt plaats in één enkele codeopslagplaats. Automatisering genereert pakketten voor nieuwe versies en publiceert deze naar een composer-opslagplaats. Het patroon combineert de lage ontwikkelingsoverhead van de bulkpakketaanpak met de flexibiliteit van de afzonderlijke pakketaanpak. Het monorepopatroon is ook ideaal voor het uitvoeren van geautomatiseerde functionele tests.
Een GRA-patroon kiezen
De keuze voor een GRA-patroon wordt gemaakt door de complexiteit van het project, de behoefte aan flexibiliteit en het vermogen van het ontwikkelingsteam om zich aan te passen te beoordelen.
Teams met weinig Adobe Commerce-ervaring kunnen het best eenvoudig beginnen. Maar als het project vanwege zijn kenmerken een complexer GRA-patroon vereist, moet u geen compromissen sluiten.
Gemeenschappelijke projectkenmerken voor elk patroon:
-
Geen patroon GRA: Enige instantie van Adobe Commerce zonder plannen om uit te breiden. Meerdere gevallen van Adobe Commerce met minimale onderlinge uniformiteit.
-
Splitst het patroon van Git GRA: De teams die Composer voor hun aanpassingen wensen te vermijden, in de meeste gevallen is het Bulk pakketpatroon een aangewezen patroon aan Splitst Git.
-
Bulk pakketGRA patroon: De codebase van de aanpassing met hoge onderlinge afhankelijkheid. Exemplaren hebben allemaal zeer vergelijkbare combinaties van aangepaste pakketten. Geen regelmatige promotie of vernietiging van afzonderlijke pakketten. Teams die weinig ervaring hebben met codebeheer en die eenvoud nodig hebben.
-
Afzonderlijke pakketten GRA patroon: Het flexibele beheer van het versiewerkingsgebied nodig. In de komende vijf jaar worden maximaal 50 aangepaste pakketten verwacht. Potentieel, globale en regionale lagen van gemeenschappelijke code. Er zijn geen plannen om naar een Monorepo-patroon te migreren. Het team is technisch deskundig en heeft strikte procesnaleving.
-
patroon Monorepo GRA: Alle kenmerken van het afzonderlijke patroon GRA van pakketten. De komende vijf jaar worden meer dan 50 pakketten verwacht. Noodzaak van uitgebreide geautomatiseerde tests. Ondersteuning voor letterlijke omgevingen. Complexe codebase op bedrijfsniveau die moet worden geschaald zonder onderhoudskosten aan een gelijk tarief te schalen.
De kosten van een verkeerde keuze
Migratie van het ene patroon naar het andere is mogelijk. In het onderstaande diagram ziet u de mate van impact van de overgang van het ene naar het andere patroon. Groene lijnen tonen een lage impact, gele en amberkleurige lijnen tonen een matig complexe tot complexe migratie.
