[Nur PaaS]{class="badge informative" title="Gilt nur für Adobe Commerce in Cloud-Projekten (von Adobe verwaltete PaaS-Infrastruktur) und lokale Projekte."}

Allgemeine Best Practices zur Entwicklung für Adobe Commerce

In diesem Abschnitt werden die Grundlagen für einen reibungslosen Adobe Commerce-Entwicklungsprozess beschrieben. Es beschreibt grundlegende Prozesse, Kodierungsprinzipien und Anwendungsentwurfsprinzipien, die Entwicklerinnen und Entwicklern als Orientierungshilfe dienen.

NOTE
Technische Architekten von Adobe verwenden diese Best Practices als Referenz bei Projekten, die mit der Entwicklung in Zusammenhang stehen.

Diese Best Practices basieren auf jahrelanger Erfahrung in der Entwicklung und Bereitstellung von Commerce-Projekten. Adobe empfiehlt, dass technische Initiativen diesen Best Practices folgen und dass Sie bestehende Prozesse und den Code verbessern, um sie an diese anzupassen.

Textkonventionen

Die Schlüsselwörter „MUSS“, „DARF NICHT“, „ERFORDERLICH“, „MUSS“, „DARF NICHT“, „SOLLTE NICHT“, „SOLLTE NICHT“, „EMPFOHLEN“, „MAI“ und „OPTIONAL“ in diesem Thema sind wie in RFC 2119“ ​.

Prozess

  1. Vor Beginn der Projektaktivitäten muss eine definierte Projektmethodik vereinbart werden. Es KANN sich um Scrum, Waterfall oder eine andere Methodik oder eine Kombination von Methodiken handeln, solange sie definiert ist.
  2. Die Entwicklung SOLLTE ERST beginnen, wenn dem Entwicklungs-Team eine Verzweigungsstrategie für das Versionskontrollsystem zur Verfügung steht.
  3. Die Entwicklung SOLLTE ERST nach der Genehmigung für technische Spezifikationen, die Genehmigung für Benutzergeschichten und Anwendungsfälle und die Genehmigung für Testfälle beginnen, die dem Entwicklungs-Team zur Verfügung stehen.
  4. Die Entwicklung SOLLTE ERST beginnen, wenn mindestens eine Entwicklungs- und QS-Umgebung verfügbar ist.
  5. Projektspezifische Anforderungen, die für den Start der Entwicklung zwingend erforderlich sind, KÖNNEN in einer Definition von Bereit dokumentiert werden.
  6. Die Genehmigung SOLLTE von einem Kundenbetreuer erfolgen, der befugt ist, Projektlieferungen zu genehmigen.
  7. In agilen Projektmethoden können nach der Genehmigung zusätzliche Anforderungen folgen. Diese Anforderungen SOLLTEN als neue Anforderungen behandelt und entsprechend erfasst, architektonisch gestaltet und geplant werden.
  8. Die gesamte Entwicklung MUSS vom Entwickler vor der Übermittlung funktionell getestet werden.
  9. Alle Entwickler SOLLTEN automatisierte Tests bestehen, bevor sie zur Code-Überprüfung übermittelt werden. KANN nach der Erstellung einer Pull-Anfrage als automatisierter Prozess konfiguriert werden.
  10. Alle Entwicklungsprojekte MÜSSEN eine manuelle Code-Prüfung durch einen technischen Architekten oder einen leitenden Entwickler bestehen, bevor sie zur Qualitätssicherung eingereicht werden.
  11. Die gesamte Entwicklung MUSS vor der Lieferung an den Kunden die Qualitätssicherung bestehen.
  12. Projektspezifische Anforderungen, die für die Bereitstellung obligatorisch sind, KÖNNEN in einer „Definition von „Fertig“ dokumentiert werden.

Umgebung

  1. Alle Entwickler SOLLTEN dieselbe IDE verwenden. PhpStorm ist die empfohlene IDE für die Adobe Commerce-Entwicklung.
  2. Alle Entwickler SOLLTEN mit demselben Technologie-Stack entwickeln und testen, der auf den (zukünftigen) Produktions-Servern verwendet wird. Die Versionen der Software in diesem Technologie-Stack MÜSSEN mit der Haupt- und Nebenversion der auf den Produktions-Servern installierten Software übereinstimmen. Weitere ​ zum typischen TechnologieStack für Adobe Commerce finden Sie unter „Systemanforderungen“.
  3. 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.
  4. Entwickler und QA-Techniker MÜSSEN Zugriff auf die Befehlszeile, die Datenbank und die Protokolldateien der QS-Umgebung haben. Dies erfordert MÖGLICHERWEISE eine VPN-Verbindung.

Versionierung

Modulversionen MÜSSEN dem Standard Semantic Versioning 2.0.0“ ​.
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

  1. Nicht sichere Funktionen SOLLTEN NICHT verwendet werden.
  2. XSS-Präventionsstrategien SOLLTEN angewendet werden.
  3. Inhaltssicherheitsrichtlinien SOLLTEN angewendet werden.
  4. Neue Adobe Commerce-Instanzen SOLLTEN mit der neuesten Sicherheitsversion einer Version bereitgestellt werden, die das Datum des „Endes der Sicherheitskorrekturen“ noch nicht erreicht hat. Siehe Adobe Commerce-Software-Lebenszyklusrichtlinie.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60