Como gerencio o desenvolvimento colaborativo em um site Drupal?

Eu trabalho com outro desenvolvedor em um site Drupal. Temos nos esforçado para encontrar uma boa maneira de trabalhar em diferentes partes do site ao mesmo tempo, sem nos atrapalhar. Tentamos trabalhar na mesma instância de desenvolvimento do site, mas geralmente pisamos um no outro ou colocamos um código incorreto no site, impossibilitando que o outro continue trabalhando até que seja resolvido. Então, mudamos para instâncias de desenvolvimento separadas. Mas agora é uma grande dor mesclar nosso trabalho em uma única instância do site. Basicamente, acabamos refazendo tudo em uma cópia compartilhada.

O maior problema que temos agora é como mesclamos alterações no banco de dados e como incluímos o banco de dados em nosso sistema de controle de origem? Os arquivos são fáceis, basta rastrear todos (usamos git) e mesclar nosso trabalho, resolvendo conflitos quando necessário. Mas isso realmente não funciona com o banco de dados. Podemos pegar um dump SQL e incluí-lo em nosso repositório git, mas não podemos realmente mesclar os bancos de dados. O módulo Features ajuda um pouco, permitindo-nos exportar parte do nosso banco de dados para código que pode ser versionado e mesclado. No entanto, nem mesmo perto de tudo suporta Recursos. Então...

• Que etapas podemos tomar para mesclar facilmente nossas alterações no banco de dados?

• Como devemos fazer a versão do banco de dados (colocar um arquivo de despejo no git é uma boa maneira de fazê-lo)?

• Existem módulos disponíveis que ajudam com alguns desses problemas?

• Ou estamos trabalhando na mesma cópia do site? (por favor, não)

Edit: Nos comentários, discutimos o que não pode ser exportado com o Features e um deles foi Taxonomies. Há outra pergunta que lida com isso .

É uma alteração no fluxo de trabalho, mas você deve se acostumar a trabalhar em um novo despejo do banco de dados ativo. Existem três maneiras de obter alterações no banco de dados.

1. Recursos. Isso não funciona para tudo, mas para muitas coisas que você precisa.
2. ganchos de atualização. Quando os recursos não funcionam, você pode codificar as coisas em um gancho de atualização de um módulo que você possui.
3. Mudanças manuais. Use moderadamente. Algumas coisas não vêm naturalmente para os recursos ou ganchos de atualização e são muito mais fáceis de fazer manualmente. Este é o último recurso, mas às vezes é o único caminho pirático.

Se você puder. Várias vezes ao dia, obtenha um novo despejo e teste sua compilação, você deverá ter menos problemas de integração.

Respondi a uma pergunta semelhante e vou ajustá-la um pouco para responder sua pergunta aqui. Minha sugestão raiz é que você tenha um servidor de desenvolvimento / armazenamento temporário em que as alterações de código sejam verificadas usando um sistema de integração contínua com frequência (por exemplo, a cada 5 minutos). Portanto, na sua máquina local, você trabalha apenas em uma solicitação de recurso / relatório de bug de cada vez, certificando-se de delinear claramente essa tarefa de outras pessoas nas quais as pessoas possam estar trabalhando e comunicando aos colegas de equipe que você está trabalhando nela (redmine ou outro rastreamento de bugs é ótimo para isso). Em seguida, você confirma as alterações regularmente e elas são transferidas para o servidor de desenvolvimento / teste, assim como seus colegas de equipe. Idealmente, você tem testes de unidade incorporados ao seu sistema de integração contínua (recomendo o luntbuild ou o QuickBuild para isso, a propósito, mas o Hudson também funciona). O sistema ou os testes de IC podem detectar automaticamente quaisquer conflitos que você possa ter apresentado assim que você fizer o check-in do seu código. Se você precisar fazer alterações no conteúdo (sem código), faça-o no servidor de desenvolvimento / temporariedade.

Quanto à parte do banco de dados, adotei basicamente duas escolas de pensamento aqui (uma terceira escola de pensamento, fazendo diferenças de banco de dados, não discutirei porque a complexidade é bastante alta).

1) Implante eliminando o banco de dados de produção e importando um mysqldump do banco de dados de desenvolvimento. Opcionalmente, execute uma localização / substituição de regex previamente em qualquer link absoluto codificado que faça referência à URL do desenvolvedor no dump SQL. Após importar o dev db para o prod, execute automaticamente as instruções SQL (geralmente via script) posteriormente para alterar as configurações diferentes para prod do que dev (por exemplo, talvez você tenha na tabela de variáveis ​​algumas configurações de conexão para conectar-se a sistemas externos que você precisa mude para apontar para sistemas externos de prod em vez de para a versão dev).

2) Use o módulo Recursos, conforme mencionado pela budda, para configurações de administrador e use o módulo Exportação de nó para exportação / importação de conteúdo em combinação com o módulo Excluir tudo. Portanto, o fluxo de trabalho é:

use node_export e recursos para exportar nós / recursos para arquivos Opcionalmente (e espero) controle de versão Carregar arquivos no sistema prod Use a interface drush ou admin para carregar recursos Use a interface drush delete-all ou admin para excluir todos os nós dos tipos que você deseja importar Use drush ne-import ou a interface administrativa para importar os nós do arquivo que você exportou. Uma observação, eu sugeriria a adoção de um fluxo de trabalho padrão, onde o conteúdo segue apenas uma direção. Dev -> Prod ou Prod -> Dev (eu prefiro este).

Eu fiz isso e estou fazendo isso em alguns sistemas grandes, com resultados razoavelmente bons, mas sempre haverá muitas maneiras de fatiar esta maçã, escolha a maneira que funcionar melhor para você.

Embora essa seja uma pergunta antiga com uma resposta aceita, acredito que ainda há espaço para outra.

Primeiro, deixe-me dizer de antemão que eu não acho Características seja a ferramenta certa para esta tarefa e proponho um conjunto alternativo de ferramentas.

Um pré-requisito para a colaboração da equipe é ter um servidor intermediário para testar versões de desenvolvimento do projeto separadas do servidor de produção. Todo o código de desenvolvimento é testado no servidor de temporariedade e enviado apenas ao servidor de produção quando está estável e pronto para implementação. No entanto, os desenvolvedores não trabalham diretamente no servidor intermediário. Cada desenvolvedor trabalha em sua própria estação de trabalho, usando um controle de revisão e gerenciamento de código-fonte (SCM) para coordenar seu trabalho com o restante da equipe.

O sistema SCM permite que os membros da equipe trabalhem em paralelo em diferentes ramificações do código sem interferir entre si. Somente a ramificação principal é implementada no servidor intermediário para fins de teste.

Para espelhar o banco de dados entre produção, preparação e estações de trabalho, existe um módulo chamado Backup and migrate que pode ser usado se você estiver em hospedagem compartilhada e não estiver gerenciando seu próprio banco de dados. Se você está gerenciando seu próprio servidor de banco de dados, este é o único projeto nesse servidor e você usa o mysql , o seguinte par de comandos é útil:

Para despejar:

mysqldump --all-databases --opt -u root -p > DUMP.sql

Restaurar:

mysql -u root -p < DUMP.sql

Se o seu não for o único banco de dados nesse servidor, escreva alguma versão mysqldump(ou equivalente, se você não estiver usando o mysql ) que despeja apenas seus bancos de dados.

Faça uma política de que é o banco de dados no servidor de produção que é mestre. O servidor intermediário e as estações de trabalho devem ser uma cópia do banco de dados de produção, não vice-versa.

Observe que o Drupal 7 mantém todas as configurações de administrador no banco de dados. Isso significa que o espelhamento do banco de dados entre o site de produção, o site de teste e as estações de trabalho migrará as configurações de admim sem Recursos .

Agora, para compartilhar o código:

A maneira padrão de compartilhar código entre os membros de uma equipe de desenvolvimento é usar o sistema SCM. Por padrão, o Drupal é gerenciado com um sistema chamado git .

O Git permite o uso de repositórios locais ou remotos. Se os membros da equipe estiverem localizados no mesmo espaço físico, você poderá configurar um repositório local em seu servidor intermediário. Se eles estiverem espalhados geograficamente, você poderá configurar um repositório remoto. Se você não se importa que outras pessoas tenham acesso de leitura ao seu código em desenvolvimento, use uma sandbox no Drupal.org como repositório remoto. Você também pode usar uma área de projeto no GitHub . O GitHub não é apenas um repositório, mas vem com algumas ferramentas de colaboração e permite repositórios públicos e privados.

Basicamente, um sistema SCM permite que os membros da equipe retirem o código-fonte e a documentação do repositório compartilhado pelos membros da equipe e retornem novamente depois de terem trabalhado nele. O SCM controla as alterações e, se houver um conflito (por exemplo, alguém tenta enviar um código que não contenha as alterações que outro membro da equipe cometeu), ele informará e sugerirá uma maneira de resolver esse conflito.

Geralmente, com alguma comunicação cordial sobre como as tarefas são divididas entre os membros da equipe, não haverá conflitos. Mas, com o sistema SCM acompanhando as coisas, os conflitos se tornam administráveis, mesmo se forem cometidos erros ou a comunicação falhar.

Existem muitos tutoriais sobre como começar e usar o git (GIYF). Dois que eu recomendarei são: o site git-scm e o Pro Git de Scott Chacon.