Gerenciando Magento / Composer / Deployment

Então, estou gostando de usar o instalador do hackathon Magento Composer, mas estou lutando para entender como os outros o usam em relação a um serviço de implantação. Atualmente, estou usando o DeployHQ e, sim, posso configurá-lo para implantar e executar o compositor quando houver uma atualização no repositório, mas isso não faz sentido para mim agora.

Meu repositório principal de compositores, contendo apenas o arquivo json de todos os pacotes que quero incluir na minha compilação, só é atualizado quando adiciono um novo pacote à lista.

Quando atualizo meu tema ou extensão personalizada (que é referenciada no arquivo json), não há "gancho" para atualizar meu serviço de implantação. Portanto, tenho que fazer login no meu servidor e executar manualmente o compositor (que desativa o site até terminar).

Então, como os outros gerenciam isso? Devo executar apenas o compositor localmente e incluir a pasta do fornecedor no meu repositório?

Qualquer resposta seria muito apreciada.

Eu configurei uma estrutura em nossa agência que nos permite usar o Composer para implantar todos os nossos sites Magento. Isso pode ser um pouco exagerado para a pergunta que você fez, mas aqui está uma visão geral básica da estrutura:

Estrutura do repositório

Abaixo está a estrutura de pastas do repositório 'pai'. Ele contém o JSON do compositor e arquivos de bloqueio e outras configurações necessárias para a implementação.

- code
   - magento
- deployment
- environmental
   - local
       - local.xml
       - robots.txt
   - staging
       - local.xml
       - robots.txt
   - production
       - local.xml
       - robots.txt
- provisioning
- public
   - index.php
- vendor
- composer.json
- composer.lock

• Todas as personalizações específicas do cliente são armazenadas em um módulo "personalizações" separado que é instalado usando o Composer
• O núcleo Magento está incluído como um submódulo Git ( code/magento)
• Uma index.phppasta personalizada e outras, como mídia e erros, ficam dentro de uma pasta pública fora da raiz do Magento
• Arquivos específicos do ambiente (local.xml, robots.txt, etc.) são vinculados à raiz do Magento durante o processo de implantação
• A pasta do fornecedor é excluída do Git, mas o arquivo composer.lock está incluído.

Desdobramento, desenvolvimento

• Implementamos o uso do Capsitrano, que permite vários servidores e ambientes de aplicativos (preparação / produção)
• O Capistrano cria toda a base de código no servidor em uma nova pasta e troca o link simbólico da webroot no final, significando que não há tempo de inatividade para o seu site.
• O Capistrano é executado composer installdurante a construção e implementa todos os módulos no submódulo Magento.

Ainda não é uma configuração de integração contínua, mas acho que funciona bem para sites Magento. Sinta-se à vontade para me enviar uma mensagem se desejar mais conselhos específicos para sua configuração.

Outro método é usar a estratégia de implementação de cópia magento hackathons, que se parece com isso no seu arquivo composer.json:

"extra": {
    "magento-root-dir": "./",
    "magento-deploystrategy": "copy",
    "magento-force": true
}

O uso do método acima copia os arquivos instalados do fornecedor para a instalação real, permitindo que ele seja confirmado no Git e implantado normalmente, sem a necessidade de instalar o compositor.

Não sou muito fã de usar repositórios de terceiros quando você está prestes a fazer uma implantação ao vivo, e depender de repositórios de terceiros é meio arriscado, a menos que você tenha algum tipo de cache proxy para sua rede .

Leia este artigo e ele lhe dará uma perspectiva diferente: http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_debacle

Basicamente, o NPM foi desativado (mais ou menos ..) e os sistemas de criação de todos pararam de funcionar (para implantações críticas!) Porque dependiam diretamente do NPM. (O NPM é como o Packagist para Javascript, exceto que o NPM realmente hospeda o arquivo e o Packagist apenas aponta para os repositórios de módulos do Github - me corrija se eu estiver errado)

editar: apenas a resposta do red fschmengler. Esta é uma elaboração da sua primeira abordagem

É importante entender que o Composer não é uma ferramenta de implantação, mas uma ferramenta de desenvolvimento.

Existem diferentes abordagens sobre como preparar uma implantação com todas as dependências:

• comprometa o diretório do fornecedor (ou onde quer que o compositor instale as fontes) no repositório do projeto
• use um servidor de construção que execute composer installe crie um arquivo morto com o resultado, que você pode implantar repetível em diferentes sistemas de destino
  • corrida composer install no servidor e depois alterne os links simbólicos, conforme sugerido por @ jharrison.au, é uma variação deste

Além disso, não recomendo usar o compositor para cada módulo e apenas manter composer.jsone composer.lock no repositório do projeto. Isso está exagerando e torna o desenvolvimento desnecessariamente complicado. Faz todo o sentido o código que é reutilizado em vários projetos, mas por que você colocaria o código específico do projeto em repositórios separados?

Minha estrutura de projeto atual se parece com isso (usando os instaladores de compositores alternativos da AOE ):

• srccontém todos os módulos específicos do projeto. O Composer também instala outros módulos Magento aqui
• .modman links para src que o modman possa lidar facilmente com o link simbólico
• wwwé o webroot. O compositor instala o núcleo Magento aqui

Dessa forma, incluo módulos externos no repositório. Se você preferir não fazer isso, ajuste-o assim:

• srccontém todos os módulos específicos do projeto. Para incluí-los em.modman para que o modman crie links simbólicos, usemodman link
• .modmanestá em .gitignore. O compositor instala os módulos Magento aqui
• wwwé o webroot. O compositor instala o núcleo Magento aqui