Preciso levar um site ao controle de versão e configurar o ambiente de integração contínuo

Eu sou um empreendedor com um projeto Drupal 6x que começou pequeno o suficiente para não precisar de controle de versão (por desenvolvedores), mas agora estou convencido de que não há como ficar sem ele. Existe uma extensa documentação sobre o JIRA, completa com histórias de usuário bem escritas que cobrem tudo. Eu li um pouco sobre como isso poderia ser feito e criei o seguinte plano -

1. Separe o código do site do banco de dados usando módulos
   1. Contexto
   2. Recursos
   3. Braço forte
   4. perfil
2. Coloque o código em um repositório SVN e crie um site intermediário
3. Crie um espelho do servidor intermediário no servidor de produção EC2
4. Crie testes de selênio e execute-os na nuvem usando o Saucelabs
5. Crie um fluxo de trabalho de construção no JIRA Studio usando o Elastic Bamboo para executar atualizações automáticas
6. Atualize e instale perfis usando o Drush Make
7. Executar atualizações no servidor de produção (não sei como)

Para começar, fiz uma lista de cerca de 50 "Recursos", cada um com seus componentes (visualizações, tipos de conteúdo, módulos etc.). Sem dúvida, isso será desafiador, pois o site contém cerca de uma dúzia de módulos personalizados e serviços da web, além de outras dezenas de instâncias do tipo de aplicativo "aplicativo" que contém código personalizado (a maioria das quais eu gostaria de ter convertido em visualizações ou módulos atualizáveis) . O bom é que o site ainda não está em produção, portanto o risco ainda é limitado.

Alguém tem alguma experiência em fazer algo semelhante? Que armadilhas e limitações devo esperar encontrar? Agradeço imensamente quaisquer sugestões para melhorar / corrigir o plano acima, ou qualquer insight ou conselho que os especialistas lá fora possam ter para mim.

Ok, vou tentar :) Não poderei responder completamente à sua pergunta, mas talvez você tenha algumas dicas interessantes. Observe que minha numeração não está em resposta direta à sua :)

1. Como eu já mencionei no comentário, nenhum projeto é muito pequeno para o controle de versão. Eu, pessoalmente, recomendo o Git. Os motivos são a velocidade impressionante (o tempo de espera no git é medido em milissegundos, não segundos) e a enorme quantidade de recursos. Pode ser um pouco difícil de entender, por causa de nomes e argumentos estranhos, mas a documentação a seguir explica muitos deles realmente bons: http://www.eecs.harvard.edu/~cduan/technical/git/ . Outra razão é que agora é usado pelo drupal.org, portanto, conhecer o git o ajudará quando você quiser contribuir (fornecendo patches, testando patches, módulos de lançamento, ...)

2. Dito isso, se você quiser usar o SVN por algum motivo (como a integração com os serviços que planeja usar), siga em frente. O SVN também funciona razoavelmente bem e é muito melhor do que nenhum controle de origem. (A menos que você pergunte a Linus Torvalds ..). Além disso, muitas vezes há maneiras de migrar de um VCS para outro se você mudar de idéia. SVN -> Git funciona bem, por exemplo.

3. Terceiro, aborde este passo a passo. Não tente fazer tudo de uma vez. Dê a você (e seus desenvolvedores) tempo para aprender as novas ferramentas.

4. Mudar do Drupal 6 para o Drupal 7 não é algo trivial. Especialmente com muito código personalizado. Observe apenas que há muitas mudanças na API e novos conceitos (como o sistema de entidade / campo); também há o ponto de que muitos módulos contribuídos ainda não estão totalmente prontos.

5. O gerenciamento de implantação é um dos pontos fracos do Drupal, que também não mudou muito no Drupal 7. Estamos cientes do problema e as pessoas estão trabalhando duro para resolver isso no Drupal 8: http://groups.drupal.org / build-systems-change-management / cmi . Recursos etc. ajudam, mas não é uma bala de prata. Nem tudo pode ser exportado como um recurso.

6. Existem também algumas opções específicas do Drupal para implantar sites de preparação / produção. Vale a pena conferir o Pantheon (ainda em beta) e o Acquia Dev Cloud .

7. A integração contínua, o teste automatizado é importante e realmente útil, mas também requer tempo para configurar, escrever os testes e assim por diante. Tempo que você pode ou não ter neste momento. Porém, testes especialmente automatizados são uma área em que é fácil fazer melhorias incrementais. Depois de configurar um ambiente para executá-los, você pode escrever mais e mais testes conforme o tempo permitir.

Então, aqui está minha recomendação para a pergunta atualizada no comentário:

Conclua e solte como está, mas comece a usar um VCS (sistema de controle de versão) para o Drupal 6 agora. Crie um ambiente de preparação para o seu site. Veja quais módulos (contribuídos) você está usando e verifique se uma porta para o Drupal 7 é viável nesse ponto. Não subestime o tempo que levará. Comece também a melhorar o processo de teste / implantação, começando com o que você acha que trará mais benefícios / custo.

Você também pode criar perguntas de acompanhamento mais específicas ou procurar as que já existem. Como você pode ver, mesmo dando apenas algumas dicas para uma pergunta como essa pode ficar enorme e demorar um pouco.