Fluxo de trabalho GIT para desenvolvimento web

Há muito tempo, a pequena equipe de desenvolvedores da web com quem trabalho começou a usar o git para desenvolvimento da web. Naquela época, apenas nos comprometíamos a organizar ou dominar diretamente e depois nos fundíamos com frequência. Era melhor que nada, mas também era uma bagunça.

Há pouco tempo, adotamos o fluxo de trabalho do gitflow. Embora seja certamente melhor do que o caos que veio antes, parece um tanto complicado e excessivamente orientado para o lançamento / marco. Meus colegas desenvolvedores costumam me pedir para esclarecer como deve funcionar e o que deve se fundir e não deve. Em geral, parece inadequado para o trabalho de desenvolvimento da Web em que estamos implantando código com frequência e sem rastrear etapas específicas para o lançamento.

Em uma sugestão recente de amigos, comecei a olhar para o GitHub Flow . A leitura do post de Scott Chacon aqui atinge o ponto de dor perfeitamente com isso:

Então, por que não usamos git-flow no GitHub? Bem, a questão principal é que implantamos o tempo todo. O processo git-flow é projetado amplamente em torno do "release". Realmente não temos “lançamentos” porque implantamos na produção todos os dias - muitas vezes várias vezes ao dia.

FWIW, eu também observei esse ótimo resumo dos fluxos de trabalho no site da Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

No entanto, TODOS parecem más escolhas para o desenvolvimento da web em uma equipe pequena e voltados novamente para os principais lançamentos de aplicativos, não os lançamentos diários / frequentes.

Existe uma pergunta no SE que pede para comparar o git-flow com o github- https: //stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -fluxo

Essa é uma boa resposta em geral, mas como mencionei no meu comentário abaixo meta.programmers.SE parece indicar que as perguntas sobre as melhores práticas gerais de fluxo de trabalho pertencem a este local e eu esperava uma lista mais ampla de respostas possíveis do que apenas o git-flow e o github -fluxo, sendo específico para o desenvolvimento da web. Por isso, acho que merece uma nova pergunta aqui.

Com isso, qual você acha que é o melhor / preferido fluxo de trabalho baseado em git para uma pequena equipe de desenvolvimento da web trabalhando em projetos com implantação bastante contínua? É github-flow ou algo mais?

Primeiro, gostaria de fazer um pequeno resumo dos diferentes fluxos de trabalho em que você analisou e acha que não são adequados para o tipo de desenvolvimento em que está trabalhando:

• Centralizado ( origem ): praticamente como o fluxo de trabalho SVN, mas agora em um ambiente distribuído. Todo desenvolvedor trabalha em uma cópia pessoal mastere envia as alterações origin/masterdiretamente ou via solicitação pull.

• Ramo de recursos ( fonte ): Bem, isso. Todo desenvolvedor que trabalha em um recurso específico deve trabalhar em uma ramificação específica dedicada apenas a esse recurso. Esse ramo de recurso deve ser criado a partir de masterou de outro ramo de recurso. Eventualmente, tudo é mesclado de volta master.

• Gitflow ( fonte ): duas ramificações principais rastreiam um histórico de projeto develope master. Mais 3 ramos chamado hotfix, releasee featuremudanças hold feitas diretamente para masterpara corrigir bugs críticos de produção, número da versão mudança e outros detalhes antes de uma liberação ou trabalhar em uma característica particular como ramo de funcionalidade , respectivamente.

• Fluxo do GitHub ( Origem ): os desenvolvedores criam uma featureramificação de master. As alterações são enviadas por solicitação pull. As alterações aceitas master são implantadas imediatamente pelo bot Hubot do GitHub.

Para a parte de desenvolvimento da sua pergunta, a resposta depende do histórico da sua equipe. Eles vêm de um ambiente SVN? Você deve seguir a abordagem centralizada, pois é a que mais se assemelha ao SVN. Eles se sentem confortáveis ​​trabalhando com o Git? Talvez você não deva tentar adaptar o fluxo de trabalho de sua equipe a algum deles, mas implementar o seu próprio, criado para atender às suas necessidades que, se eu entendi bem, são flexibilidade de desenvolvimento e implantação rápida.

Eu também acho que você deve se concentrar em melhorar este último. Como é o seu pipeline de implantação ? Em " Entrega contínua: versões confiáveis ​​de software por meio da automação de compilação, teste e implantação ", os autores identificam possíveis causas para implantações pouco frequentes, algumas das quais são:

• O processo de implantação não é automatizado.
• O teste leva muito tempo.
• As pessoas não entendem o processo de compilação / teste / implantação.
• Os desenvolvedores não estão sendo disciplinados sobre como manter o aplicativo funcionando, fazendo pequenas alterações incrementais e, com tanta frequência, interrompem a funcionalidade existente

Algum desses parece algo que você poderia melhorar? Talvez você possa nos contar um pouco mais sobre como você e sua equipe lidam com essa parte do projeto.