Práticas recomendadas de gerenciamento de código do Adobe Commerce
Este tópico foi projetado para ajudá-lo a decidir se usará o Git ou o Composer para distribuir código personalizado, considerando o gerenciamento de versões, a complexidade do código e o gerenciamento de dependências.
Produtos e versões afetados
Todas as versõescom suporte de:
- Adobe Commerce na infraestrutura em nuvem
- Adobe Commerce no local
Definições
- Arquitetura de Referência Global (GRA): também conhecida como White Label Architecture ou Common Code Base. Esta é a arquitetura de distribuição do módulo para uma configuração de várias instâncias.
- Configuração de várias instâncias: o mesmo cliente usa instalações separadas do Adobe Commerce para regiões ou marcas separadas. Cada instalação tem módulos compartilhados e exclusivos.
- Configuração de instância única: há apenas uma instalação do Adobe Commerce. Várias cópias do código-fonte podem existir para diferentes ambientes de teste, mas há apenas uma versão do código de produção.
Quando usar o Git ou o Composer
- Abordagem padrão para gerenciar código para uma configuração de instância única
- Quando a base de código não for parte de um GRA de várias marcas no futuro
- Quando todas as marcas são executadas em uma única instância como sites
- Quando a base de código puder ou se tornará parte de uma configuração de várias instâncias no futuro
- Quando quase todos os módulos estão interligados (não recomendado)
- Quando o código é mantido por uma equipe não familiarizada com o Composer
- Abordagem padrão para gerenciar código para uma configuração de várias instâncias
- Quando o Adobe mantém a base de código ou a equipe de manutenção está familiarizada com o Composer
Matriz de recursos
Cada pacote do Composer é representado por um repositório Git
app/vendor/vendor/ se eles forem instalados por meio do marketplace ou packagist.org. Caso contrário, eles serão instalados em app/vendor/git merge e git pull ou git checkoutcomposer update e git pull ou git checkout
module.xml, funcionalidade limitada
composer.json
Soluções a serem evitadas
-
Combinando o Compositor e
app/codepara seus módulosIsso resulta na combinação de todas as desvantagens dos dois estilos de gerenciamento de código no seu projeto. Ele acrescenta complexidade desnecessária, instabilidade e falta de flexibilidade.
Por exemplo:
- Explique os fluxos de trabalho do Git e do Composer (em vez de apenas um deles) à equipe de desenvolvimento.
- Instale módulos incompatíveis no
app/code, pois não há nada em vigor que impeça isso de acontecer. - Mover um módulo do
app/codepara o Composer (ou vice-versa) é complicado, especialmente com desenvolvimento contínuo.
-
Gerenciador de Pacotes do Satis
O Private Packagist custa ± €600 por ano. Este custo é para todo o GRA combinado, não por marca. Não tente evitar esses custos usando a solução gratuita Satis. O Satis não atualiza automaticamente seus pacotes sempre que você envia confirmações para o Git. Além disso, o Satis não tem autorização incorporada. Você deve manter um servidor Web para executar o Satis. Você acaba gastando uma multidão da taxa de assinatura do Private Packagist mantendo o Satis.
-
Comece com o Git e depois vá para o Composer
Escolha uma abordagem de gerenciamento de código no início do projeto. Alternar do Git para o Composer ou vice-versa, com desenvolvimento contínuo, é complicado e pode levar à perda de código e/ou perda de histórico de revisão.