Allgemeine Best Practices für die Entwicklung von Adobe Commerce
Hier wird die Grundlinie für einen gesunden Adobe Commerce-Entwicklungsprozess beschrieben. Es beschreibt grundlegende Prozesse, Kodierungsprinzipien und Grundsätze für das Anwendungsdesign, die Entwicklern als Orientierung dienen.
NOTE
Adobe Technical Architects verwenden diese Best Practices als Referenz bei Entwicklungsinteraktionen.
Diese bewährten Verfahren wurden auf der Grundlage jahrelanger Erfahrung bei der Entwicklung und Durchführung von Commerce-Projekten entwickelt. Adobe empfiehlt, dass technische Initiativen diesen Best Practices folgen und bestehende Prozesse und Code zur Anpassung an sie verbessern.
Textkonventionen
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SOULD", "SOULD NOT", "EMPFOHLEN", "MAY"und "OPTIONAL"in diesem Thema sind wie in RFC 2119 beschrieben zu interpretieren.
Prozess
- Vor Beginn der Projektaktivitäten MUSS eine definierte Projektmethodik vereinbart werden. Es kann sich um Scrum, Waterfall oder eine andere Methode oder eine Kombination von Methoden handeln, solange sie definiert ist.
- Die Entwicklung SOLLTE NICHT beginnen, bis dem Entwicklungsteam eine Verzweigungsstrategie für das Versionskontrollsystem zur Verfügung steht.
- Die Entwicklung SOLLTE NICHT beginnen, bis nach der Abmeldung von technischen Spezifikationen, der Abmeldung von Benutzermeldungen und Nutzungsszenarios und der Abmeldung von Testfällen dem Entwicklungsteam zur Verfügung stehen.
- Die Entwicklung SOLLTE NICHT beginnen, bis mindestens eine Entwicklungs- und QA-Umgebung verfügbar ist.
- Projektspezifische Anforderungen, die zum Starten der Entwicklung erforderlich sind, KÖNNEN in einer Definition von Bereit dokumentiert werden.
- Die Abmeldung SOLLTE von einem Kundenbetreuer vorgenommen werden, der zur Abmeldung von Projektlieferungen berechtigt ist.
- Bei den Agile-Projektmethoden können nach der Unterzeichnung zusätzliche Anforderungen gestellt werden. Diese Anforderungen SOLLTEN als neue Anforderungen behandelt und entsprechend erfasst, gestaltet und geplant werden.
- Die gesamte Entwicklung MUSS vom Entwickler vor der Übermittlung funktional getestet werden.
- Die gesamte Entwicklung SOLLTE automatisierte Tests bestehen, bevor sie zur Codeüberprüfung eingereicht wird. Dies kann als automatisierter Prozess nach der Erstellung von Pull-Anforderungen konfiguriert werden.
- Jede Entwicklung MUSS eine manuelle Code-Überprüfung durch einen technischen Architekten oder Lead-Entwickler bestehen, bevor sie zur Qualitätssicherung eingereicht wird.
- Alle Entwicklungen MÜSSEN vor der Lieferung an den Kunden die Qualitätssicherung bestehen.
- Projektspezifische Anforderungen, die für den Versand erforderlich sind, KÖNNEN in einer "Definition der Fertig"dokumentiert werden.
Umgebung
- Alle Entwickler sollten dieselbe IDE verwenden. PhpStorm ist die empfohlene IDE für die Adobe Commerce-Entwicklung.
- Alle Entwickler SOLLTEN den gleichen Technologiestapel entwickeln und testen wie auf den (zukünftigen) Produktionsservern. Die Versionen der Software in diesem Technologie-Stack MÜSSEN mit der Haupt- und Nebenversion der Software übereinstimmen, die auf den Produktionsservern installiert ist. Weitere Informationen zum typischen Technologiestapel für Adobe Commerce finden Sie unter Systemanforderungen .
- Der Systemadministrator oder Technische Architekt kann dem Team eine zentral gepflegte lokale Entwicklungsumgebung zur Verfügung stellen, um gleiche und aktuelle lokale Umgebungen zu gewährleisten und zu fördern.
- Entwickler und QA-Techniker MÜSSEN Zugriff auf die Befehlszeile, die Datenbank und die Protokolldateien der QA-Umgebung haben. Dies kann eine VPN-Verbindung erfordern.
Kodierungsstandards
- Sämtlicher Code SOLLTE den Konventionen in Architektur, Methodik und Kodierungsstandards entsprechen. Kreativität ist in der Funktion gewünscht, nicht in der Form.
- Der gesamte Code SOLLTE dem Adobe Commerce Architecture Guide entsprechen.
- Der gesamte Code sollte den Adobe Commerce-Kodierungsstandards entsprechen.
- Der gesamte Code sollte den technischen Adobe Commerce-Richtlinien entsprechen.
- Der gesamte Code SOLLTE gegebenenfalls die Best Practices für Adobe Commerce implementieren.
- Der gesamte Code sollte den Standards der PHP-Framework Interoperability Group (FIG) Standard entsprechen.
- Es wird empfohlen, nach Möglichkeit Technische Visionen von Adobe Commerce zu berücksichtigen.
- Alle Integrationen mit externen Systemen SOLLTEN über Integrationstests verfügen, die den Geschäftsprozess validieren.
- Alle Module SOLLTEN eine Testabdeckung haben. Was genau getestet werden soll, sollte vom Entwicklungsteam in Zusammenarbeit mit dem technischen Architekten oder Lead-Entwickler bestimmt werden. Diese Bestimmung sollte auf qualitativen und nicht quantitativen Maßnahmen beruhen; ein hoher Coderechtesatz ist weder ein Erfolgsindikator noch bedeutet er eine hohe Codequalität. Ermitteln Sie stattdessen das Risiko, einen Teil des Codes nicht zu decken, indem Sie die Wahrscheinlichkeit und die Schwere der Regressionen in diesem Teil des Programms bewerten.
Versionierung
Modulversionen MÜSSEN dem Semantic Versioning 2.0.0 standard entsprechen.
Abhängigkeiten von der Adobe Commerce-Codebasis sollten den Richtlinien für Modulversionsabhängigkeiten entsprechen.
REVISIONSKONTROLLE
Commits MÜSSEN von aussagekräftigen Commit-Nachrichten begleitet werden.
Sicherheit
- Nicht sichere Funktionen SOLLTEN NICHT verwendet werden.
- XSS-Präventionsstrategien SOLLTEN angewendet werden.
- Inhaltssicherheitsrichtlinien SOLLTEN angewendet werden.
- Neue Adobe Commerce-Instanzen SOLLTEN bei der neuesten Sicherheitsversion einer Version bereitgestellt werden, die noch nicht das Datum "Ende der Sicherheitskorrekturen"erreicht hat. Siehe Adobe Commerce-Software-Lebenszyklusrichtlinie.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60