Discussion :

[dorian53]

Bonjour,

Quels sont les avantages et inconvénients de ces deux workflow ?

Workflow 1 (+tags)

master
hotfix
release
develop
features-*

Workflow 2
master
5.2
5.1
4.7
4.6
...

Dans quel contexte préférez l'un plus que l'autre ?
Le workflow 1 est-il réservé au développement d'un projet et le workflow 2 davantage à une librairie ?
À quoi sert master dans le workflow 2 (rien, présent par obligation, une branche develop...) ?

Merci,
Dorian

[Marco46]

C'est une très importante question mais c'est une conséquence d'une encore plus importante, j'y viens par la suite.

Le premier workflow que tu décris ressemblerais à s'y méprendre au gitflow. C'est le plus connu des vieux workflow git, avant que la vague devops n'arrive. Il est lourd et présente certains désavantages, comme l'existence d'une seule ligne de développement (develop), et l'existence d'une branche master censée représenter la prod ce qui n'a absolument aucun sens avec git puisque c'est le rôle des tags et non des branches que de représenter un déploiement (peu importe l'environnement). Cette branche ne sert donc à rien et est une terrible source de confusion et de débats chez les développeurs. C'est bien pour débuter avec git, mais c'est pas terrible.

Un workflow intermédiaire, une sorte de gitflow advanced serait de faire :

release
develop
features-*

En traitant les hotfix dans les releases. Il suffit de tirer des branches de release pour les hotfix depuis les tags déployés et pour les features depuis develop. Mais là aussi une seule ligne de développement.
Develop peut être déployé en continuous déploiement dans un environnement de développement (je préfère le terme d'assemblage), c'est à dire qu'à chaque commit mergé dans develop l'intégration continue déploie une nouvelle version de l'appli identifiée par le sha1 du commit et non par un tag.

Le déploiement dans autre environnement se fait sur la base des releases et des tags associés.

Le deuxième worfklow ressemble à du trunk base development ou du simple git flow.

L'idée sous-jacente est que tout ce qui est mergé dans master est déployable, peu importe l'environnement. Cela nécessite de mettre en place du feature flipping (ou feature toggle selon les appellations). Tu peux donc avoir une pipeline où quand tu décides de déployer dans un environnement tu crées un tag sur le commit voulu de master et tu déploies ce tag. Ça nécessite un très important outillage autour pour gérer les configurations des environnements ce qui peut être géré manuellement avec le gitflow. Le niveau moyen des devs doit également être plus important et plus homogène qu'avec le gitflow qui permet quand même de gérer plus facilement les juniors, mais ça scale pas.


Voilà pour les commentaires sur les workflows.

Maintenant la question est de savoir quel est le process de livraison dans ton organisation. Est-ce qu'il y a une QA manuelle ? Des phases de validation par d'autres personnes (métier, chef de projet, directeur quelconque) ? De même, est-ce que les dev et les ops sont séparés ? Qui gère la prod ? Qu'elle est la fréquence de déploiement ? C'est cadré à n livraisons par an ? A chaque fin de sprints SCRUM ? Ou bien c'est ASAP ?

Autre question, y-a-t-il plusieurs équipes différentes qui travaillent en concurrence sur la même base de source ? Si la réponse à cette question est oui, alors tu ne peux pas utiliser le gitflow (workflow 1) sans y apporter des améliorations importantes. Dans ce cas un workflow basé sur du feature flipping est plus intéressant (on merge le plus souvent possible pour simplifier la gestion du SCM au prix d'une complexité applicative plus importante).

Toutes ces questions déterminent si tu vas faire du continuous delivery (je livre un tag donné à une date donnée dans un environnement donné) ou du continuous deployment (je merge dans ma seule branche de collaboration et la pipeline automatise tous les process de livraisons, avec dans le cas extrême une livraison en prod automatisée).

Ton worflow git doit venir s'insérer dans ton organisation pour en devenir un rouage, il ne peut pas être "hors-sols".

A mon avis, plus la taille du projet augmente, et la taille des équipes avec, et plus il est intéressant de se diriger vers du trunk based development. Enfin pour des applications de gestion n-tiers classiques. Pour de la dépendance tu es obligé de faire du continuous delivery (livrer un périmètre précis à une date donnée), ça n'aurait pas de sens de livrer 5 versions par semaines d'une dépendance. Le noyau linux est un bon exemple des contraintes liées à être une dépendance des autres, c'est un projet énorme mais ils vont du delivery avec Linus Torvalds qui joue le rôle de gate keeper en construisant la future version. A contrario les grosses plateformes type Amazon ou Google livrent leurs produits web le plus souvent possible, Amazon livre une nouvelle version de son magasin online plusieurs fois par jour.