jeudi 31 décembre 2015

Un site web ASP.NET MVC 5 de A à Z - Initiation au versionning avec Git (partie 2)

Dans notre article précédent, nous avions vu comment utiliser Git dans notre projet avec Visual Studio. Cette fois-ci nous allons voir comment mettre en place une STRATEGIE DE BRANCHES : il s'agit en réalité de mettre en place un vrai processus de gestion de branches qui s'inscrit dans une optique DevOps.


Pourquoi mettre en place une stratégie de branches ?

Pour répondre à cette questions, voici d'autres questions qui font office de réponse :

  • Comment travailler à plusieurs sur le projet sans collision ?
  • Comment je sais quelle version de mon application est en production ?
  • Comment je vois l'historique de mon application ?
  • Comment je reviens à une version précédente (rollBack) ?
  • comment je fais si j'ai un bug en Production ?
  • Comment je fais pour livrer une évolution sans embarquer celle de mon collègue ?
  • Comment je récupère les évolutions de mon collègue X sans celle de mon collègue Y ?
  • Comment je travaille proprement avec des collègues qui travaillent sur le même projet depuis un autre site ou autre pays ?


Stratégie de branches avec Git

Il existe une multitude de stratégie de branches existantes et ayant fait leur preuve. Il faut cependant admettre que chaque projet à ses spécificités et il convient d'adapter sa stratégie pour faciliter au mieux le travail des développeurs/ops/testeurs.
L'exemple ci-dessous est celui que j'utilise le plus souvent :





source : http://nvie.com/posts/a-successful-git-branching-model

L'idée de ce système de branching est de "tirer" une branche pour chaque feature (fonctionnalité à développer). En plus, des branches plus "stables" doivent exister pour gérer le cycle de vie de l'application :

  • la branche master : elle sert de versionning pure des versions livrées en prod. A chaque déploiement en production, un merge doit être fait sur cette branche depuis la branche "release" ainsi qu'une apposition de tag Git qui sert d’étiquetage de la version.
  • la branche release : c'est la branche source de livraison. Une fois les devs des features terminés, on merges toutes les features branches vers la branche develop. De la branche develop, on merge vers la branche 'release' pour une MEP à venir.
  • la branche hotfixes : comme son nom l'indique, elle sert à patcher en production. Ainsi lorsqu'un bug critique/majeur apparaît en production et que l'on souhaite le corriger sans impacter les dev en cours, on utilise cette branche. un merge est alors effectué depuis la branche.
  • la branche develop : cette branche sert de merge des branches de features développé. c'est en quelque sorte la branche mère des devs en cours. Une fois les devs des features terminés, les branches de feature sont mergées vers la branche 'develop'. Une fois les 'merges' effectués, c'est de cette branche qu'on mergera vers la branche 'release'.
  • les branches de  feature : Git propose une grande souplesse en terme de branching. Ainsi, pour chaque User Storie que vous vous attribuez en début de sprint, vous pouvez tirer une branche à partir de 'develop'. Cette branche servira de développement de votre US, que vous pourrez remerger vers 'develop' une fois le développement terminé. Il arrive souvent qu'un développeur ait besoin de partager son dev avec un autre : dans ce cas, il peut merge sa branche vers 'develop' s'il estime que son développement est assez abouti et l'autre développeur pourra récuperer les modifications merger. Avec Git, un merge pourra être fait également d'une branche de 'feature' d'un développeur vers une autre branche de 'feature'.

Dans tous les cas, vous l'aurez certainement deviné, l'aspect collaboratif reste primordial. Il convient de communiquer le plus possible avec vos collègues afin de faciliter les 'merge' et la gestion de vos branches.

2 commentaires:

  1. Intéressant, mais j'ai hâte qu'on entre dans le vif du sujet

    RépondreSupprimer
  2. Ravi que vous voulez en voir d'avantage ! la suite est imminente !

    RépondreSupprimer