Madrid DevOps est un groupe de professionnels dédié à … DevOps, comme on peut l’imaginer. Il existe un ‘Meetup Group’ où trouver les informations les plus récentes, principalement au sujet de nouvelles réunions, chaque mois.

Le 10 avril dernier, la présentation de Manuel Recena Soto et Antonio Manuel Muñiz de ClinkerHQ, s’intitulait ‘Continuous Integration’. Je leur ai posé quelques questions au sujet de cette présentation, que vous pouvez trouver ici https://speakerdeck.com/clinkerhq/integracion-continua (en espagnol).

Bonjour Antonio, bonjour Manuel, puis-je vous demander de vous présenter ?

Nous sommes les principaux développeurs de ClinkerHQ, un écosystème de développement logiciel basés sur des solutions Open Source (Jenkins, SonarQube, Redmin, SVN, Git, Nexus), prêt à être utilisé ou installé comme un service sur une plate-forme virtualisée.

De nombreux clients de ClinkerHQ comptent sur nous pour mettre en place ou améliorer leurs pratiques d’Intégration Continue (IC) en utilisant notre produit. Notre connaissance de l’Intégration Continue vient de l’expérience acquise au cours de plus de 7 ans de mise en œuvre, et d’aide à la mise en œuvre de ces pratiques dans différentes entreprises.

Qu’est-ce que l’Intégration Continue dans votre activité quotidienne ?

C’est le cœur de tout notre cycle de développement et s’il cesse de battre  nous ne pouvons pas continuer à travailler. Chaque jour chez Klicap, des builds sont effectués, les tests sont exécutés, la documentation est générée, les snapshots sont déployés, etc. et le tout automatiquement. Nous travaillons sur un produit complexe où de nombreux composants logiciels distincts sont impliqués. Sans un système d’Intégration Continue qui permette que tout soit disponible à tout instant, il serait impossible d’avancer, et notre activité au jour le jour se convertirait en un labyrinthe de composants et de dépendances.

L’Intégration Continue nous signale en temps quasi réel quand l’une des pièces du puzzle ne s’imbrique pas correctement, et nous donne la clé pour détecter la cause de l’échec instantanément.

Je vois beaucoup de gens qui pensent que utiliser Jenkins signifie qu’ils sont DevOps, ou que Intégration Continue égal DevOps. Quelle est votre définition de DevOps ?

Ce sont des concepts différents. Disons que les processus d’Intégration Continue apportent à DevOps ce qu’ils apportent au développement logiciel, ni plus ni moins.

Pour nous, DevOps est un profil dans une équipe, avec un pied dans le développement et l’autre pied dans l’infrastructure, afin d’avoir les connaissances nécessaires pour briser cette barrière qui a historiquement toujours existé entre « Développement » et « Systèmes ».

Est-ce que DevOps égal Continuous Integration + Continuous Deployment ou est-ce plus que cela ?

Ce sont des concepts différents. Intégration Continue et Déploiement Continu sont basés sur l’automatisation des tâches pour gagner en productivité. Peuvent-ils s’appliquer à DevOps ? Bien sûr.

Je vois certaines personnes militer en faveur d’un tableau de bord avec des données sur la qualité de l’infrastructure (disponibilité, saturations, etc.) pour les équipes de développement. Je suis d’accord avec quelques SLA s’ils restent simples à interpréter, mais je ne sais pas s’il existe réellement une valeur au-delà (sauf pour investiguer un incident).

Le pilotage de l’infrastructure est essentiel, surtout quand un produit est offert en mode service (SaaS). En fait, l’un des composants de ClinkerHQ fournit une série de graphiques de tendances temporelles de consommation des ressources de la plate-forme sur laquelle le produit fonctionne, ce qui permet à l’utilisateur de prendre des décisions au sujet d’un éventuel upgrade.

Il y a une phrase célèbre de Tom DeMarco, largement utilisée dans le domaine de la qualité des applications qui que « Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer ». Manuel, tu dis quelque chose de semblable dans la présentation : « Il n’y a pas de valeur sans mesure ». Peux-tu nous en dire plus ?

Tout à fait vrai. La phrase se réfère à des outils de développement logiciel et de mesure de la qualité, comme par exemple SonarQube. Il est essentiel de mesurer à quel point nos pratiques sont bonnes (ou mauvaises), et quels sont les points faibles à améliorer. Si l’on ajoute la mesure en continu (Continuous Measurement) et le déverminage (debugging) par l’inspection de code, alors nous avons la pratique connue sous le Continuous Inspection.

Quel est l’avenir de DevOps ? Dans quelle direction pensez-vous ou souhaitez vous que cela aille ?

L’avenir de DevOps ? Eh bien aucune idée, mais il semble que c’est un profil qui est là pour rester car il a toujours été nécessaire. Peut-être que les outils d’automatisation et de modélisation d’insfraestructure (je pense à Ansible, Chef, Puppet, etc. ) ont conduit à la création de ce courant. Ces outils ont mis à la disposition des équipes Systèmes les mêmes possibilités que celles dont bénéficient les développeurs depuis des années.

Merci beaucoup à tous les deux pour avoir pris le temps de répondre à mes questions.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.