De bästa sätten att hantera kod för Adobe Commerce
Det här avsnittet är utformat för att hjälpa dig att avgöra om du ska använda Git eller Composer för att distribuera anpassad kod, med hänsyn till versionshantering, kodkomplexitet och beroendehantering.
Berörda produkter och versioner
- Adobe Commerce i molninfrastruktur
- Adobe Commerce lokalt
Definitioner
- Global Reference Architecture (GRA): Kallas även White Label Architecture eller Common Code Base. Detta är moduldistributionsarkitekturen för en konfiguration med flera instanser.
- Installationsprogram för flera instanser: Samma klient använder separata Adobe Commerce-installationer för separata regioner eller varumärken. Varje installation har gemensamma och unika moduler.
- Eninstansinstallation: Det finns bara en Adobe Commerce-installation. Det kan finnas flera kopior av källkoden för olika testmiljöer, men det finns bara en version av produktionskoden.
Använd Git eller Composer
- Standardmetod för att hantera kod för en enskild instansinställning
- När kodbasen inte kommer att ingå i ett GRA-avtal för flera varumärken i framtiden
- När alla varumärken körs på en enda instans som webbplatser
- När kodbasen kan eller kommer att ingå i en flerinstanskonfiguration i framtiden
- När nästan alla moduler är sammanlänkade (rekommenderas inte)
- När koden underhålls av ett team som inte är bekant med Composer
- Standardmetod för att hantera kod för en konfiguration med flera instanser
- När Adobe underhåller kodbasen eller så är gruppen som underhåller Composer bekant med den
Funktionsmatris
Varje Composer-paket representeras av en Git-databas
app/
vendor/
vendor/
om de installeras via Marketplace eller packagist.org. Annars installeras de i app/
vendor/
git merge
och git pull
eller git checkout
composer update
och git pull
eller git checkout
module.xml
, begränsad funktionalitet
composer.json
Lösningar att undvika
-
Kombinera disposition och
app/code
för dina modulerResultatet blir att alla nackdelar med båda kodhanteringsformaten kombineras i ditt projekt. Det ger onödig komplexitet, instabilitet och bristande flexibilitet.
Exempel:
- Förklara både Git- och Composer-arbetsflöden (i stället för bara ett av dem) för utvecklingsteamet.
- Installera inkompatibla moduler i
app/code
eftersom det inte finns något som kan stoppa det. - Det är besvärligt att flytta en modul från
app/code
till Composer (eller omvänt), särskilt med pågående utveckling.
-
Satis Package Manager
Privata paketeringskostnader ± 600 euro per år. Kostnaden är för hela GRA kombinerat, inte per varumärke. Undvik inte dessa kostnader genom att använda den kostnadsfria lösningen Satis. Satis uppdaterar inte automatiskt dina paket när du push-implementerar för att Git. Satis har inte heller någon inbyggd behörighet. Du måste ha en webbserver för att köra Satis. Det innebär att ni måste betala en stor mängd av den privata Packagistens prenumerationsavgift för att underhålla Satis.
-
Börja med Git och gå sedan till Composer
Välj en metod för kodhantering i början av projektet. Att byta från Git till Composer eller tvärtom, med pågående utveckling är besvärligt och kan leda till kodförlust och eller förlust av revisionshistorik.