Beste werkwijzen voor codebeheer voor Adobe Commerce
Dit onderwerp wordt ontworpen om u te helpen beslissen of om Git of Composer te gebruiken om douanecode, met aandacht voor versiebeheer, codeingewikkeldheid, en gebiedsdeelbeheer te verspreiden.
Betrokken producten en versies
- Adobe Commerce over cloudinfrastructuur
- Adobe Commerce ter plaatse
Het behandelt zowel globale verwijzingsarchitectuur (GRA)en enige instantie installaties.
Definities
- Globale Architectuur van de Verwijzing (GRA): Ook gekend als Wit de Architectuur van het Etiket of Gemeenschappelijke Basis van de Code. Dit is de architectuur van de moduledistributie voor een multi-instantie opstelling.
- multi-instantie opstelling: De zelfde cliënt gebruikt afzonderlijke installaties van Adobe Commerce voor afzonderlijke gebieden of merken. Elke installatie heeft zowel gedeelde als unieke modules.
- Single-instance opstelling: Er is slechts één installatie van Adobe Commerce. Er kunnen meerdere exemplaren van de broncode bestaan voor verschillende testomgevingen, maar er is slechts één versie van de productiecode.
Wanneer gebruikt u Git of Composer
- Standaardbenadering voor het beheren van code voor een Single Instance Setup
- Wanneer de basis van de code in de toekomst geen deel zal uitmaken van een meermerkige GRA
- Wanneer alle merken op één instantie als websites worden uitgevoerd
- Wanneer de codebasis in de toekomst deel kan of zal worden van een multi-instantie opstelling
- Wanneer bijna alle modules onderling zijn gekoppeld (niet aanbevolen)
- Wanneer de code door een team wordt gehandhaafd dat niet vertrouwd met Composer is
- Standaardbenadering voor het beheren van code voor een meervoudige instantie-instelling
- Wanneer de Adobe de codebasis handhaaft of het handhaven team vertrouwd met Composer is
Eigenschappenmatrix
Elk enig pakket Composer wordt vertegenwoordigd door een bewaarplaats van het Git
app/vendor/vendor/ als ze via de markt of packagist.org worden geïnstalleerd. Anders worden ze geïnstalleerd in app/vendor/git merge - en git pull - of git checkout -opdrachtencomposer update - en git pull - of git checkout -opdrachten
module.xml, beperkte functionaliteit
composer.json
Oplossingen om te vermijden
-
Combinerend Composer en
app/codevoor uw modulesResultaat in het hebben van alle nadelen van beide die stijlen van het codebeheer in uw project worden gecombineerd. Het voegt onnodige complexiteit, instabiliteit en gebrek aan flexibiliteit toe.
Bijvoorbeeld:
- Verklaar zowel de werkschema's van de Git als van de Composer (in plaats van slechts één) aan het ontwikkelingsteam.
- Installeer incompatibele modules in
app/codeomdat er niets is om dat te voorkomen. - Het verplaatsen van een module van
app/codenaar Composer (of omgekeerd) is omslachtig, vooral bij de lopende ontwikkeling.
-
Satis de Manager van het Pakket
Private Packagist kost ± 600 euro per jaar. Deze kosten zijn voor de hele GRA samen, niet per merk. Probeer deze kosten niet te vermijden door de vrije oplossing Satis te gebruiken. Uw pakketten worden niet automatisch bijgewerkt wanneer u op Vastleggen drukt. Satis heeft ook geen ingebouwde vergunning. U moet een webserver onderhouden om Satis uit te voeren. Je geeft uiteindelijk een veelvoud van de abonnementskosten voor Private Packagist door om Satis te behouden.
-
Begin met Git, dan beweging aan Composer
Maak de keus voor een benadering van het codebeheer bij het begin van uw project. Het schakelen van Git naar Composer of omgekeerd, met aan de gang zijnde ontwikkeling is omslachtig en kan tot codeverlies en of het verlies van de revisiegeschiedenis leiden.