Flux de travail GIT pour le développement Web


12

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?


BTW, je pose cette question ici sur Programmers.SE sur la base de ceci: meta.programmers.stackexchange.com/posts/6312/revisions
jb510

Partager vos recherches aide tout le monde . Dites-nous ce que vous avez essayé et pourquoi cela n'a pas répondu à vos besoins. Cela démontre que vous avez pris le temps d'essayer de vous aider, cela nous évite de réitérer des réponses évidentes, et surtout vous aide à obtenir une réponse plus spécifique et pertinente. Voir aussi Comment demander
moucher

@gnat Je ne sais pas ce que je pourrais partager de plus à cet égard? gitflow étant tellement orienté vers la libération est encombrant. GitHub-Flow prétend être bon pour un déploiement quotidien, mais avoir des dizaines de branches en attente de fusion ressemble également au chaos. J'espérais que quelqu'un répondrait par "X est parfait pour les développeurs Web parce que Y". C'est bien couvert dans le lien que j'ai fourni, je suppose que je pourrais en extraire des citations?
jb510

1
@gnat - J'ai complètement réécrit la question pour montrer plus de recherche et être très précis sur la réponse que je cherche.
jb510

Réponses:


7

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.


2
+1, la clé de cd n'est pas git ou votre gitflow mais CI et workflow de livraison.
Wyatt Barnett

Penser BEAUCOUP à ce sujet. Merci pour la perspicacité. FWIW, j'évite spécifiquement d'utiliser le terme CI parce que nous n'utilisons pas CI. Peut-être que nous devrions, mais ce n'est pas le cas, c'est tout simplement trop lourd pour les dizaines de projets sur lesquels nous travaillons au cours d'une semaine donnée, à court terme, à long terme.
jb510

2
@ jb510 - nous avons une configuration de projet similaire, je ne rêverais pas de le piloter sans CI. Changer de contexte est beaucoup plus facile lorsque toutes les parties stupides mais fragiles sont scriptées.
Wyatt Barnett

1
Parfois, l'impossibilité d'implémenter CI facilement est un signe de combien vous avez besoin de CI sur un projet. Pas de tests unitaires? Déploiement tout manuel? Beaucoup d'étapes de déploiement fastidieuses? A besoin d'un examen.
Kzqai

1
J'ai suivi cette question et répondu au fil des ans. J'avais espéré que d'autres offriraient également des réponses, mais c'est en soi une excellente réponse, alors finalement, le marquer comme accepté (aurait probablement dû le faire il y a longtemps)
jb510
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.