Se um projeto vagrant for seu próprio repo

3

Então, eu tenho trabalhado com o Vagrant e acho excelente, mas estou imaginando qual é o melhor ou mais comum uso dele

Eu imagino que haja duas maneiras de usá-lo: O primeiro seria criar um tipo de master repo que contenha os scripts de informações e fantoches do Vagrant para o ambiente de desenvolvimento dessa organização. Isso teria o benefício de poder haver vários repositórios que o usam de maneira comum.

O segundo seria criar um arquivo vagrant por projeto que reflita esse projeto em particular.

A segunda parece ser a maneira que eu tentaria e estruturaria as coisas, mas estou me perguntando se há armadilhas com essa abordagem.

    
por Mr Wilde 03.04.2014 / 20:49

1 resposta

0

Essa é uma pergunta meio carregada, mas eu realmente odeio quando as pessoas permanecem super vagas e tentam soar todas inteligentes sobre um tópico, então vou tentar escrever meu plano com alguns pensamentos. Isso realmente depende se você está trabalhando em vários tipos diferentes de servidores ou apenas em um único tipo. Além disso, se você está mexendo com o provisionamento por algum motivo ou outro, isso pode aumentar a necessidade de uma base por projeto.

Para mim? Eu gosto de coisas em modelos: código, vida, orçamentos, listas de compras, frigideiras, etc. Eu sou engenheiro e gosto de coisas abstratas e generalizadas que são reutilizáveis e extensíveis .. Então, para vagrant, eu quero um vagrant primário projeto repo com a ferramenta de provisionamento que eu prefiro (fantoche). Eu teria versões diferentes deste abstratas e generalizadas como eu entendesse por projeto. Se minha empresa fizesse centenas de sites wordpress, eu faria uma configuração padrão que inicializasse um servidor e instalei a versão mais recente (ou x) do wordpress, e similar para quaisquer outros projetos que não sejam raridades (Symfony, RoR, Laravel) , nó).

Ao iniciar um novo projeto, você deve inicializar o novo repositório para o seu projeto e, em seguida, adicionar submódulo para o projeto vagrant generalizado mais próximo para suas necessidades. Os desenvolvedores poderiam, então, editar o submódulo vagante, e não enviar alterações, ou enviar alterações se fossem grandes o suficiente para exigir atualização.

Eu tenho certeza de que os desenvolvedores que tiveram a necessidade de atualizar seu repositório vagante fizeram isso criando uma nova ramificação. Eu teria git hooks nos repositórios vagrant que notificavam os principais desenvolvedores de mudanças, para que eles pudessem revisar e determinar as etapas necessárias para abstrair os projetos. Podemos criar um novo repositório vagrant baseado nas alterações para este projeto específico? É importante o suficiente?

Esse fluxo deve garantir que possamos ter controle de nosso histórico de git com o objetivo de revisar projetos no futuro para determinar sua configuração "base" de vagrant, nos permite atualizar e corrigir facilmente quaisquer bugs existentes em nossos projetos base vagrant e permite que todos os projetos consigam atualizar facilmente o submódulo do vagrant sem afetar o código do projeto.

De qualquer forma, essa é a minha ideia de como pretendo fazê-lo, se alguma vez chegar a essa conclusão.

    
por 05.04.2014 / 10:00

Tags