Best practice generali di sviluppo per Adobe Commerce
Questo argomento descrive la linea di base per un processo di sviluppo Adobe Commerce efficiente. Descrive i processi fondamentali, i principi di codifica e i principi di progettazione delle applicazioni per guidare gli sviluppatori.
NOTE
Gli architetti tecnici Adobi utilizzano queste best practice come riferimento durante gli impegni che coinvolgono lo sviluppo.
Queste best practice sono state sviluppate sulla base di anni di esperienza nello sviluppo e nella distribuzione di progetti Commerce. L’Adobe consiglia di seguire queste best practice nelle iniziative tecniche e di migliorare i processi e il codice esistenti per allinearli.
Convenzioni testo
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDATIONS", "MAY" e "OPTIONAL" in questo argomento devono essere interpretate come descritto in RFC 2119.
Processo
- Prima di avviare le attività del progetto, DEVE essere concordata una metodologia di progetto definita. Può essere Scrum, Waterfall, o qualsiasi altra metodologia o combinazione di metodologie, purché sia definita.
- LO SVILUPPO NON DEVE INIZIARE FINCHÉ non sarà disponibile per il team di sviluppo una strategia di ramificazione per il sistema di controllo delle versioni.
- LO SVILUPPO NON DEVE INIZIARE FINCHÉ non siano state approvate le specifiche tecniche, approvate le storie degli utenti e i casi d’uso e il team di sviluppo non avrà avuto a disposizione l’approvazione dei casi di test.
- LO SVILUPPO NON DEVE INIZIARE finché non sia disponibile almeno un ambiente di sviluppo e di controllo qualità.
- I requisiti specifici del progetto obbligatori per l'avvio dello sviluppo possono essere documentati in una Definizione di Pronto.
- L’approvazione DEVE essere effettuata da un rappresentante del cliente autorizzato a firmare i risultati finali del progetto.
- Nelle metodologie di progetto Agile, requisiti aggiuntivi POSSONO seguire l’approvazione. Questi requisiti DEVONO essere trattati come nuovi requisiti e DEVONO essere acquisiti, progettati e pianificati di conseguenza.
- Tutti gli sviluppi DEVONO essere testati dal punto di vista funzionale dallo sviluppatore prima dell’invio.
- Tutti gli sviluppi DEVONO superare test automatizzati prima di essere inviati per la revisione del codice. PUÒ essere configurato come processo automatizzato dopo la creazione della richiesta di pull.
- Tutti gli sviluppi DEVONO superare l'esame manuale del codice da parte di un architetto tecnico o di un lead develeloper prima che venga inviato per il controllo qualità.
- Tutti gli sviluppi DEVONO superare il controllo qualità prima della consegna al cliente.
- I requisiti specifici del progetto che sono obbligatori per la consegna POSSONO essere documentati in una "Definizione di completato".
Ambiente
- Tutti gli sviluppatori DEVONO utilizzare lo stesso IDE. PhpStorm è l’IDE consigliato per lo sviluppo Adobe Commerce.
- Tutti gli sviluppatori DEVONO sviluppare e testare utilizzando lo stesso stack di tecnologia utilizzato sui (futuri) server di produzione. Le versioni del software in questo stack di tecnologia DEVONO corrispondere alla versione principale e alla versione secondaria del software installato sui server di produzione. Consulta requisiti di sistema per informazioni dettagliate sullo stack tecnologico tipico di Adobe Commerce.
- L’amministratore di sistema o l’architetto tecnico PUÒ fornire al team un ambiente di sviluppo locale gestito a livello centrale per garantire e promuovere ambienti locali uguali e aggiornati.
- Sviluppatori e ingegneri QA DEVONO avere accesso alla riga di comando, al database e ai file di registro dell’ambiente QA. Potrebbe essere necessaria una connessione VPN.
Norme di codifica
- Tutto il codice DEVE seguire le convenzioni degli standard di architettura, metodologia e codifica. La creatività è desiderata nella funzione, non nella forma.
- Tutto il codice deve essere conforme alla Guida all'architettura di Adobe Commerce.
- Tutto il codice deve rispettare i Standard di codifica Adobe Commerce.
- Tutto il codice deve rispettare le linee guida tecniche di Adobe Commerce.
- Tutto il codice DEVE implementare le Best practice per Adobe Commerce, se applicabili.
- Tutto il codice DEVE rispettare gli standard PHP-Framework Interoperability Group (FIG).
- Ove possibile, si consiglia di prendere in considerazione Visioni tecniche di Adobe Commerce.
- Tutte le integrazioni con sistemi esterni DEVONO disporre di test di integrazione che convalidano il processo aziendale.
- Tutti i moduli DEVONO avere copertura di test. Cosa verificare esattamente DEVE essere determinato dal team di sviluppo in collaborazione con l’architetto tecnico o lo sviluppatore principale. Tale determinazione DOVREBBE basarsi su misure qualitative e non su misure quantitative; una percentuale elevata di copertura del codice non è un indicatore di successo né implica un'elevata qualità del codice. Determinare piuttosto il rischio di non coprire una parte del codice valutando la probabilità e la gravità delle regressioni in tale parte del programma.
Controllo delle versioni
Le versioni del modulo DEVONO rispettare lo standard Controllo delle versioni semantiche 2.0.0.
Le dipendenze nella base di codice di Adobe Commerce DEVONO seguire le linee guida sulle dipendenze della versione del modulo.
CONTROLLO DELLE REVISIONI
I commit DEVONO essere accompagnati da messaggi di commit significativi.
Sicurezza
- FUNZIONI non sicure NON DEVONO essere utilizzate.
- È necessario applicare strategie di prevenzione XSS.
- È necessario applicare Criteri di sicurezza dei contenuti.
- Le nuove istanze di Adobe Commerce DEVONO essere consegnate all’ultima versione di sicurezza di una versione che non ha ancora raggiunto la data di "Fine delle correzioni di sicurezza". Consulta Adobe Commerce Software Lifecycle Policy.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60