DokumentationHandelImplementera spelningsbok

De bästa sätten att hantera kod för Adobe Commerce

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Skapat för:

  • Erfaren
  • Utvecklare

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.

NOTE
Dessa bästa metoder är lämpligast för migreringar och implementeringar, och mindre bra för utveckling av en enda modul.

Berörda produkter och versioner

Alla versioner som stöds av:

  • Adobe Commerce i molninfrastruktur
  • Adobe Commerce lokalt

Den omfattar både global referensarkitektur (GRA) och eninstansinstallationer.

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

Kod som huvudsakligen hanteras via Git
Kod som huvudsakligen hanteras via Composer
När används för en inställning med en instans
  • 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 används för en flerinstansinställning
  • 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

Funktion
Git
Disposition
Huvudkodarkiv
All kod finns i en enda eller några Git-databaser
All kod finns i paketen i en Composer-databas
Varje Composer-paket representeras av en Git-databas
Kodplats
Utveckling sker i katalogen app/
Utveckling sker i katalogen vendor/
Core upgrade management
Adobe Commerce Core installeras och uppgraderas med Composer och resultatet implementeras i Git
Adobe Commerce Core installeras och uppgraderas med Composer; resultatet implementeras i Git
Modulhantering från tredje part
Tredjepartsmoduler installeras i vendor/ om de installeras via Marketplace eller packagist.org. Annars installeras de i app/
Alla tredjepartsmoduler är installerade i katalogen vendor/
Utgåvor
Frisläppningen kännetecknas av kommandona git merge och git pull eller git checkout
Frisläppningen kännetecknas av kommandona composer update och git pull eller git checkout
Antal Git-databaser
Få
Många
Utvecklingskomplexitet
Enkel
Komplex
Komplexitet för pull-begäran
Enkel
Komplex
Komplexitet för kodgranskning
Enkel
Enkel
Dev/QA/UAT-miljö - uppdaterar komplexitet
Enkel
Komplex
GRA-stöd
Ja, ikon
Ja, ikon
Moduler kan installera externa bibliotek automatiskt
Ingen ikon
Ja, ikon
Flexibilitet i GRA-sammansättning
Ingen ikon
Ja, ikon
Modulberoendehantering
Ja, ikon Endast via module.xml, begränsad funktionalitet
Ja, ikon Fullständig beroendehantering via composer.json
Modulversionshantering
Ja, ikon Du kan definiera en version, men du kan inte installera en viss version
Ja, ikon Stöd för fullversion
Betalda tjänster krävs
Git-databas
Git-arkiv, privat Packagist (± 600 euro per år)
Bitbucket-integrering med Jira möjlig
Ja, ikon
Ja, ikon
Kodändringar som är direkt tillgängliga för installation
Ja, ikon
Ja, ikon

Lösningar att undvika

  1. Kombinera disposition och app/code för dina moduler

    Resultatet 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.

  2. 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.

  3. 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.

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60