Processo de implantação do Magento 2

Atualmente, nos comprometemos composer.lockcom o repositório e, em seguida, executamos composer install --no-devno servidor de produção. Não acho que seja a melhor maneira de fazê-lo, porque leva alguns minutos para o compositor gerar todos os arquivos e é arriscado.

Gostaria de saber se é melhor confirmar com o repositório todos os arquivos necessários para execução no modo de produção.

Como outras pessoas gerenciam o processo de implantação com o magento 2?

Concorde 100% com a claudiu-creanga em não comprometer o fornecedor e também evitar executar a instalação do compositor na produção.

A maneira como lidamos com isso é ter uma pasta ativa e uma pasta candidata a lançamento. É na pasta release-candidate que executamos os comandos git pull e a instalação do compositor --no-dev. Nosso processo pode ser resumido assim:

1. Na pasta release-candidate:

   • Verifique se há alterações inesperadas
   • Atualizar repositório
   • Instalação do compositor

2. Sincronizar arquivos para a pasta do site ativo

3. Na pasta do site ativo:
   • Implantar arquivos estáticos
   • Ativar modo de manutenção
   • Ativar módulos
   • Executar scripts de instalação
   • Compile DI
   • Limpar cache
   • Desativar modo de manutenção
   • Atualizar permissões

Eu escrevi um artigo de blog mais longo, fornecendo os comandos e o raciocínio por trás disso: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

ATUALIZAÇÃO: Agora, copiamos o banco de dados ativo para um banco de dados intermediário e o usamos para executar scripts de instalação, implantar arquivos estáticos e compilar todos os DI offline. Isso pode ser implementado para viver, incluindo arquivos pub / estáticos e var. Ainda retiramos o site brevemente se os scripts de instalação estão sendo executados, mas, caso contrário, o site é deixado para cima. Mais detalhes em https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

ATUALIZAÇÃO: Mudei de idéia sobre o envio da pasta do fornecedor. Ao confirmar a pasta, você obtém a capacidade de rastrear o histórico de como esses arquivos são alterados, ver se você mudou algo acidentalmente e, o mais importante, evitar rodar o compositor no momento da implantação. O último é vital agora que estamos contando com fornecedores externos de repositórios. E se um deles não estiver disponível? De repente, você não pode implantar. As desvantagens são um repositório maior, o risco de cometer hacks principais e o repulsão de desenvolvedores como eu :)

Até agora, também confirmamos a pasta do fornecedor, que naturalmente adiciona muitos arquivos ao seu repositório. (Certifique-se de remover qualquer pasta .git nos arquivos do compositor do fornecedor, caso contrário, o conteúdo das pastas não será confirmado - firegento por exemplo). Mas a ligação simbólica da pasta vendor não funciona, a edição do caminho no arquivo vendor_path.php também não funciona e ainda não tivemos tempo de procurar uma solução melhor.

Não temos um servidor de construção e não executamos o compositor no servidor, executamos e testamos todas as atualizações localmente e as confirmamos. Por sua vez, isso dispara nosso script de implantação.

Nosso script de implantação substitui o arquivo env.php, faz algumas coisas personalizadas e também aciona setup:upgradee setup:static-content:deployantes de mudar o link ao vivo para a nova pasta.

A única pasta em que ligamos o link é pub / media.

Por fim, optamos por um serviço como deploybot( http://deploybot.com/ ). Você pode usar o capistranoque é gratuito. O Deploybot cria um contêiner de docker enquanto a instalação do compositor está em execução e, se o comando for bem-sucedido, ele implementará o código; caso contrário, ele não implementará nada, para que seu ambiente de produção fique seguro.

Considero a melhor abordagem porque:

1) ter a pasta do fornecedor em seu repositório git não é recomendado pelos compositores por boas razões:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Mais informações: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) A execução composer install in productionsem redes de segurança é arriscada , os pacotes podem estar inoperantes (consulte a npm), você pode encontrar problemas de memória ou qualquer erro que possa estar acontecendo enquanto o compositor gera arquivos e você terá que lidar com um ambiente de produção danificado.

Também estou analisando isso, a abordagem adotada até agora é:

Inicializando o servidor:

1. Configure o projeto composer --create-project ... --no-devem uma srcpasta (embora eu ainda veja muitos itens de desenvolvimento chegando)
2. Aplicativo de instalação, compilar arquivos estáticos, atualizar db etc.
3. Defina todas as permissões corretas

O que me dará um estoque, executando a loja do meu diretório src (mas meu webroot não está apontando para lá)

Então meu processo de implantação:

1. Crie uma nova pasta de lançamento
2. rsync os arquivos src no meu release (excluindo o cruft)
3. implantar e descompactar minhas personalizações por cima (alguns arquivos e módulos de temas)
4. instalar qualquer módulo magento de terceiros através do magento connect
5. aponte meus webroot de hosts para minha nova versão (com um link simbólico)
6. graciosamente recarregar meu servidor web

Isso me permite manter o código principal do Magento separado do meu, usar o compositor para mantê-lo atualizado .. e eu não preciso enviar 39.102 !!! arquivos com cada implantação ou execute comandos do compositor no momento da implantação.

... Gostaria de ouvir outras abordagens ou as melhores práticas sobre isso, e também gosto de saber quais arquivos são realmente necessários para a produção e quais são dev .. para que eu possa manter minha raiz da web limpa.

Quando terminar, terei um manual ansible e alguns comandos do Fabric para orquestrar a configuração e a implantação, que é um prazer compartilhar.

espero que ajude