Bästa praxis för utveckling av Adobe Commerce
I det här avsnittet beskrivs baslinjen för en sund Adobe Commerce-utvecklingsprocess. Här beskrivs grundläggande processer, kodningsprinciper och principer för programdesign som vägleder utvecklarna.
NOTE
Adobe tekniska arkitekter använder dessa bästa metoder som referens vid utvecklingsarbete.
Dessa metodtips har utvecklats baserat på många års erfarenhet av att utveckla och leverera Commerce-projekt. Adobe rekommenderar att de tekniska initiativen följer dessa bästa metoder och att ni förbättrar befintliga processer och kod så att de passar dem.
Textkonventioner
Nyckelorden "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD", "SHOULD", "SHOULD NOT", "REKOMMENDED", "MAY" och "OPTIONAL" i detta ämne ska tolkas enligt beskrivningen i RFC 2119.
Process
- En definierad projektmetod MÅSTE överenskommas innan projektverksamheterna inleds. Det kan vara Scrum, Waterfall eller någon annan metod eller kombination av metoder, så länge som det definieras.
- Utvecklingen bör INTE börja förrän utvecklingsteamet har tillgång till en förgreningsstrategi för versionskontrollsystemet.
- Utvecklingen BÖR INTE börja förrän vi har godkänt tekniska specifikationer, godkänt användarberättelser och användningsexempel och godkänt testfall är tillgängliga för utvecklingsgruppen.
- Utveckling BÖR INTE påbörjas förrän minst en utvecklings- och QA-miljö finns tillgänglig.
- Projektspecifika krav som är obligatoriska för utveckling att starta kan dokumenteras i en definition av Ready.
- Godkännande BÖR utföras av en kundrepresentant som är behörig att underteckna på projektprodukter.
- I Agile-projektmetoder kan ytterligare krav uppfyllas efter signeringen. Dessa krav bör behandlas som nya krav och bör hämtas, konstrueras och planeras i enlighet med detta.
- All utveckling MÅSTE funktionstestas av utvecklaren innan den skickas in.
- All utveckling bör klara automatiska tester innan den skickas in för kodgranskning. Detta kan konfigureras som en automatiserad process efter att en pull-begäran har skapats.
- All utveckling MÅSTE genomgå manuell kodgranskning av en teknisk arkitekt eller Lead Developer innan den skickas in för kvalitetssäkring.
- All utveckling MÅSTE ge kvalitetssäkring innan den levereras till kunden.
- Projektspecifika krav som är obligatoriska för leverans kan dokumenteras i en "Definition av Klar".
Miljö
- Alla utvecklare BÖR använda samma utvecklingsmiljö. PhpStorm rekommenderas för utveckling av Adobe Commerce.
- Alla utvecklare BÖR utveckla och testa med samma teknologi som används på (framtida) produktionsservrar. Versionerna av programvaran i denna teknologi MÅSTE matcha den större och mindre versionen av programvaran som är installerad på produktionsservrarna. Mer information om den typiska teknikstacken för Adobe Commerce finns i systemkraven.
- Systemadministratören eller den tekniska arkitekten får förse teamet med en centralt underhållen lokal utvecklingsmiljö för att säkerställa och främja likartade och aktuella lokala miljöer.
- Utvecklare och QA-tekniker MÅSTE ha tillgång till kommandoraden, databasen och loggfilerna för QA-miljön. Detta kan kräva en VPN-anslutning.
Kodstandarder
- All kod ska följa konventionerna om arkitektur, metoder och kodningsstandarder. Kreativitet önskas i funktion, inte i form.
- All kod ska vara i linje med Adobe Commerce Architecture Guide.
- All kod SKA följa Adobe Commerce-kodningsstandarder.
- All kod SKA följa Adobe Commerce tekniska riktlinjer.
- All kod SKA implementera Adobe Commerce Best Practices, om tillämpligt.
- All kod BÖR följa standarden PHP-Framework Interoperability Group (FIG).
- Där det är möjligt rekommenderas att Adobe Commerce tekniska Visions beaktas.
- Alla integreringar med externa system BÖR ha integrationstester som validerar affärsprocessen.
- Alla moduler SKA ha testtäckning. Hur man testar exakt bör bestämmas av utvecklingsteamet i samarbete med den tekniska arkitekten eller den ledande utvecklaren. Detta fastställande bör bygga på kvalitativa åtgärder och inte på kvantitativa åtgärder. En hög kodsatser är inte en indikator på framgång och inte heller en hög kodkvalitet. I stället fastställa risken för att inte täcka en del av koden genom att bedöma sannolikheten för och svårighetsgraden av regressioner i den delen av programmet.
Versioner
Modulversionerna MÅSTE följa standarden Semantic Versioning 2.0.0.
Beroenden för Adobe Commerce-kodbasen BÖR följa riktlinjerna för beroende av modulversioner.
REVISIONSKONTROLL
Åtagandena MÅSTE åtföljas av meningsfulla bekräftelsemeddelanden.
Säkerhet
- Osäkra funktioner FÅR INTE användas.
- XSS-prevent-strategier SKA användas.
- Skyddsprofiler för innehåll SKA tillämpas.
- Nya Adobe Commerce-instanser bör levereras den senaste säkerhetsutgåvan av en version som ännu inte har nått datumet"Slutet av säkerhetskorrigeringen". Se Adobe Commerce livscykelpolicy för programvara.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60