Práticas recomendadas de desenvolvimento geral do Adobe Commerce

Este tópico descreve a linha de base para um processo de desenvolvimento saudável do Adobe Commerce. Ele descreve processos fundamentais, princípios de codificação e princípios de design de aplicativos para orientar os desenvolvedores.

NOTE
Os arquitetos técnicos da Adobe usam essas práticas recomendadas como referência durante os contratos que envolvem desenvolvimento.

Essas práticas recomendadas foram desenvolvidas com base em anos de experiência no desenvolvimento e no fornecimento de projetos do Commerce. A Adobe recomenda que as iniciativas técnicas sigam essas práticas recomendadas e que você melhore os processos e o código existentes para alinhá-los.

Convenções de texto

As palavras-chave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" neste tópico devem ser interpretadas conforme descrito em RFC 2119.

Processo

  1. Uma metodologia de projeto definida DEVE ser acordada antes do início das atividades do projeto. PODE ser Scrum, Waterfall ou qualquer outra metodologia ou combinação de metodologias, desde que esteja definida.
  2. O desenvolvimento NÃO DEVE começar até que uma estratégia de ramificação para o sistema de controle de versão esteja disponível para a equipe de desenvolvimento.
  3. O desenvolvimento NÃO DEVE começar até que as especificações técnicas, as histórias de usuários e os casos de uso sejam aprovados, e a aprovação em casos de teste esteja disponível para a equipe de desenvolvimento.
  4. O desenvolvimento NÃO DEVE começar até que pelo menos um ambiente de desenvolvimento e controle de qualidade esteja disponível.
  5. Os requisitos específicos do projeto obrigatórios para o início do desenvolvimento PODEM ser documentados em uma Definição de Pronto.
  6. A aprovação DEVE ser feita por um representante do cliente autorizado a aprovar os resultados do projeto.
  7. Nas metodologias de projetos Agile, requisitos adicionais PODEM vir após a aprovação. Esses requisitos DEVEM ser tratados como novos requisitos e DEVEM ser capturados, arquitetados e planejados de acordo.
  8. Todo o desenvolvimento DEVE ser funcionalmente testado pelo desenvolvedor antes do envio.
  9. Todo o desenvolvimento DEVE passar por testes automatizados antes de ser enviado para revisão do código. Isso PODE ser configurado como um processo automatizado após a criação da solicitação de pull.
  10. Todo o desenvolvimento DEVE passar pela revisão manual do código por um arquiteto técnico ou desenvolvedor principal antes de ser enviado para o controle de qualidade.
  11. Todo o desenvolvimento DEVE passar pela garantia de qualidade antes da entrega ao cliente.
  12. Os requisitos específicos do projeto que são obrigatórios para entrega PODEM ser documentados em uma "Definição de Concluído".

Ambiente

  1. Todos os desenvolvedores DEVEM usar o mesmo IDE. O PhpStorm é o IDE recomendado para o desenvolvimento do Adobe Commerce.
  2. Todos os desenvolvedores DEVEM desenvolver e testar usando a mesma pilha de tecnologia usada nos (futuros) servidores de produção. As versões do software nesta pilha de tecnologia DEVEM corresponder às versões principal e secundária do software instalado nos servidores de produção. Consulte requisitos do sistema para obter detalhes sobre a pilha de tecnologia típica do Adobe Commerce.
  3. O administrador do sistema ou arquiteto técnico PODE fornecer à equipe um ambiente de desenvolvimento local mantido centralmente para garantir e promover ambientes locais iguais e atualizados.
  4. Os desenvolvedores e engenheiros de controle de qualidade DEVEM ter acesso à linha de comando, ao banco de dados e aos arquivos de registro do ambiente de controle de qualidade. Isso PODE exigir uma conexão VPN.

Padrões de codificação

  1. Todos os códigos DEVEM seguir as convenções de arquitetura, metodologia e padrões de codificação. A criatividade é desejada na função, não na forma.
  2. Todos os códigos DEVEM estar de acordo com o Guia de Arquitetura do Adobe Commerce.
  3. Todos os códigos DEVEM seguir os Padrões de codificação do Adobe Commerce.
  4. Todos os códigos DEVEM seguir as Diretrizes Técnicas da Adobe Commerce.
  5. Todos os códigos DEVEM implementar as Práticas recomendadas da Adobe Commerce, se aplicável.
  6. Todo código DEVE seguir os padrões do Grupo de Interoperabilidade de PHP (FIG).
  7. Sempre que possível, é RECOMENDÁVEL considerar as Visões técnicas do Adobe Commerce.
  8. Todas as integrações com sistemas externos DEVEM ter testes de integração que validem o processo de negócios.
  9. Todos os módulos DEVEM ter cobertura de teste. O que testar exatamente DEVE ser determinado pela equipe de desenvolvimento, em colaboração com o arquiteto técnico ou o desenvolvedor principal. Essa determinação DEVE ser baseada em medidas qualitativas e não em medidas quantitativas; uma alta porcentagem de cobertura de código não é um indicador de sucesso, nem implica alta qualidade de código. Em vez disso, determine o risco de não cobrir uma parte do código avaliando a probabilidade e a gravidade das regressões nessa parte do programa.

Controle de versão

As versões de módulo DEVEM seguir o Controle de Versão Semântico 2.0.0 padrão.
As dependências na base de código do Adobe Commerce DEVEM seguir as diretrizes de Dependências de Versão de Módulo.

CONTROLE DE REVISÃO

As confirmações DEVEM ser acompanhadas por mensagens de confirmação significativas.

Segurança

  1. Funções não seguras NÃO DEVEM ser usadas.
  2. Estratégias de prevenção XSS DEVEM ser aplicadas.
  3. Políticas de Segurança de Conteúdo DEVEM ser aplicadas.
  4. As novas instâncias do Adobe Commerce DEVEM ser entregues na versão de segurança mais recente de uma versão que ainda não atingiu a data de "Fim das correções de segurança". Consulte Política de Ciclo de Vida de Software da Adobe Commerce.
recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60