Projetos GIT e estratégia de implantação Magento2

92

Com o Magento 1, usei uma ferramenta de implantação que extraía o repositório GIT, executava comandos como modman deploy-alle assegurava que o vardiretório fosse gravável. Para o que .gitignoreeu usei este que funcionou muito bem.

Mas e o Magento 2 ?

Qual gitignore funciona melhor, como você implanta seu projeto e qual comando deve ser executado antes e depois da implantação. Ansioso para ouvir algumas idéias da comunidade.

A pergunta permanecerá aberta por algum tempo

Sander Mangel
fonte
Boa pergunta @sander Mangel
Amit Bera
1
Por definição, não pode haver uma resposta canônica para isso, portanto é provavelmente muito amplo e também pouco adequado à natureza de perguntas e respostas do site. Provavelmente deve ser meta. Mas tu já sabes isto. Dito isto, permitirei até que a recompensa expire.
philwinkle
@philwinkle, pode ser amplo, mas aparentemente não muito amplo, já que já foram dadas 3 respostas. Conforme discutido aqui: meta.magento.stackexchange.com/questions/745/… O Meta deve ser usado para perguntas sobre o MageSE, não para postagens / perguntas aleatórias. Se você quiser excluí-lo, não posso impedi-lo, mas parece que as pessoas estão interessadas na questão e, na minha opinião, é válida, não sendo muito específica.
Sander Mangel
Duas coisas: Primeiro, Sander está correto sobre o Meta - ele deve ser usado apenas para perguntas sobre a plataforma SE no que se refere ao Magento SE (Nota: talvez não tenhamos policiado o Meta o suficiente para reforçar essa regra). Segundo, "muitas pessoas [interessadas] em" uma pergunta nada tem a ver com a possibilidade de uma resposta ser canônica ou não (e, portanto, com a adequação de uma pergunta ao formato StackExchange). É frustrante, com certeza (eu já enfrentei isso). Estou inclinado a ver para onde vai esse tópico de perguntas e respostas. Talvez um A possa ser declarado suficientemente bem para ser exclusivamente "correto" ...
benmarks
@benmarks nesse caso, escolhi a razão ou o assunto errado para a recompensa, minha motivação por trás disso era recompensar quem tirou um tempo para escrever uma resposta completa para isso. Se esse tópico não pertencer aqui, eu o copio e publico em algum lugar on-line, creditando os autores, pois sinto que ainda tem valor. Por favor, avise-me se antes de excluir
Sander Mangel

Respostas:

56

As etapas abaixo descrevem como configurar o ambiente para desenvolvimento de módulo personalizado, não para produção.

Inicialização do projeto

  1. Adicione credenciais repo.magento.com e token de acesso ao github para auth.json no diretório inicial do compositor
  2. Crie um projeto usando o seguinte comando:

    composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .

  3. Pegue esse .gitignore e coloque na raiz do projeto. Quase todos os arquivos / diretórios principais já foram adicionados à raiz .gitignore, mas é melhor adicionar também os 2 a seguir /updatee /phpserver(basta adicionar essas 2 linhas ao .gitignore)

  4. Inicialize o novo repositório git na raiz do projeto
  5. Adicione todos os arquivos não rastreados ao git e os confirme
  6. Comece o desenvolvimento de seus módulos como de costume (coloque-os abaixo app/code/VendorName/ModuleName), agora você terá apenas seu código personalizado em seu repositório git

Instalação Magento

  1. Verifique se todas as permissões do sistema de arquivos estão definidas conforme descrito no guia oficial
  2. Instale o Magento usando a linha de comando, por exemplo:

    ${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ [email protected] \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1

  3. Habilite o trabalho cron dos indexadores, por exemplo, no Ubuntu:

    echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -

  4. O Magento será executado no defaultmodo e todo o conteúdo ausente será gerado automaticamente após a primeira solicitação. Portanto, não há necessidade de executar o compilador ou a implantação de conteúdo estático
  5. [opcional] Se estiver usando o PHP Storm, execute o seguinte comando para ativar o suporte ao XSD:

    bin/magento dev:urn-catalog:generate .idea/misc.xml

Alex Paliarush
fonte
Oi Alex. Etapa 3 de inicialização do projeto - você poderia expandi-lo um pouco? Você achou que tinha que copiar manualmente esse subdiretório para a raiz? (Eu estou querendo saber se há algo não está funcionando corretamente - Eu não estava esperando esse passo.)
Alan Kent
Atualmente, o @AlanKent faz o download de todos os arquivos relacionados ao Magento vendor, inclusive o magento2-baseque é apenas um esqueleto para um novo projeto. Não sabe por que essa etapa não está configurada para ser executada automaticamente pelo compositor, tentará descobrir. Em relação à .gitignorecópia de outro repositório, já está sendo discutido como eliminar / simplificar esta etapa.
Alex Paliarush
Etapa 3 não é necessária. O empacotamento dos arquivos / pastas é feito durante a etapa 2.
Maddy
Obrigado @Maddy. O @AlanKent, copiar magento2-basepara a raiz não é mais necessário (apenas verificado), parece ter sido corrigido recentemente. Removida esta etapa da resposta.
Alex Paliarush
1) eu coloquei todo o meu código no repositório, já não instalado, e tudo, quando puxo esse repositório e apenas altero as configurações do pangel admin e das credenciais db, tudo funcionará corretamente? 2) desde que me esqueci de excluir a pasta var / e pub / durante o envio, posso excluí-las completamente, para que possam ser excluídas no repo remoto, elas serão regeneradas novamente? Obrigado.
Lachezar Raychev
25

Para Inicialização e Instalação, siga as etapas de Alex, sua resposta para a maioria das etapas, apenas as diferenças que eu recomendaria:

Configuração Git

Armazene apenas os seguintes arquivos no seu repositório Git:

  • compositer.json
  • compositer.lock
  • app / etc / config.php

Para o código personalizado do seu projeto, use também módulos separados que você inclui no compositor. O gerenciamento desse compositor é mais fácil, pois você pode bloquear uma versão / release específico que deseja implantar. Isso também força você a usar a mesma abordagem para módulos internos e externos.

Desdobramento, desenvolvimento

Durante o desenvolvimento, você atualiza os módulos em seu ambiente (dev / test) com o comando:

composer update

Isso atualizará o arquivo composer.lock com as versões instaladas nessa instalação.

Na preparação / pré-produção / produção, você pode criar / instalar a mesma configuração com o comando:

git pull
composer install

Isso instalará todos os mesmos módulos usados ​​no dev / test para garantir que o teste antes da publicação na produção seja realizado com as mesmas versões de módulo com as quais é desenvolvido.

Após a instalação, execute os seguintes comandos:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Isso atualizará o banco de dados (atualização de esquema e dados), gerará a configuração de DI e implementará todos os arquivos de exibição estática.

Vladimir Kerkhoff
fonte
Talvez faça sentido usar dados de amostra em vez de gerar acessórios? Os equipamentos preenchem apenas os módulos mais críticos e parecem ser úteis apenas para testes de desempenho.
Alex Paliarush
Obrigado, removemos essa parte, pois ela não é necessária ao usar um site em produção.
Vladimir Kerkhoff
Isso segue muito de perto a abordagem que estou usando também. Isso também está funcionando bem com o Magento 1 (com um processo de compilação menos complexo). Deixe o compositor fazer seu trabalho, ele funciona muito bem para implantações na minha experiência, e não vimos muitas desvantagens além das complexidades da estratégia .gitignore quando você não siga a menor pegada no git.
Aepod
Esta instalação se parece com o modo 'integrador'. Ele adiciona os repositórios em vendor / magento / *. Nenhum código estará em app / code / .. e outros diretórios. Como eu teria diretórios principais do Magento 2 como no arquivo .zip. É possível adicionar através do compositor um módulo (outro repositório git) e depois acabar em app / code / ... automaticamente?
obscuro
4
arriscado, o compositor não é uma ferramenta de implantação. se algo falhar no compositor instalar quando executando na produção ...
Claudiu Creanga
3

No .gitignore, 2.2 a resposta oficial do Magento será "config.php entra no git, o env.php não".

Estamos analisando plugins de compositores, como o Mediawiki, para aproximar o desenvolvedor interno do desenvolvimento de extensões e dos sites dos clientes. Ainda explorando, ainda não final.

Eu gostei bastante de usar o tipo de repositório Composer "Path" com um caminho ../othergitrepo/app/code/*/*para pegar módulos, mas ele usa links simbólicos que não funcionam tão bem com ambientes de desenvolvimento usando Unison ou similar.

Alan Kent
fonte
3

executamos uma abordagem diferente que não envolve um servidor / processo de compilação separados , desenvolvemos localmente como se estivéssemos em produção

em seguida, confirmamos todos os arquivos necessários para a produção . simplesmente implantamos os conjuntos de alterações no servidor e executamos o comando upgrade.

chegar a uma versão adequada para desenvolvimento, mas também executada no modo de produção, foi a parte mais complicada e ainda não é perfeita, mas agora temos uma receita que funciona.

o motivo é que queremos ter 100% de controle sobre o código que entra em produção. Como o magento2 gera uma tonelada de código, precisamos executá-lo localmente para poder entender todos os efeitos e poder depurar como se estivesse em produção.

Estou ciente de que isso não é o que muitas pessoas recomendam fazer, mas para nós funciona melhor.

etapas de configuração do frontend

Para que esses scripts funcionem, configure sua loja para o modo de produção em seu env.php e configure seu tema em dev/tools/grunt/configs/themes.js. (as etapas a seguir foram colocadas em um manual de instruções)

  1. excluir var/cache
  2. excluir var/view_preprocessed
  3. delete pub/static/*(não exclua o .htaccess)
  4. excluir var/composer_home
  5. corre php bin/magento cache:flush
  6. corre php bin/magento setup:static-content:deploy %your_languages%
  7. exclua todos os temas / idiomas que você realmente não usa de pub / static / frontend
  8. remova cópias impressas de menos arquivos do pub/static/frontend
  9. corre php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
  10. opcional: usamos um script bash para alterar os links simbólicos absolutos, criados na etapa 9, para relativos, possibilitando a execução de um grunhido de fora da vm
  11. corre grunt less:your_theme

etapas de back-end / di-setup

  1. excluir var/cache
  2. excluir var/generation
  3. excluir var/composer_home
  4. excluir var/di
  5. corre php bin/magento cache:flush
  6. corre php bin/magento setup:di:compile
greenone83
fonte
Obrigado por este @ greenone83, esta é a abordagem que basicamente adotei, embora gere meu back-end como parte do front-end. NUNCA uso setup: di: compile porque acho que estraga tudo! Uma coisa que não entendo é por que a instalação: static-content: deploy cria arquivos no código / gerado (o local foi alterado em sua postagem)? Descobri que, se eu excluir todo o código gerado /, com o meu site no modo de produção, esses arquivos serão criados automaticamente quando eu navego pelo site.
PedroKTFC
2

Você também deve ignorar esses arquivos
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

mrtuvn
fonte
2
Se você ignorar o config.php, precisará habilitar a nova extensão novamente depois de enviar para outro ambiente, portanto, é melhor incluí-la no seu repositório.
Vladimir Kerkhoff