Flux de travail GIT pour le développement Web

Il y a longtemps, la petite équipe de développeurs Web avec laquelle je travaille a commencé à utiliser git pour le développement Web. À l'époque, nous nous étions simplement engagés à mettre en scène ou à maîtriser directement, puis à fusionner fréquemment entre les deux. C'était mieux que rien, mais c'était aussi un gâchis.

Il n'y a pas si longtemps, nous avons adopté le flux de travail gitflow. Bien qu'il soit certainement meilleur que le chaos qui l'a précédé, il semble quelque peu lourd et excessivement orienté vers la sortie / le jalon. Mes collègues développeurs me demandent souvent de clarifier comment cela est censé fonctionner et ce qui devrait fusionner ou non. En général, il semble peu adapté aux travaux de développement Web où nous déployons du code fréquemment et sans suivre les étapes spécifiques de la publication.

Sur une suggestion récente d'un ami, j'ai commencé à regarder GitHub Flow . La lecture du post de Scott Chacon ici frappe parfaitement le problème avec ceci:

Alors, pourquoi n'utilisons-nous pas git-flow sur GitHub? Eh bien, le principal problème est que nous déployons tout le temps. Le processus git-flow est conçu en grande partie autour de la «version». Nous n'avons pas vraiment de «versions» car nous déployons en production tous les jours - souvent plusieurs fois par jour.

FWIW, j'ai également regardé cette belle série de workflows sur le site d'Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Cependant, ils ressemblent TOUS à de mauvais choix pour le développement Web dans une petite équipe et sont à nouveau orientés vers les versions majeures des applications, non fréquentes / quotidiennes.

C'est une question sur SE demandant de comparer git-flow à github-flux /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -couler

C'est une bonne réponse en général, mais comme je l'ai mentionné dans mon commentaire ci-dessous, meta.programmers.SE semble indiquer que les questions sur les meilleures pratiques générales de workflow appartiennent ici et j'espérais une liste plus large de réponses possibles que juste git-flow et github -flow, tout en étant spécifique au développement web. Par conséquent, je pense que cela mérite une nouvelle question ici.

Avec cela, quel est selon vous le meilleur workflow basé sur git pour une petite équipe de développement web travaillant sur des projets avec un déploiement assez continu? Est-ce que c'est github-flow ou autre chose?

J'aimerais d'abord faire un petit résumé des différents workflows que vous avez examinés et que vous pensez ne pas convenir au type de développement sur lequel vous travaillez:

• Centralisé ( source ): à peu près comme le flux de travail SVN mais maintenant sur un environnement distribué. Chaque développeur travaille sur une copie personnelle de masteret pousse les modifications origin/masterdirectement ou via une demande de tirage.

• Branche de fonctionnalité ( Source ): Eh bien, ça. Chaque développeur travaillant sur une fonctionnalité particulière doit travailler sur une branche spécifique dédiée à cette fonctionnalité uniquement. Cette branche de fonctionnalité doit être créée à partir masterou à partir d'une autre branche de fonctionnalité. Finalement, tout est fusionné master.

• Gitflow ( Source ): deux branches principales suivent l'historique d'un projet, developet master. 3 autres branches appelées hotfix, releaseet featuredétiennent les modifications apportées directement masterpour corriger les bugs de production critiques, numéro de changement de version et d' autres détails avant une libération ou le travail sur une caractéristique particulière , tout comme la branche de fonction , respectivement.

• Flux GitHub ( source ): les développeurs créent une featurebranche hors de master. Les modifications sont poussées via la demande de tirage. Les modifications acceptées master sont immédiatement déployées par le bot Hubit de GitHub.

Pour la partie développement de votre question, la réponse dépend du parcours de votre équipe. Proviennent-ils d'un environnement SVN? Ensuite, vous devriez opter pour l'approche centralisée car c'est celle qui ressemble le plus à SVN. Se sentent-ils à l'aise de travailler avec Git? Alors peut-être que vous ne devriez pas essayer d'adapter le flux de travail de votre équipe à l'un d'eux, mais mettre en œuvre le vôtre, conçu pour répondre à vos besoins qui, si je comprends bien, sont la flexibilité du développement et le déploiement rapide.

Je pense également que vous devriez vous concentrer sur l'amélioration de ce dernier. Comment se compose votre pipeline de déploiement ? Dans « Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation », les auteurs identifient les causes possibles des déploiements peu fréquents, dont certains sont:

• Le processus de déploiement n'est pas automatisé.
• Les tests prennent beaucoup de temps.
• Les gens ne comprennent pas le processus de génération / test / déploiement.
• Les développeurs ne sont pas disciplinés pour maintenir l'application en fonctionnement en apportant de petites modifications incrémentielles, et donc interrompent fréquemment les fonctionnalités existantes.

Est-ce que certains de ces sons semblent pouvoir être améliorés? Peut-être pourriez-vous nous en dire un peu plus sur la façon dont vous et votre équipe gérez cette partie du projet.