La configuration : fondation du DevOps

1. Pourquoi versionner

Peut-être travaillez-vous aujourd’hui sans utiliser de gestion de configuration. Si c’est le cas, vous développez de façon continue une application sans jamais marquer de version. C’est-à-dire que vous déployez l’application quand vous pensez être prêt, puis vous l’améliorez à chaque fois que cela vous semble nécessaire, en mettant à jour l’application telle qu’elle existe en production.

Quand vous vous retournez, vous ne voyez qu’une seule application, comme si elle avait été développée d’un seul trait jusqu’à aujourd’hui.

Si vous travaillez à plusieurs, vous être obligé de séparer la propriété de chaque fichier entre chaque membre de l’équipe. Il est impossible de modifier un fichier à plusieurs, sous peine d’effacer le travail des autres, ou de créer du code incompatible avec le reste de l’application.

Pour faire simple, vous ne pouvez pas revenir en arrière, vous ne pouvez pas savoir ce que votre collègue a fait, vous ne pouvez pas contrôler ce que vous mettez en production, vous ne pouvez pas automatiser des tests sans tout retester à chaque fois, vous ne pouvez pas mesurer les possibles effets de bords d’un changement, vous ne pouvez pas procéder par dichotomie lors d’une recherche d’erreur, etc.

En réalité, plus personne, ou presque, ne peut développer un produit sans maintenir une gestion de configuration.

La gestion de la configuration est scindée en deux activités très complémentaires, pour ne pas dire indissociables :

1. Les principes de base

Travailler avec des branches de code

Versionner, c’est chercher à maîtriser l’état d’une application pour le reproduire à chaque instant. Chaque état est le fait d’un changement dans le code de l’application. Ces changements sont "publiés" dans la base de code, on parle alors de "commit".

On peut donc définir un état comme le résultat d’une succession d’autres états passés. Cette liste d’états successifs forme la base de code, ou "mainline". On utilise aussi le terme de tronc (trunk), ou maître (master). Cette sémantique multiple est troublante, mais elle désigne la même chose.

Le dernier état de la base de code est appelé la tête. Il correspond à l’état de l’application lors de la dernière publication d’un changement.

Cette base de code est intéressante si l’on est le seul développeur d’une application. On peut effectivement dire qu’il est possible de récupérer un état quelconque de l’application à partir de cette ligne principale."

Mais évidemment l’un des objectifs essentiels du versionnage est de pouvoir travailler en équipe sans défaire le travail de ses collègues, et en évitant de créer des anomalies par des incohérences de code.

Chaque membre de l’équipe va donc travailler sur une ligne de code qui lui est dédiée. On appelle cette nouvelle ligne de code une branche. En créant une branche, on isole une version de l’application dans un état donné et on lui donne un cycle de vie spécifique, pour un temps plus ou moins court (ou plus ou moins long selon la stratégie...