Gerenciar módulos personalizados em várias instalações


19

Temos alguns módulos personalizados que são usados ​​para vários sites. Eles não podem ser liberados como módulos contribuídos, por exemplo, porque são específicos do cliente, fazem suposições que não funcionam para os módulos contribuídos e assim por diante.

Conheço as seguintes possibilidades para lidar com isso:

  • copie e cole-os. Torna obviamente difícil manter o módulo atualizado em todas as instalações.

  • Tenha uma única instalação multi-site, mas isso nem sempre é possível.

  • Use sub-módulos git, mas eles podem ser desagradáveis, é fácil esquecer de atualizá-los e nem sempre são suportados (por exemplo, Pantheon)

  • Drush faz scripts para fazer check-out em um repositório git comum. Para isso, você precisa usar o drush make para todo o site e não o usamos atualmente.

  • http://drupal.org/project/fserver . Ainda não tentei isso, alguém sabe se é estável o suficiente? A descrição do projeto não parece muito promissora e não existe a versão 7.x.

Mais alguma coisa / melhor? O que você prefere e por quê?


eu acho que a nova forma de fazer essas coisas é com aplicativos: drupal.org/project/apps
mojzis

Respostas:


10

A abordagem Drush make, como você já mencionou, é a versão que minha equipe está usando.

Mesmo que você atualmente não esteja usando o drush make para seus sites, deve ser relativamente simples mudar para esse fluxo de trabalho, se desejar, pois o drush também fornece drush make-generate, que gerará o arquivo make a partir de um site existente. Portanto, não é necessário sentir que vale a pena apenas para novos sites. :)


Obrigado, decidi aceitar sua resposta. Eu preciso me acostumar a fazer manufatura, descobrir como lidar melhor com isso em grandes projetos com muitos módulos personalizados e convencer meus colegas de trabalho antes que eu possa começar a usá-lo;) Você tem algum recurso sobre como manter um site, por exemplo, a melhor maneira de atualizar a versão, reconstruir um site.
Berdir

2
Como eu não tinha recursos, escrevi um :) drupal.stackexchange.com/questions/33403/… Obviamente, fique à vontade para comentar com perguntas mais profundas, se quiser. :)
Letharion

1

Se todos os sites estiverem no mesmo servidor, você poderá usar symlinkpara carregar módulos de um local central ou rsyncse estiver lidando com vários servidores.

Isso resolverá o problema de distribuição de arquivos, mas você ainda precisará disparar uma atualização. Ele pode ser automatizado drush, juntamente com um script simples que chama a atualização em todos os sites, um por um.


0

Parece que você quase parece muito com todas as soluções. Quando li isso, primeiro o que vem na minha mente suas duas outras soluções como rsyncou symlinkmas novamente não é confortável para manter.

Então, nos lembramos do módulo Git Deploy que, na verdade, é uma boa combinação com os submódulos git.

Ainda não tentei essa idéia, mas ela poderia funcionar, ou pelo menos lhe dar uma pista de como hackear para criar seu próprio sistema.


O Git deploy expõe as informações da versão dos módulos contrib, mas não temos módulos contrib, portanto, acho que não ajudaria.
Berdir

0

Eu uso um repositório git separado para todos os módulos contribuídos / personalizados, onde cada módulo contribuído ou personalizado está em uma ramificação separada (não em um submódulo).

aqui está como o merge git funciona aqui:

mestre

      <-- custom
        <-- custom module 1
        <-- custom module 2    

      <-- contrib
        <-- contrib module 1
        <-- contrib module 2     

master -> release

e um script bash / drush para atualizar as ramificações


Minha solução é baseada neste artigo nvie.com/posts/a-successful-git-branching-model
Refineo

Hum. Então, eu poderia essencialmente adicionar outro site como remoto e importar uma ramificação de módulo personalizado a partir daí. Isso poderia funcionar, mas é relativamente complexo.
Berdir

0

Em vez disso, uso o SVN Git para armazenar nossos módulos personalizados. Após confirmar a alteração do localhost, apenas executo o script bash, que executa o comando "svn update" em locais predefinidos do servidor. Sempre que implanto um módulo em um novo local, atualizo o script bash. É realmente uma configuração simples e funciona sem qualquer aborrecimento.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.