Magento2 - implantação local / temporária / de produção e gitignore

Este poderia ser um tipo de discussão mais do que uma pergunta.

Eu gostaria de saber qual política de implementação você seguir com Magento2 & locais > staging > produção ambientes

Após algumas tentativas, decidimos que a melhor (ou pelo menos a mais sólida) abordagem seria esse arquivo gitignore, incluindo a pasta vendor no git.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Portanto, executamos o compositor apenas no ambiente local: como qualquer nova extensão ou atualização de software é testada no local, validada e confirmada. Provavelmente incluiríamos também o arquivo app / etc / config.php no git, mas esse arquivo é reescrito durante a execução setup:upgrade, certo?

Incluir fornecedor significa que o tamanho do repositório será maior do que o (talvez) recomendado, mas dessa maneira, ao implantar o código, apenas executamos a sequência:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Informações relacionadas: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Veja por que escolhemos o comando compile como opcional Magento 2 - setup: di: compile ?

ATUALIZAR

A verdade é que estamos tendo alguns problemas ao implantar alterações de código em nossos projetos Magento 2 publicados

As alterações funcionam no local e na preparação (verificadas nos dois modos: desenvolvedor e produção ... embora configuremos conceitualmente esses ambientes no modo desenvolvedor), mas algumas delas não funcionam no ambiente de produção (no modo de produção), etc ... então não tenho certeza se estamos seguindo a estratégia certa. Gostaria de ver qual é a sequência de comandos apropriada e a relevância da ordem nesses comandos

De fato, todos os dias estou menos convencido sobre a utilidade do modo de produção Magento 2, a menos que você não mude nada no projeto. Você pode mudar de idéia?

De fato, todos os dias estou menos convencido sobre a utilidade do modo de produção Magento 2, a menos que você não mude nada no projeto. Você pode mudar de idéia?

Não sei se entendi direito, mas é exatamente para isso que serve o modo de produção : sistemas de produção nos quais você não altera nada (código). Até a próxima implantação, é isso.

Acho que a implantação baseada no Git que você está usando é menos adequada para o Magento 2 do que para o Magento 1, devido a todo o pré-processamento. A compilação e implantação são mais complexas e o IMHO não tem como evitar um processo automatizado de compilação

O que eu recomendaria:

• Tenha implantações repetíveis , ou seja, você deve ter certeza de que o mesmo código exato termina na produção que estava no preparo, incluindo arquivos gerados .

• Para conseguir isso, separe a construção da implantação e faça o seguinte no processo de construção:

  • composer install( vendortambém é possível adicionar ao repositório, mas se você fez isso apenas para evitar a execução do compositor no servidor durante a implantação, faça-o na etapa de compilação e mantenha-se apenas composer.lockno repositório)

  • Geração de código (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy

  • criar um arquivo (o artefato de construção ) do diretório completo Magento, excluindo mediae var, mas incluindo vendor, pub, var/generatede var/di. Começando com magento-2.2 , var/generatede var/dimovido para generated/codee generated/metadata, o que facilita separá-los do restante vardeve ser ignorado para implantações.

• Na implementação, copie o artefato de construção no servidor de destino, extraia-o para um novo diretório e:

  • ligar diretórios persistentes para ele ( media, var/session, var/log, ...)
  • ativar o modo de manutenção
  • alternar raiz do documento (geralmente o docroot é um link simbólico para a última versão, altere para a nova versão)
  • cache de descarga
  • corre setup:upgrade
  • desativar o modo de manutenção

• Esse processo de implantação pode ser facilmente implementado com o Deployer , que é como o Capistrano, mas em PHP. Uma solução de implantação completa para Magento 2 baseada em deployer pode ser encontrada aqui: https://github.com/mwr/magedeploy2 (graças ao netz98!) E aqui está outra que usamos: https://github.com/staempfli / magento2-deployment-tool

• Manter app/etc/config.phpo repositório é bom para acompanhar os módulos ativados e desativados.

Esta não é uma instrução passo a passo, mas deve fornecer uma visão geral de uma alternativa mais robusta ao seu processo atual. Dê uma olhada nas ferramentas vinculadas para ver como pode ser uma solução completa.

Na minha opinião, aguarde o Magento 2.2 ou tente implementar uma abordagem semelhante.

O Magento 2.2 introduz a implantação de pipeline, por exemplo, separando o servidor de compilação com o servidor de produção.

Aqui está a documentação oficial: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

Além disso, atualmente estou usando o Ansible para gerenciar a implantação automatizada com modelos de configuração e instalação de vários ambientes.