L’approche CI/CD est-elle compatible avec l’infogérance ?

Matérialisation par excellence de la culture DevOps, l’approche CI/CD a permis de pousser le concept encore plus loin en lui apportant une très commode couche d’automatisation dans les processus de développement, de distribution et de déploiement. Si cette automatisation a apporté un confort de vie indéniable aux développeurs côté “CI”, elle leur a également ôté le poids et la charge d’opérations complexes côté “CD” (dans des contextes où la CI/CD est très poussée). 

Alors, avec une démarche qui a permis aux développeurs de s’affranchir encore plus des métiers qui nécessitent des compétences et de la culture en infrastructures, est-ce encore la peine de s’encombrer d’un infogéreur ? Si l’approche CI/CD entretient la chimère de compétences “Ops” superflues et scalables, elle est pourtant loin de les mettre au rebut. Il en va de même pour l’infogérance.

Mais pour bien comprendre et définir la place de l’infogérance dans un contexte de CI/CD, il faut d’abord se pencher sur les deux dimensions qui vont la conditionner. Premièrement les raisons qui motivent l’adoption d’une approche CI/CD et deuxièmement, le niveau d’automatisation qu’on souhaite apporter au code et aux infrastructures.

De la tambouille maison à la livraison rapide

Le travail d’équipe pour les développeurs, c’est un peu comme jouer au Jenga à plusieurs et en simultané. Chacun joue le jeu, mais l’effort collectif semble plus participer à l’effondrement du projet qu’à sa résolution ou son amélioration. Autant dire que c’est chronophage et laborieux. C’est précisément ce que cherche à adresser la CI/CD.  

Nous pourrions aller très loin sur la définition du terme, mais ce n’est pas le but de cet article et, en plus, nous ne ferions que paraphraser cet excellent article de Red Hat. En pratique, l’approche CI/CD couvre beaucoup de besoins, mais sa finalité reste principalement d’augmenter la fréquence de distribution des applications grâce à l’introduction d’un haut niveau d’automatisation sur les étapes de développement, de test et de distribution. Les équipes de développement logiciel peuvent ainsi livrer plus vite. Mais l’automatisation de tâches introduite par la CI/CD a aussi répandu quelques perceptions erronées à son égard. Nous en avons notamment relevé deux. 

Premièrement, une croyance selon laquelle la CI/CD serait réservé aux équipes surdimensionnées évoluant dans des grosses structures. Certes, les processus d’intégration continue sont indispensables dans ce cas de figure, mais ils sont aussi adaptés aux plus petites structures. Et ce, pour une raison très simple aux allures d’inavouable vérité : le travail en équipe devient complexe dès qu’elle est constituée de deux développeurs, surtout s’ils travaillent en parallèle sur un même projet. Chacun a vite fait de se gêner ou de ruiner le travail de l’autre en poussant ses modifications. Les outils comme GitLab ont permis de démocratiser l’usage de la CI/CD pour les équipes réduites en leur facilitant la mise en place. Deux développeurs peuvent très simplement créer deux branches, travailler indépendamment et tester automatiquement chaque itération avant de les fusionner.

Deuxièmement, considérer qu’il s’agit “d’un truc de développeurs”. Quand on parle de CI/CD, on a souvent tendance à se concentrer sur le développement continu en occultant l’autre partie de l’acronyme qui englobe pourtant deux dimensions : la distribution et le déploiement continu. Une tendance liée à une sur-représentation et survalorisation des compétences en développement dans les entreprises, au détriment de celles en infrastructures. Nous avons d’ailleurs largement adressé ce point dans notre article “Pour en finir avec le grand n’importe quoi qu’est devenu le DevOps” mais là n’est pas le sujet. Si les développeurs ont eu raison de s’emparer de cette pratique aussi commode qu’indispensable, cela a néanmoins participé à la création d’une vision unilatérale de la CI/CD, déformée par le prisme métier des développeurs. Concrètement, cela s’est traduit par un recours à l’automatisation aussi hasardeuse qu’abusive de tâches “Ops” qui nécessitent pourtant une connaissance exhaustive du sujet.

Ce n’est pas parce qu’une possibilité technique existe qu’elle doit absolument être utilisée pour autant. Un peu comme l’expliquait Barry Sonnenfeld, réalisateur de “La Famille Adams”, au sujet de la 4K dans une interview : 

“Si on devait tourner La Famille Adams aujourd’hui, on filmerait ça en numérique et pas sur des pellicules 35mm. Ce serait en HDR [high dynamic range] et qu’importe ce qu’on en dit, la HDR c’est le mal. Ce n’est pas une bonne chose ; c’est un argument marketing. La 4K est un argument marketing. Tous les studios de streaming disent : “Tu dois tourner en 4K”. Et pourtant les acteurs ne sont pas beaux en 4K, on voit toutes les traces de maquillage. Alors qu’est-ce qu’on fait ? On tourne quand même en 4K parce que c’est un argument marketing.”

Autrement dit, même si c’est pratique et accélère la fréquence de distribution, tout ne mérite pas d’être automatisé. 

Automatisation & CI/CD : le risque, c’est d’y céder

(Pour les besoins impérieux du jeu de mots nous avons exceptionnellement prononcé CI/CD avec l’accent français, ne nous jugez pas)

Alors concrètement qu’elle est la bonne part d’automatisation ? Il n’existe pas de méthode infaillible ou de règles pour le déterminer avec exactitude, seulement quelques orientations. Chez Oxeva par exemple, nous avons tendance à considérer qu’il faut automatiser le nombre minimum d’étapes pour avoir une CI/CD pratique et fonctionnelle. En pratique nous ciblons les étapes chronophages et périlleuses qui n’ont rien à gagner à être effectuées manuellement par des humains :

• Pour la “CI” : automatisation des tests, du merge et du rollback. Nous adressons aussi une mention spéciale à l’automatisation du rollback qui permet de revenir à une version précédente d’un site ou d’une application en un clic en cas de catastrophe. Cela nous a sauvé la vie plusieurs fois.
• Pour la “CD” : automatisation de la livraison du code en SSH chez l’hébergeur. Cela englobe le dépôt de code, la gestion automatique des mises-à-jour ou encore la suppression du cache. 

Pour le reste, nous estimons que l’intervention humaine reste indispensable, notamment en ce qui concerne les composants infrastructures, serveurs web et serveurs de base de données. À cet instant précis, une question commence peut-être à vous tarauder : 

“Mais dites donc Oxeva, un peu plus haut vous nous avez dit que la CI/CD c’était pas juste un truc de développeur, mais vu ce que vous préconisez d’automatiser, ça ressemble à un truc de développeur quand même non ?”

Si on ne regarde que par le prisme de l’automatisation c’est vrai. Mais l’approche CI/CD n’est pas qu’une question d’automatisation de processus techniques. Elle s’inscrit dans la philosophie DevOps et repose donc autant sur la technique pure que sur le partage de compétences et de connaissances. Un excellent développeur aura du mal à être efficace sur la mise en place de la CI/CD et pourra faire les choses de travers côté infrastructures. Un très bon Ops ne saura pas les fonctionnalités métiers que les développeurs veulent intégrer dans la CI/CD. Il faut donc dialoguer pour mettre en place un pipeline qui réponde aux besoins du métier tout en restant robuste.

C’est précisément la raison pour laquelle les fonctionnalités type “Auto DevOps” proposées par GitLab nous laissent perplexes. Premièrement, faire la promesse que tout fonctionnera comme par magie en utilisant Auto DevOps avec un Cluster Kubernetes est mensongère. “Donnez-nous votre code on s‘occupe du reste”, c’est pratique sur le moment, ce sera même peut-être fonctionnel, mais pour combien de temps ? Et deuxièmement, la manière dont GitLab promeut cette solution nous alarme un peu. Le site nous dit : 

“With Auto DevOps, developers can skip the manual work of configuration, such as security auditing and vulnerability testing, and focus on software creation.”

Une promesse sous-entendant que les développeurs n’ont pas de temps à perdre avec ces basses besognes que sont la configuration des audits de sécurité et des tests de vulnérabilités. La sécurité de vos sites ou applications est un sujet trop important pour laisser une application tierce “faire sa popote” pour la gérer à votre place. Par exemple, une bonne pratique en matière de sécurité consiste à ne pas donner les mots de passe de la prod au Lead Developer. Or, avec ce niveau d’automatisation, tous les mots de passe sont intégrés dans l’outil.

Et c’est ainsi que nous arrivons enfin à la question qui nous brûle les lèvres depuis le début de cet article.

CI/CD et infogérance font-elles bon ménage ?

Pour répondre à cette question, nous allons… répondre à 2 autres questions (mais promis à la fin ça fera une réponse).

1. Quel est le rôle ou l’utilité d’un infogéreur dans le cadre d’une démarche CI/CD ? 

En toute transparence, l’infogéreur est loin d’avoir un rôle central dans cette démarche. Contrairement à certains autres sujets liés à l’hébergement, ce n’est pas l’infogéreur qui prendra des décisions techniques à la place de l’entreprise. Son rôle est plutôt consultatif, si vous avez besoin d’avis ou de regard extérieur sur les orientations que vous êtes en train de prendre. Globalement, nous n’aurons pas grand-chose de plus à dire que ce que nous avons déjà écrit plus haut sur ce qu’il faudrait ou ne faudrait pas automatiser. Et ce rôle de conseil concernerait surtout les dimensions de déploiement & distribution continus, côté développement continu, ce n’est pas vraiment notre place (sauf si vous tenez ABSOLUMENT à connaître notre avis). 

En résumé : aiguiller pour faire les bons choix d’automatisation et s’assurer que les tests unitaires et fonctionnels s’effectuent bien.

2. Comment travailler intelligemment avec un infogéreur dans ce contexte ?

Même si le rôle de l’infogéreur est assez limité dans cet exercice, cela ne dispense pas pour autant d’une bonne communication. Établissez votre plan de route en vous demandant quelle “CI” vous voulez : que voulez-vous tester ? Comment ? A quelle fréquence ? Etc. Puis posez-vous la même question sur la “CD” : que voulez-vous livrer ? A quelle fréquence ? Avec quelles possibilités de “rollback” ? Etc. 

L’infogérant fait office de « validation tiers ». Il pourra challenger ce que vous avez mis en place avec un œil neuf et vous faire bénéficier de sa grande expérience multi-client. Il mettra le doigt sur d’éventuelles failles et pourra vous assister sur la mise en place de toutes ces automatisations de manière fluide. Et ce n’est vraiment pas pour vous embêter, mais nous assurer que tout fonctionne bien (ce qui est notre cœur de métier). 

Pour conclure, l’infogérance et la CI/CD sont compatibles, même si c’est un peu contre-intuitif sur le papier. Si le rôle de l’infogéreur s’avère assez limité, son intervention n’est pas non plus dénuée de sens puisqu’elle fait office de filet de sécurité tant sur la conception que sur la mise en œuvre de la démarche. Et comme tous les filets de sécurité, ils sont inutiles jusqu’au moment où vous en avez besoin.