Depois de ler sua pergunta, acho que o que você está procurando está mais de acordo com um conjunto de ferramentas de implantação do que com uma configuração de desenvolvimento. Independentemente da direção escolhida, acho que a primeira coisa que você precisa fazer é obter todo o código no controle de origem . Você não pode razoavelmente ter nenhum sistema confiável para implantação sem poder versionar todos os sub-serviços. Colocar todos os projetos em um servidor SVN é bom; você precisaria de um projeto massivamente grande para superar uma abordagem de servidor único e fornecer a capacidade de ramificar / marcar facilmente uma versão em todos os subprojetos com facilidade.
Recomendo ver ferramentas criadas especificamente para implantação, como o Capistrano , Fabric , ou ControlTier . Cada projeto tem seus pontos strongs e fracos (Capistrano funciona bem com Rails, ControlTier com Java, etc.) e você provavelmente encontrará a melhor ferramenta depende da linguagem em que seus subprojetos são escritos. Algumas razões para preferir um sistema de implementação um simples gancho de pós-commit:
- Não é difícil escrever alguns scripts que executam um "svn up" em um determinado diretório em um punhado de servidores, mas os sistemas de implantação tratam de coisas como ambientes de preparação versus produção, reversões de implantações com falha, etc.
- A implantação deve ser uma etapa separada do código de check-in. Muitas vezes, prefiro implantar em uma determinada hora do dia (digamos, no meio da manhã, quando o suporte de engenharia provavelmente está disponível ou no meio de a noite em que o tráfego do site está próximo do ponto mais baixo) e os desenvolvedores devem ter a liberdade de verificar o código que não necessariamente resulta em uma implantação. Se você tiver sistemas de integração contínua em vigor, você deseja que seu código seja testado / verificado antes de ser implantado. Muito disso pode ser feito fazendo com que o gancho post-commit inspecione o caminho dos arquivos confirmados e implemente somente se forem feitas alterações em uma ramificação de release.
- O processo de implantação em si deve ser documentado, repetido e controlado por versão. Existem razões legítimas para reimplantar a mesma versão (por exemplo, adicionar mais servidores à sua configuração) que não devem Exigir um falso commit ao controle de origem apenas para iniciar outra compilação. Além disso, gosto de ter as etapas necessárias para implantar disponíveis e visíveis para os desenvolvedores. O Capistrano é ótimo para isso, já que você está literalmente verificando um arquivo para o controle de origem que descreve como executar uma implantação. Se você está apenas usando um gancho post-commit, certifique-se de que ele tenha um backup junto com os dados do próprio repositório SVN!
A segurança será amplamente ditada pelos requisitos de negócios. Em lojas menores, não vejo nada de errado em dar aos desenvolvedores "chaves para o castelo" e até mesmo rodar as tarefas de implantação entre a equipe. Se você trabalha em um ambiente onde os desenvolvedores não podem acessar os dados de produção, você precisará criar um sistema em que eles possam acionar uma implantação (por meio de um check-in ou de algum outro processo), mas não possam acessar a autenticação do próprio sistema de implantação. Se você estiver executando em uma plataforma UNIX, isso pode ser tão simples quanto gerando chaves SSH para implantação, e dando apenas as chaves para os responsáveis pela implantação.