Controle de versão para desenvolvimento de módulos

Estou me perguntando se existem boas convenções, no que diz respeito ao controle de versão, para o desenvolvimento de um módulo que você está usando em uma única instância do Magento e também quer lançar como um módulo da comunidade.

Inicialmente, o que tentei fazer foi usar o modman para gerenciar o módulo fora do meu repositório principal de instâncias do Magento. Mas isso acabou sendo problemático em vários níveis. Ter um repositório único que você pode instalar facilmente em diferentes ambientes ou reverter a produção é extremamente útil, e eu diria que se tornou uma parte necessária do meu fluxo de trabalho.

O que estou fazendo atualmente é desenvolvê-lo dentro do repositório do meu site e planejo dividi-lo em um repositório separado em breve. Nesse ponto, o que provavelmente vou fazer é:

• Construir no meu ambiente local em um repositório de módulo individual usando o modman
• Copiar alterações no repositório do site quando estiver pronto para implantar o código

Esperando que haja uma maneira melhor?

Temos alguns módulos em que fizemos isso e o que fizemos essencialmente é:

• Configure um repositório Git para o módulo.
• Implante este módulo na base de código do site de produção e confirme tudo, incluindo:
  • soft-links criados por modman
  • o diretório .modman que hospeda o repositório do módulo clonado
• Use o modman para "implementá-lo" em outras versões e / ou ambiente de desenvolvimento para desenvolvimento e teste.

Dessa maneira, você obtém a flexibilidade necessária para o desenvolvimento do módulo, versão do código no site único e, se você fizer alterações no módulo na base de código do site único, poderá enviá-las diretamente para o repositório do módulo, pois o repositório existe no diretório .modman.

ATUALIZAÇÃO: Quando eu escrevi isso originalmente, não considerei em minha resposta que o Git não permite que (sub) módulos sejam comprometidos com um repositório; nesse caso, "comprometer tudo" precisa de alguma elaboração!

Aliás, isso é porque eu fiz isso com mais frequência usando o modman para implantar módulos alojados nos repositórios do Git em uma base de código de produção hospedada pelo SVN… e o Subversion não tem escrúpulos que impedem o comprometimento de toda a árvore do Git no VCS.

Então aqui vai ...

1. Se você estiver usando o SVN para hospedar o código do site de produção, não deverá ter problemas, pois o Subversion não tem (praticamente) nenhum conceito de submódulo. Não vai se importar.

2. Se você estiver usando Git para o código do site de produção, terá que usar submódulos para "confirmar tudo" no repositório de códigos do site. Depois de usar o modman para clonar algo assim:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Você também deseja adicioná-lo como um submódulo da seguinte forma:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Depois de fazer isso, você poderá adicionar o diretório .modman e o arquivo .gitmodules ao índice e confirmar.

   Após a clonagem do repositório que está usando esses módulos instalados via modman, basta iniciar submodules e atualizar:

   git submodule init
   git submodule update

PS: Agora eu uso o Git em tempo integral em todos os novos projetos; espero que essa supervisão não ocorra novamente. Desculpem rapazes. ;)

Parece que a convenção atual é fornecer suporte para:

• Compositor - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Repo do Github

No que diz respeito à estrutura de diretórios, é mínimo e, de preferência, o módulo é instalado no pool de códigos da Comunidade.

Uma estrutura de diretório sugerida mínima e mínima seria:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Opcional / agradável para quem tem:

• Página de destino do Github com uma descrição, algumas capturas de tela e alguns recursos com marcadores.
• Vincular a uma loja de demonstração instalada também seria bom
• Uma visão geral de screencast / dois minutos do seu produto

Edit: Eu posso ter entendido errado.

O uso de combinações de modman / gitignore pode manter seu módulo isolado de seu ambiente de teste. Usando a estrutura de pastas acima, você pode permitir explicitamente que apenas os arquivos do seu módulo sejam confirmados / instalados no seu repositório. Nesse caso, a resposta de David é mais aplicável. O suporte de Modman para dev / deploy parece ser o consenso.

Mesmo não tendo tentado isso ainda, eu recomendaria o uso do compositor para isso.

Controle de versão, incluindo dependências

Mantendo o composer.lockarquivo no repositório, você corrige as versões de todos os módulos e sempre pode restaurar uma versão específica (uma ramificação, tag ou uma versão mais antiga) usando seu VCS ( git checkout, svn ..) e depois composer.phar install.

Desvantagens

Um problema que surge é que sua implantação pode depender facilmente de várias fontes (por exemplo, GitHub), criando vários pontos de falha.

Portanto, precisaríamos de algum tipo de cache ou proxy que armazene esses módulos para que possamos sempre implantar.

O Satis parece capaz de atender a esse propósito (consulte https://github.com/researchgate/broker ) e minha pergunta /programming//q/16211671/288568

Kalen,

Talvez eu não tenha entendido direito o seu fluxo de trabalho, mas parecia que você está desenvolvendo um repositório magento localmente e depois se separando em um repositório modman. Por que não apenas editar o arquivo ./modman/modulesname/CONTENTS no IDE e enviar o código para o repositório do módulo de forma independente no mesmo fluxo de trabalho que você usa para desenvolver. você pode usar o modman para implantar na produção, pode interagir com o repositório individual na pasta .modman / modulesname / da cli ou adicionando uma fonte de versão ao IDE, embora realmente use .basedir para manter os caminhos vinculados ao repositório fora do seu webroot vai jogar melhor.

Há também um recurso muito bom do modman que muitas pessoas parecem não usar. O script bash interpreta um arquivo .basedir no repositório .modman, se o arquivo não existir, o modman aplicará as regras de vínculo simbólico no arquivo modman no mesmo nível da pasta .modman ... se o arquivo .basedir existir, o O conteúdo descreve uma subpasta que é o nível superior do seu código Magento, descendo o caminho .modman ... em outras palavras, você pode executar (e eu faço) todas as versões básicas do Magento em pastas como 'BaseMagento1.9.1.0' 'BaseMagento1.14.2.0' e modman iniciam a pasta que os contém. Adicione um arquivo .basedir ao caminho .modman e você poderá alterar o conteúdo facilmente. Isso funciona bem para teste de versão.