DevOoops : des conflits dans la gestion de configuration logicielle

La gestion de configuration logicielle, ou SCM, software configuration management, représente l’un des plus grands défis DevOps. Au début de ma carrière, l’idée de donner accès à des référentiels Git n’était absolument pas rassurante.

Ma principale erreur « DevOoops » remonte à l’époque où j’essayais de maîtriser les fondamentaux de Git sur un projet impliquant des sous-modules Git. Il comportait une série de scripts Bash qui implémentaient un workflow primitif d’intégration et de livraison continues en s’exécutant dans les environnements sur lesquels nous les déployions (oui, vraiment). Le nombre de conflits était alors énorme, et je ne vous raconte pas comment il a été difficile de solutionner celai. Heureusement, nous utilisions le modèle « fork-Pull Request » qui m’a permis de limiter les dégâts.

La gestion de configuration logicielle (SCM) est essentielle, non seulement pour l’évolution des versions, mais également pour partager la visibilité sur le code et d’autres ressources, depuis le développement jusqu’à la phase de production. En accordant toute l’attention nécessaire à la structure SCM, aux modèles de fusion et de branches, aux contrôles d’accès, etc., l’entreprise réunit les ingrédients du succès DevOps, à savoir : la collaboration, la fiabilité et la traçabilité.

Dans l’étude 2019 de la communauté Jenkins et du DevOps, 66 % des entreprises sondées ont indiqué utiliser des solutions modernes de SCM, et plus particulièrement fondées sur Git, telles que GitHub ou BitBucket. Cependant, les plus anciennes n’ont pas totalement été abandonnées : 45 % de l’ensemble des entreprises continuent d’en utiliser des antérieurs à Git et aux systèmes de contrôle des versions distribué comme Perforce, Subversion et CVS. Bien que l’utilisation DevOps soit compatible avec ce type d’anciennes solutions, il est important (bien que complexe) de concevoir un modèle de fusion et de branche, ainsi qu’un workflow environnant soutenant les aspects DevOps fondamentaux, comme l’évaluation par les pairs, la collaboration et la durée de vie limitée des branches.

Les solutions modernes de SCM telles que GitHub proposent des fonctionnalités qui soutiennent la collaboration de façon inhérente, à l’instar des révolutionnaires Pull Requests ; simplifient le déploiement et favorisent la livraison continue et DevOps.

Des workflows de livraison continue mal conçus ou des systèmes de livraison continue inadéquats peuvent générer plusieurs types de conflits. Si les interactions sont trop laborieuses, les utilisateurs n’enverront pas assez souvent leur code dans le pipeline. S’il est difficile d’accéder au pipeline et d’assurer la visibilité sur le processus, cela peut également favoriser les conflits non résolus.

Il est primordial de choisir le bon outil. Si l’entreprise n’a pas la possibilité de se procurer un outil moderne, il reste nécessaire d’adapter l’existant.

Deux autres questions liées à cet exemple de DevOoops méritent également une attention particulière : celles des branches et de l’acquisition des compétences DevOps adéquates.

  • La gestion des branches : Un bon modèle de fusion et de branches est nécessaire pour garantir que les bonnes informations soient intégrées au pipeline DevOps, de sorte que l’intégration continue soit possible ainsi que les tests et le déploiement des modifications. Le meilleur conseil en la matière repose sur le principe KISS (keep it simple, stupid) Si l’entreprise a besoin d’un tableau ou d’une feuille de calcul entière pour qu’un comptable puisse répertorier toutes ses branches actives, elle devra revoir son système. Il est nécessaire de sa rapprocher au maximum d’un idéal de développement à branche unique, avec des branches ayant une courte durée de vie, des versions d’application minimales, etc.
  • L’acquisition des compétences : Tandis que les entreprises cherchent à adopter une approche DevOps, il est très probable que de nouveaux outils et pratiques surgissent simultanément. Il est important de le comprendre et de se faire à l’idée que l’apprentissage ne se fera pas sans quelques heurts. Par exemple, le fait de passer d’un contrôle des versions centralisé, comme avec Apache Subversion (SVN), à un contrôle des versions distribué, comme avec Git, est un paradigme qui peut être difficile à appréhender et qui peut conduire à des conflits critiques, comme la suppression de nœuds de l’historique des modifications, l’écrasement de changements ou la mauvaise configuration du contrôle des accès. L’entreprise doit alors envisager de recruter du personnel possédant ces nouvelles compétences et/ou prévoir du temps pour former ses équipes.

Si une entreprise utilise une ancienne solution de SCM, antérieure à Git, elle devra développer une stratégie de fusion et de branche logicielles au sein de ce système existant afin d’atteindre la vitesse nécessaire au développement DevOps.

Il est nécessaire de garder à l’esprit le besoin de développer ses compétences en vue d’adopter de nouvelles pratiques et outils de SCM. Cela doit être pris en compte lors de la mise en place de la stratégie.

DevOoops : des conflits dans la gestion de configuration logicielle
DevOoops : des conflits dans la gestion de configuration logicielle

Ma principale erreur « DevOoops » remonte à l’époque où j’essayais de maîtriser les fondamentaux de Git sur un projet impliquant des sous-modules Git. Il comportait une série de scripts Bash qui implémentaient un workflow primitif d’intégration et...