Devops for Growth

Principe de la solution

Le coeur de la solution de build incassable que nous allons voir permet de séparer les versions partagées par les développeurs de la version stable depuis laquelle se font les mises à jour des copies de travail des développeurs.

Comme expliqué dans le premier article, avec un gestionnaire de versions décentralisé, il est possible d’imaginer toute sorte de topologie des dépôts. Nous utiliserons donc un dépôt centralisé en plus du dépôt par développeur. Ce dépôt centralisé aura de particulier de posséder une branche par développeur. Ces derniers enverront leurs modifications (push avec Git) sur leur branche personnelle sur le dépôt central (cf étape 1 du schéma). Si un développeur casse le build avec ses modifications, il ne cassera que sa branche dans le dépôt central.

Il reste encore à positionner l’Intégration Continue dans ce système, et puis c’est bien beau d’avoir sa branche personnelle, mais où sont consolidées les modifications des développeurs ? ie. où est la version de l’application qui contient l’ensemble des modifications des développeurs ?
À notre dépôt central, nous ajouterons donc une branche supplémentaire qui contiendra la consolidation de toutes les branches des développeurs. C’est l’Intégration Continue qui se chargera de merger les branches de chaque développeur vers cette branche de référence.

Les modifications de la branche de référence ne seront renvoyées par l’Intégration Continue (étape 5) que si le merge de la branche en cours de build sur la branche de référence (étape 3) et le build du résultat de ce merge (étape 4) sont validés par l’Intégration Continue.
C’est cette branche de référence sur le dépôt central qui sera la source de mise à jour de tous les développeurs (étape 7).
C’est la possibilité de partager ses modifications sur une branche et de mettre à jour sa copie de travail depuis une autre qui est particulier aux gestionnaires de version distribués.

Voyons comment se comporte ce système dans les deux situations décrites comme des limites précédemment :

• Un développeur partage des modifications qui vont faire échouer le build. Comme il les partage sur sa branche personnelle sur le dépôt central, aucun des autres développeurs n’est impacté. Ils vont en effet mettre à jour leur dépôt (et copie de travail) depuis la branche de référence qui n’est pas modifiée tant que le build du développeur n’est pas stable.
• Les autres développeurs peuvent partager leurs modifications car un build qui échoue sur une branche d’un développeur n’empêche pas d’effectuer un build des autres branches et de continuer à faire évoluer la branche de référence.

Une source supplémentaire d’échec du build apparait cependant. En effet, si un développeur partage ses modifications avant d’avoir mis à jour sa copie de travail (ou si un autre build est en cours), le build de sa branche peut échouer à cause de conflits qui apparaissent lors du merge dans la branche de référence (étape 3). Dans ce cas, il faudra au développeur mettre à jour sa copie de travail depuis la branche de référence, résoudre les conflits et renvoyer ses modifications. Le reste de l’équipe n’est pas impacté par les erreurs de merge, de la même manière qu’il n’est pas impacté par les erreurs de build.

Un dernier avantage, qui n’est pas si négligeable qu’il n’y parait, est que lorsqu’un build échoue, l’Intégration Continue « connait » de façon certaine le développeur incriminé : celui à qui appartient la branche à partir de laquelle le build a été initié. Elle peut alors notifier uniquement ce développeur et non pas tous les développeurs ayant potentiellement cassé le build comme c’est le cas aujourd’hui (ie. tous les développeurs qui ont partagé des modifications depuis le dernier build en succès). C’est un avantage non négligeable car une des raisons pour lesquelles l’Intégration Continue n’est pas très suivie est qu’elle peut générer une quantité importante de notifications pas toujours bien ciblées qui finissent par être ignorées.