Langage de programmation

Les pipelines CI/CD sont fondamentalement des programmes, ils orchestrent des tâches, acheminent des données, réagissent à des événements et coordonnent du travail sur plusieurs machines. Pourtant, la plupart des outils de pipeline reposent sur des approches qui n’ont jamais été conçues pour cela.

Pourquoi les approches existantes sont insuffisantes

Configuration YAML

Des outils comme GitHub Actions, GitLab CI et CircleCI représentent les pipelines sous forme de fichiers YAML décrivant des séquences de commandes shell. Cela fonctionne pour les cas simples, mais atteint rapidement des limites structurelles :

Pas de transmission native de données : les données entre jobs doivent être sérialisées sur disque, téléversées comme artefacts, puis téléchargées et désérialisées dans le job suivant. Il n’existe pas de concept de flux.
Parallélisme grossier : les jobs peuvent s’exécuter en parallèle, mais la coordination au sein d’un job reste séquentielle. La concurrence fine nécessite des contournements.
Expressivité limitée : les conditions sont maladroites, les boucles sont limitées ou absentes, et tout ce qui dépasse une séquence linéaire requiert des scripts externes.
Observabilité plate : une exécution en échec produit des logs à plat. Il n’existe pas de trace structurée indiquant quel traitement a reçu quelle entrée, diagnostiquer une erreur revient à parcourir des sorties plutôt qu’à inspecter un état.

Scripts impératifs

Groovy (Jenkinsfile), Python et les langages de script similaires offrent plus de flexibilité, mais introduisent leurs propres problèmes lorsqu’ils sont utilisés pour l’orchestration de pipelines :

Modèle mental séquentiel : les scripts s’exécutent ligne par ligne. Exprimer une exécution concurrente, un fan-out ou un comportement réactif nécessite une gestion explicite des threads ou des constructions asynchrones non prévues pour cet usage.
Pas de distribution native : distribuer du travail sur plusieurs machines nécessite d’écrire du code de coordination, appels SSH, files de tâches ou orchestration personnalisée. L’auteur du pipeline gère la distribution, pas le langage.
Gestion manuelle des flux : transmettre un flux d’octets ou d’événements entre machines implique d’écrire manuellement le buffering, le découpage et la gestion des erreurs.
Topologie opaque : un script n’a pas de structure intrinsèque qu’un outil peut inspecter. Déboguer revient à lire des logs d’exécution plutôt qu’à comprendre la forme du programme.

Pourquoi Mélodium est adapté

Mélodium a été conçu spécifiquement pour les programmes que les pipelines CI/CD sont réellement : distribués, orientés flux, réactifs et inspectables.

Les pipelines YAML transmettent les données via des uploads d’artefacts séquentiels. Les traitements Mélodium se connectent via des flux typés et s’exécutent en parallèle dès que leurs entrées sont disponibles.

Les flux comme entités de premier ordre

Les données circulent entre les traitements sous forme de flux typés, sans aller-retours de sérialisation entre les étapes. Fichiers, octets et valeurs structurées se déplacent directement d’un traitement au suivant, même à travers les frontières machine. Le système de types garantit qu’un Stream<byte> ne peut pas être accidentellement connecté à une entrée attendant un Block<string>, détectant les erreurs de connexion avant toute exécution.

Distribution native

Un programme Mélodium déclare ce qui s’exécute où. Le runtime prend en charge la création de processus sur des machines distantes, l’établissement des connexions entre eux et la coordination de l’exécution. L’auteur du pipeline écrit de la logique ; Mélodium gère la distribution. Il n’y a pas de code de coordination, pas d’infrastructure SSH, pas de file de tâches à gérer.

Le même programme Mélodium peut distribuer des traitements sur des machines d’infrastructures différentes. La topologie de connexion est déclarée dans le programme, le runtime gère le reste.

Exécution réactive

Les traitements s’exécutent quand leurs entrées arrivent, et non selon un calendrier prédéfini. L’exécution parallèle, le fan-out et la synchronisation s’expriment comme des connexions dans le graphe de programme. Il n’est pas nécessaire de marquer explicitement des jobs comme parallel: true ou de gérer des conditions d’attente en code impératif, la concurrence est une conséquence naturelle de la topologie du flux de données.

Validation statique

L’ensemble du programme, ses types, connexions et configuration, est validé avant toute exécution. Les incohérences de types, les connexions manquantes et les configurations invalides sont détectées au démarrage, pas découvertes à mi-chemin d’un build de 20 minutes quand un job en aval échoue à recevoir son entrée attendue.

Débogage en profondeur

Parce que le modèle d’exécution possède une topologie bien définie de traitements connectés par des flux typés, Cadence.CI peut observer les entrées, sorties et états intermédiaires à chaque nœud du graphe. C’est ce qui rend possible le débogage au niveau des traitements, quelque chose de structurellement impossible dans les pipelines basés sur des scripts, où il n’existe pas de concept de « données circulant entre l’étape A et l’étape B ».

Récapitulatif

	Config YAML	Script impératif	Mélodium
Transmission de données	Upload d’artefacts	Sérialisation manuelle	Flux typés
Parallélisme	Au niveau des jobs	Async explicite	Piloté par la topologie
Distribution	Non native	Coordination manuelle	Intégrée au langage
Validation	À l’exécution	À l’exécution	Au démarrage (statique)
Débogage	Logs à plat	Logs à plat	Traçage E/S par traitement

Général Intégration avec les fournisseurs de cloud