Le CI le plus rapide que nous ayons construit a échoué

 (earthly.dev)
1 points par GN⁺ 2023-09-13 | 1 commentaires | Partager sur WhatsApp
  • Plutôt que d’affronter de front les acteurs établis du marché des outils CI/CD, Earthly s’était concentré sur la vitesse de build ; l’entreprise met fin à Earthly CI et se reconcentre sur Earthly et Satellites
  • La vision initiale était d’unifier le système de build et le CI et de l’exécuter de manière distribuée, afin d’offrir à la fois parallélisme automatique, mise en cache et reproductibilité locale
  • Earthly et Earthly Satellites ont chacun été validés, respectivement pour la cohérence des builds et des pipelines CI 2 à 20 fois plus rapides, mais le produit censé remplacer entièrement le CI n’a pas généré assez de conversions
  • Les nouveaux clients voyaient surtout le coût de migration et la charge de réécriture des scripts, tandis que les clients Satellites existants obtenaient déjà 95 % de la valeur d’Earthly CI avec une combinaison de CI existant comme GitHub Actions
  • Earthly CI s’arrêtera le 1er octobre 2023 ; Earthly investit dans Satellites pour permettre aux utilisateurs de conserver leur CI existant tout en bénéficiant de builds rapides

Arrêt d’Earthly CI et recentrage

  • Earthly met fin à Earthly CI et réaligne l’entreprise autour d’Earthly et d’Earthly Satellites
  • La valeur sur laquelle l’entreprise se concentrera désormais se limite à deux axes
    • les builds locaux et la reproductibilité
    • Earthly Satellites, utilisable avec les CI existants
  • Earthly CI visait un CI rapide, mais n’a pas produit de signaux d’adoption initiale suffisants sur le marché

La vision initiale du « CI le plus rapide »

  • Earthly a démarré en avril 2020 avec l’objectif d’améliorer les outils CI/CD
  • Le point de départ était deux questions
    • À quoi ressemblerait un CI s’il pouvait aussi s’exécuter sur un ordinateur portable ?
    • À quoi ressemblerait le système CI le plus rapide au monde ?
  • La réponse trouvée par Earthly était que le système de build et le CI devaient être identiques, tout en étant distribués
  • L’objectif était de ne pas répéter les étapes de build non affectées par un changement, d’offrir une exécution parallèle automatique et de reproduire de manière fiable n’importe quelle partie du build sur un ordinateur portable

Comment une petite équipe peut concurrencer les fournisseurs CI établis

  • Une startup en phase initiale peut difficilement rivaliser avec des acteurs établis disposant de financement, d’effectifs, d’une réputation et de plus de dix ans d’avance en matière de finition, de nombre de fonctionnalités et d’étendue des intégrations
  • La stratégie choisie par Earthly n’était pas de convaincre tout le marché, mais d’offrir une solution 10 fois meilleure à un petit nombre d’équipes souffrant fortement d’un problème précis
  • Une validation initiale ressemble à l’apparition d’un petit groupe d’utilisateurs enthousiastes, même si le produit comporte des bugs et des limites
  • Quand un MVP n’obtient pas une validation suffisante, se contenter d’ajouter des fonctionnalités conduit souvent à une compétition où les acteurs établis sont avantagés

Le plan en 3 étapes vers Earthly CI

  • Earthly n’a pas construit directement son objectif final, Earthly CI ; l’entreprise l’a découpé en plusieurs produits indépendants afin de valider chaque étape

  • Étape 1 : Earthly

    • Le premier jalon était Earthly
    • Earthly a d’abord fourni une syntaxe de build et une expérience d’exécution de builds à la demande
    • Sa valeur principale était la cohérence des builds, c’est-à-dire faire en sorte que le build s’exécute de la même façon quel que soit l’environnement d’exécution
    • Au début, il s’exécutait en local et dans d’autres CI, puis il a été utilisé dans des milliers de dépôts
    • VMware, Adobe, Namely, Roche, ExpressVPN et Bluecore sont cités parmi ses utilisateurs
    • Il s’agissait d’un projet non financé développé par une seule personne, avec des bugs et des contraintes, mais le fait que des gens l’utilisent réellement a constitué un signal de validation

  • Étape 2 : Earthly Satellites

    • Le deuxième jalon était Earthly Satellites
    • Satellites est un runner distant que l’on peut appeler depuis un ordinateur portable ou depuis n’importe quel CI
    • Sa valeur principale était la vitesse de build, grâce au caching et au parallélisme, pour rendre les pipelines CI 2 à 20 fois plus rapides
    • Comme Earthly était open source, les utilisateurs pouvaient obtenir un effet similaire avant même l’arrivée du service commercial en opérant eux-mêmes un runner distant basé sur Buildkit
    • Lorsque les Satellites managés sont arrivés, les utilisateurs ont commencé à utiliser le produit pour ne pas avoir à gérer eux-mêmes des runners distants
    • Les premiers Satellites avaient des bugs, étaient inefficaces et instables, mais les alternatives offrant le même niveau de vitesse CI/CD étaient rares, ce qui a attiré des utilisateurs

  • Étape 3 : Earthly CI

    • Le troisième jalon était Earthly CI
    • Earthly CI était une plateforme CI complète combinant Earthly et Satellites, destinée à concurrencer des CI comme GitHub Actions, CircleCI et Jenkins
    • Earthly visant la cohérence des builds et Earthly CI la vitesse de build, l’entreprise pensait qu’Earthly gratuit ne cannibaliserait pas la monétisation d’Earthly CI
    • Mais plus tard, la différence de proposition de valeur entre cohérence et vitesse s’est révélée problématique

Les barrières de conversion apparues après le lancement

  • Earthly CI a été lancé, présenté dans TechCrunch, et des billets de blog destinés à Reddit et HackerNews ont également été préparés
  • Dans les 1 à 2 premières semaines après le lancement, environ 50 e-mails se sont inscrits sur la liste d’attente, dépassant l’objectif
  • Une nette différence existait entre les nouveaux clients et les utilisateurs Earthly existants
    • Les nouveaux clients voyaient souvent le CI comme « globalement similaire, avec seulement une syntaxe différente » et n’examinaient pas en profondeur ce qui différenciait Earthly CI
    • Les discussions dérivaient le plus souvent vers le coût de migration, lié à la réécriture des scripts existants et à l’adaptation nécessaire
    • Les utilisateurs Earthly existants avaient déjà terminé leur transition vers Earthfile et expérimenté les avantages d’Earthly, ils étaient donc prêts à devenir des défenseurs du produit en interne
  • Pour les nouveaux clients, Earthly n’avait pas encore la réputation permettant de prouver qu’il pouvait fournir les bénéfices promis à grande échelle, et il était difficile de démontrer en un court appel Zoom que l’expérience vécue par les utilisateurs existants était « 10 fois plus simple »

Pourquoi même les clients existants ne sont pas passés à Earthly CI

  • La plupart des clients Earthly Satellites existants utilisaient déjà Satellites dans leur CI/CD
  • Earthly pensait que, puisque le fournisseur CI ne gérait que le déclenchement du pipeline et que l’exécution réelle se faisait dans Satellites, le besoin d’Earthly CI était validé
  • Mais les clients Satellites obtenaient déjà 95 % de la valeur d’Earthly CI
  • Comparé à une configuration GitHub Actions + Satellites, Earthly CI n’était pas suffisamment meilleur et il manquait de raisons de migrer
  • Les utilisateurs Earthly existants utilisaient déjà Earthfile, ce qui semblait rendre la migration facile, mais les besoins réels étaient plus nombreux
    • l’écosystème de plugins GitHub
    • codecov action
    • les déclencheurs manuels
    • les déclencheurs basés sur la création de git tag
    • le choix de la taille des machines
    • l’annulation des anciens builds
    • la confiance nécessaire pour confier les secrets de build
  • Le MVP d’Earthly CI était le CI le plus rapide, mais il ne satisfaisait pas certaines exigences essentielles
  • Quelques utilisateurs enthousiastes ont essayé Earthly CI, mais son usage ne s’est pas étendu à plus de 2 ou 3 personnes dans des organisations de taille significative disposant d’un budget
  • Certains utilisateurs d’Earthly CI sont ensuite devenus utilisateurs de Satellites afin de bénéficier à la fois de l’écosystème GitHub et de la vitesse de Satellites

Pourquoi les demandes de démo sont devenues un signal négatif

  • Earthly a eu plus de 100 appels avec des clients potentiels, mais il était difficile de les convaincre, en face à face, d’utiliser Earthly CI, Satellites ou Earthly
  • À l’inverse, lorsque les utilisateurs arrivaient d’eux-mêmes via le site web, la croissance tirée par le produit, le bouche-à-oreille ou le content marketing, l’adoption d’Earthly se produisait tous les jours et progressait fortement
  • Les outils pour développeurs, en particulier ceux qui nécessitent un travail d’intégration, sont difficiles à valider avec une approche commerciale directe traditionnelle
  • Le critère de qualification négatif le plus fort était un prospect demandant une démo
  • Les équipes qui convertissaient réellement téléchargeaient Earthly, lisaient la documentation, écrivaient elles-mêmes un Earthfile puis prenaient contact ; elles n’avaient pas besoin de démo
  • Les outils pour développeurs nécessitant un travail d’intégration sont adoptés selon le calendrier des utilisateurs, et il est difficile de les vendre de force ou de pousser leur adoption rapidement

Le test A/B qui a remplacé « CI » par « build »

  • À l’époque, le message du site web d’Earthly était « Earthly makes CI super simple », et la majeure partie du premier écran mettait l’accent sur le CI
  • Gavin Johnson a proposé un test A/B remplaçant le mot « CI » par « build » sur le site web
  • La phrase est devenue « Earthly makes builds super simple »
  • Ce changement d’un seul mot a doublé la conversion vers la page du CTA principal, « Get Earthly »
  • Après ce résultat, les doutes concernant Earthly CI lui-même se sont renforcés

Les leçons tirées de l’expérience ShiftLeft

  • ShiftLeft, lancé avant Earthly, s’appelle aujourd’hui Qwiet.ai
  • Sa vision initiale était un agent de sécurité à installer en production pour protéger les applications cloud contre les attaques exploitant les vulnérabilités du code source
  • Ce produit nécessitait un analyseur de code prenant en charge plusieurs langages de programmation, des agents pour chaque runtime et un backend distribué intégrant le tout, ce qui revenait presque, pour une petite startup, à construire simultanément la complexité de trois entreprises
  • Après plus d’un an d’efforts, un fonctionnement de bout en bout a été obtenu pour un langage de programmation, mais la réaction du marché n’a pas été bonne
  • Les clients cibles du produit de sécurité étaient des entreprises fortement régulées, et le produit devait être intégré à la fois au CI/CD et à la production, rendant le chemin d’adoption très difficile
  • À l’époque, l’équipe pensait pouvoir surmonter la difficulté d’adoption en ajoutant plus de fonctionnalités, et a construit pendant un an et demi de plus, mais le marché n’en voulait pas
  • Elle a compris tardivement que ce produit complexe aurait pu être divisé en deux produits différents
    • un outil d’introspection de code pour experts en sécurité
    • un analyseur de code indépendant 40 fois plus rapide que les autres analyseurs du marché
  • Le plus grand regret a été de ne pas s’être arrêtée plus tôt, lorsque les signaux étaient déjà là

Le jugement d’Earthly

  • Earthly a résumé la situation ainsi
    • les gens veulent des builds plus rapides
    • les gens détestent changer de CI
    • un nouveau CI porte le stigmate de ne pas être différencié, et les utilisateurs quittent le site dès qu’ils voient « CI »
    • l’implication de type design partner par contact direct avec les clients ne fonctionne pas, en raison de la perception d’un coût de migration élevé
    • le MVP d’Earthly CI n’a pas réussi à créer un groupe suffisant d’adopteurs initiaux
    • les réactions s’améliorent lorsqu’on explique qu’Earthly Satellites permet d’obtenir des builds plus rapides sans changer de CI existant
  • Le problème central n’était pas le manque de fonctionnalités d’Earthly CI
  • Pour un produit initial prometteur, il devrait exister un groupe prêt à supporter l’absence de certaines fonctionnalités afin d’en tirer les bénéfices ; Earthly CI n’a pas produit suffisamment de signaux de ce niveau
  • Earthly a donc décidé d’arrêter Earthly CI et de se concentrer sur ce qui fonctionne déjà : Earthly et Earthly Satellites

Calendrier d’arrêt et migration des utilisateurs

  • Earthly CI s’arrêtera le 1er octobre 2023
  • Earthly CI était marqué comme bêta/expérimental, mais Earthly accompagnera la transition des utilisateurs
  • Comme Earthly fonctionne avec n’importe quel CI, l’entreprise estime que migrer hors d’Earthly CI est simple
  • Les utilisateurs souhaitant conserver des builds rapides peuvent connecter Earthly Satellites, qui propose aussi un tier gratuit
  • L’accompagnement de la transition est fourni directement dans la communauté Slack Earthly

Orientations d’investissement futures pour Satellites

  • Earthly Satellites montre des signes de croissance, car il offre non seulement des builds rapides et cohérents, mais permet aussi aux utilisateurs de conserver leur propre CI
  • Le temps libéré par l’arrêt d’Earthly CI sera investi dans les fonctionnalités demandées par la communauté Earthly
    • Satellite metrics, incluant l’utilisation du CPU, de la mémoire, du disque et des I/O réseau
    • Build history dans l’interface web, pour les builds locaux comme pour les builds Satellites
    • Auto-skip, qui saute immédiatement un build si les fichiers modifiés ne l’affectent pas
    • la possibilité d’exécuter à distance des builds Dockerfile sur Satellites comme alternative rapide à docker build
    • self-hosted Satellites, une version mieux prise en charge de self-hosted remote Buildkit
    • la possibilité de distribuer un build unique sur plusieurs Satellites pour l’accélérer
    • Compute v2, des Satellites serverless entièrement distribués
  • Earthly Satellites est un runner de build distant qui fonctionne avec n’importe quel CI et est accessible via Earthly Cloud
  • Earthly est un framework de build open source qui fournit une cohérence des builds — écrits une fois, exécutables partout — et aide à reproduire facilement les échecs CI sur une machine locale

À lire aussi

1 commentaires

 
GN⁺ 2023-09-13
Avis sur Hacker News

  • Cet article montre bien pourquoi il ne faut pas tout céder de sa valeur centrale quand on passe en open source. Comme Earthly était open source, les utilisateurs d’Earthly Satellite bénéficiaient déjà de 95 % de la valeur d’Earthly CI.
    J’adore l’open source, mais si votre modèle économique l’intègre, il faut un élément différenciant. Au-delà du simple fait d’être extrêmement rapide, il faut donner aux gens une raison de sortir leur carte bancaire, voire de lancer une procédure de bon de commande côté comptabilité.
    GitLab réserve le CI/CD aux clients payants, Travis/CircleCI limitent le temps de build ou les crédits, Azure DevOps est diabolique, et ArgoCD est complexe. GitHub Actions convient si l’on a le matériel pour faire tourner des runners, et en entreprise, les troupeaux de Jenkins restent assez familiers.
    En tant qu’ancien directeur DevOps, la première question que je pose est : « quelle fonctionnalité me pousse à acheter plutôt qu’à l’héberger moi-même ? ». Si j’ai les compétences techniques pour l’exploiter moi-même, et que je peux faire fonctionner mon cloud et mes pipelines DevOps en les adaptant à notre activité, il faut me convaincre de vous payer.
    Je ne dis pas qu’il faut cacher les fonctionnalités indispensables au fonctionnement du logiciel, mais plutôt mettre derrière une offre payante des fonctions business comme le support ou les intégrations de niveau entreprise. On peut aussi imaginer des niveaux où les utilisateurs avancés, qui se débrouillent davantage eux-mêmes côté support, paient moins.

    • Je ne suis pas sûr que les limitations de fonctionnalités aient traditionnellement très bien marché dans les outils pour développeurs. Le taux d’abandon des outils est tellement élevé que si Earthly affaiblit volontairement son produit, la plupart des développeurs passeront sans doute à une alternative gratuite, même inférieure, comme taskfile.
      Ils pourraient convertir les utilisateurs restants en clients payants, mais c’est un pari assez risqué. Un bon contre-exemple récent pourrait être Docker, mais cela a nécessité d’abandonner l’open source strict et d’opérer des changements de licence et de produit très controversés.
    • En lisant « en entreprise, les troupeaux de Jenkins restent familiers », je pensais que nous étions la dernière organisation dans ce cas, et je suis étrangement rassuré de voir que cette configuration impie est plus ou moins un standard.
    • Les runners GitLab CI peuvent être auto-hébergés et sont disponibles même dans l’édition communautaire gratuite.
    • Même si cela peut faire débat, j’aimerais que, pour les services, l’approche commerciale source available devienne plus courante et moins décriée que l’« open core ».
      Il est très frustrant de ne pas pouvoir lire le code situé hors de l’« open core », contribuer à des corrections de bugs ou l’auto-héberger, et les éléments qui distinguent les licences open source des licences source available ne me sont pas vraiment nécessaires.
    • Si quelqu’un gérait correctement la mise en motifs des applicationset, il serait sans doute possible d’enrober ArgoCD dans un produit. D2iQ le fait déjà avec Flux, mais nous avons quitté D2iQ avant même d’avoir pu l’essayer.

  • Je ne veux pas jouer les rabat-joie, mais c’est littéralement proche d’un produit copié-collé.
    Il y a Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines, et vu les profils — ex-Google, ex-VMW, RabbitMQ — ce n’est pas surprenant.
    Même si l’auteur du billet n’était pas directement à la source de ces outils, il était au moins dans leur proche parenté.
    Les cycles de vente sont longs, et les intégrations exigent l’accord de cadres sur plusieurs axes, notamment la sécurité et le réseau.
    Ils ont construit quelque chose de bien, mais les problèmes en amont sont tellement composites que, dans un domaine qui oscille sans cesse entre sur-mesure et produit généraliste, cela m’a semblé être une histoire assez creuse. On y trouve de tout, de l’absence de supervision au micromanagement, de l’immaturité à l’excès d’expérience qui empêche de lâcher « la manière dont on a toujours fait ».
    C’est peut-être une opinion impopulaire, mais vendre une chaîne d’outils revient à vouloir faire bouillir un océan de problèmes. Le business et la technique s’écoulent comme l’eau, par les ouvertures offrant le moins de résistance, et finissent parfois par éroder les fondations du « cœur de métier ». D’après mon expérience, les chaînes d’outils qui agissent comme des recommandations ou une « stratégie d’élevage », avec des garde-fous amovibles, sont celles qui rapportent le plus.

    • Plus fondamentalement, ce produit ne donnait pas assez de raisons de l’utiliser, encore moins de raisons de payer.
      « Rapide » n’est pas un argument de vente. Les développeurs ne veulent pas de pipelines lents, mais cela ne veut pas dire qu’ils veulent des pipelines rapides.
      La vitesse d’un pipeline dépend bien davantage de la manière dont il est conçu que de l’overhead du service de pipeline, et les autres services CI/CD sont déjà très rapides. Par exemple, CircleCI n’est déjà pas facile à vendre face à GitHub Actions et GitLab CI/CD ; alors en quoi ce service se différenciait-il ? Apportait-il une valeur réelle par rapport à GitHub/GitLab/CircleCI, etc. ? Gagner des millisecondes sur des builds de quelques minutes n’est pas la réponse.

  • La raison de l’échec, c’est que le marketing était manifestement bâclé et assez malhonnête.
    Que vous compiliez avec Jenkins, Actions ou Earthly, si vous utilisez le même nœud de build, le temps de compilation sera identique. Dans un contexte où le CI démarre en quelques secondes, affirmer être 20 fois plus rapide n’a pas grand sens.
    Le caching et l’exécution parallèle sont de vieux concepts en CI, et tous les systèmes de build modernes savent les faire.
    Le cœur du CI, c’est le feedback, or je n’ai pas vraiment vu d’aspects liés à la collaboration ou à la remontée des données. Je n’ai pas regardé en détail, mais cela devrait être mis en avant. Enfin, je ne veux plus jamais introduire un DSL pour les builds.

    • Configurer le caching et la parallélisation avec GitHub Actions, Jenkins, Docker et Make est beaucoup plus difficile que de le faire avec Earthly seul.
    • Peux-tu préciser ce que tu entends par « feedback » ? Je suis curieux de savoir quel type de feedback tu attends d’un CI.

  • Que veut dire exactement CI rapide ?
    La CI, c’est un script shell devenu démesuré qui lance le build et signale les échecs. En général, l’outil de build lui-même est devenu tellement lent que le coût des runners CI devrait être quasiment nul en comparaison.
    Si l’on veut une CI rapide, ce sont tsc, clang, rustc, etc. qui doivent être rapides, pas le programme qui les appelle via exec.
    Pour rester un peu plus dans le sujet : si l’on vend de la CI et que l’entreprise échoue, c’est parce qu’on n’a pas apporté de valeur. Les gens peuvent très bien exécuter leurs scripts de build sans vous.

    • En parcourant rapidement l’article, il me semble qu’il parle ici d’une CI qui gère automatiquement des choses comme la mise en cache des artefacts de build, afin de ne pas avoir à recompiler tout le dépôt à chaque commit.
      Il ne s’agit pas de dire que le programme qui appelle exec est plus rapide, mais d’un programme qui sait qu’il n’a pas besoin d’appeler exec dès le départ.
    • J’aimerais que ce soit aussi simple que « la CI est un script shell hypertrophié qui lance le build et signale les échecs ».
      Je ne sais pas ce qui a été mesuré, mais pour donner un exemple, la page d’accueil par défaut de Jenkins est une catastrophe en matière de performances. Elle essaie d’afficher un peu partout les données des builds récents de tout le cluster, et même sur un cluster pas si grand, elle peut devoir récupérer des centaines, voire des milliers d’éléments auprès des nœuds individuels qui exécutent chaque build.
      J’ai tué Jenkins un nombre incalculable de fois rien qu’en chargeant la page d’accueil, en l’absence d’un réglage particulier empêchant le comportement par défaut.
      Un serveur CI a généralement sa propre base de données et gère toutes sortes d’entités CI : jobs, artefacts, utilisateurs, secrets, etc. Cela peut devenir assez volumineux et il faut s’occuper correctement de l’indexation, entre autres.
      La CI comporte plusieurs runners, souvent provisionnés dynamiquement. Imaginez devoir déployer des images de VM ou Docker sur des nœuds de runners. Les diffuser rapidement dans le cluster n’est pas trivial. On veut aussi probablement distribuer les artefacts à travers tout le cluster, ce qui consomme également du temps et des ressources.
      La CI a aussi besoin, en pratique, de sa propre comptabilité interne pour le garbage collection, le reporting et l’autodiagnostic. Sur un cluster suffisamment grand, tout cela peut engendrer des latences très élevées si l’on ne fait pas d’efforts spécifiques pour les réduire.
      Vous avez entendu parler de ccache ?
      Mais sérieusement, dire qu’il suffit d’avoir un tsc/clang/rustc rapide est beaucoup trop naïf. Pour rendre les builds rapides dans un système distribué comme la CI, il faut aussi résoudre la question de la distribution de ce cache et de la modularisation des builds. Vous avez sans doute entendu dire que l’une des choses les plus difficiles en programmation est l’invalidation du cache ; ce n’est qu’à moitié une blague.
    • Le seul aspect de la proposition d’Earthly qui m’ait vraiment parlé, c’est la possibilité d’exécuter la CI en local. Quand on débogue la CI, pouvoir la lancer sur sa propre machine permet de trouver les problèmes beaucoup plus vite.
      J’ai passé beaucoup de temps à ajuster des scripts GitHub Actions assez sales, parce que le cycle de debug était de 10 minutes.
    • Oui et non. Mettre en cache et savoir quand exécuter tsc/clang/rustc améliore aussi les performances.
    • La partie délicate en CI, c’est de repérer le travail qu’on n’a pas besoin de faire. C’est là qu’on peut gagner du temps.

  • Tant mieux s’ils arrêtent simplement le service sans fermer toute l’entreprise. J’aimais vraiment cet outil, au point de consulter souvent leur page recrutement.
    La syntaxe Earthfile est une évolution très raisonnable et progressive de la syntaxe Dockerfile, et elle facilite beaucoup de choses qui étaient impossibles, ou très maladroites, avec Dockerfile seul.
    Je me souviens que, lorsque Docker a introduit BuildKit et buildx, ils voulaient pousser Dockerfile comme système de build généraliste, c’est-à-dire pour produire non seulement des conteneurs, mais aussi des artefacts de fichiers, etc. Earthly a vraiment bien concrétisé cette idée.

    • Tu devrais essayer Dagger. Je le trouve meilleur qu’Earthly.
      Je l’utilise avec satisfaction, mais je ne paie pas encore pour l’instant.

  • Honnêtement, avec cet article seul, j’ai eu du mal à comprendre ce qui s’était passé. Même après plusieurs lectures, les termes restent confus. Il me semble qu’il y avait au moins deux problèmes distincts
    le problème de la migration de la configuration CI depuis le YAML CI existant, c’est-à-dire GitHub/GitLab, vers Earthly, une sorte d’hybride Makefile/Dockerfile
    le problème de la migration des exécuteurs de tâches depuis la CI existante vers le service hébergé par Earthly
    Je pensais que le premier point était le plus difficile. Changer de langage peut prendre des mois, voire des années
    Mais je ne suis pas sûr de ce que dit l’article de blog. Je pensais qu’ils avaient validé cette partie ; cela ne veut-il pas dire que les gens arrivaient à basculer ?
    Pourtant, à la fin, ils disent que cela n’a pas été validé. Les clients devaient-ils faire non pas une, mais deux migrations ?
    Alors, qu’en est-il maintenant ? Ils gardent la syntaxe Earthly mais abandonnent la CI ? La partie difficile à migrer n’était-elle pas justement cette syntaxe ? Je suis toujours perdu

    • Je suis rassuré de ne pas être le seul. Je m’intéresse à la fois au développement produit et aux outils de développement, et après avoir lu cet article assez confus, j’en suis resté à quelque chose comme « tant mieux pour eux, ou alors c’est dommage »
      Le point central est-il qu’ils ont supposé que des builds beaucoup plus rapides seraient la killer feature, sans valider cette hypothèse avant de construire le produit ? Ou bien qu’ils n’ont pas segmenté correctement leurs utilisateurs et n’ont pas compris que les besoins des gros clients étaient différents ? Ou encore qu’ils ont simplement offert gratuitement ce qui résolvait le vrai problème des clients payants ?
      Et comme cet article plutôt confus a été écrit par le CEO, je me demande si la confusion vient seulement d’un manque d’édition, ou s’il y avait aussi beaucoup de confusion réelle en interne tout au long du processus
      Il y a longtemps, Steve Blank a écrit dans « Founders and dysfunctional families » [1] que beaucoup de fondateurs avaient grandi dans le chaos et étaient donc doués pour le gérer, ce qui s’applique clairement à moi aussi. Il ajoutait que la différence entre succès et échec pouvait dépendre de la capacité du fondateur à gérer aussi les situations non chaotiques
      Les fondateurs qui n’y arrivent pas ont tendance à lancer des « grenades organisationnelles » dans leur propre entreprise pour revenir au niveau de chaos dans lequel ils excellent. Cette observation m’a fait m’arrêter et réfléchir plusieurs fois au fil des années
      [1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
    • Ce n’est pas un problème de migration de syntaxe
      Avec le temps, la CI des gens devient un modèle hybride qui encapsule toutes les façons dont l’entreprise construit et déploie chacun de ses logiciels. Imaginez une CI détournée en exécuteur de tâches d’automatisation arbitraires, façon Airflow
      La migration commence par rétro-ingénierer ce que les gens savaient autrefois, et ce n’est qu’ensuite qu’on peut tout démêler pour l’exprimer autrement
      Personne n’a envie d’arrêter le monde pour mettre ça au propre

  • Cet article est confus parce que son auteur est trop proche du problème, et il aurait besoin de l’expliquer du point de vue d’un observateur extérieur avant d’entrer dans les détails. Cela dit, les informations nécessaires semblent bien présentes
    Au final, ils semblent avoir créé une couche d’encapsulation entre les systèmes de build propres à chaque langage et le système de build continu qui les exécute
    À titre de comparaison, on peut penser à quelque chose comme Bazel : Bazel fait tout, mais pour l’adopter pleinement, il faut s’engager à remplacer les systèmes de build propres aux langages par le langage de build de Bazel, et il faut souvent déplacer les fichiers source pour que ça fonctionne
    Cela peut paraître étrange par rapport à l’utilisation du système de build natif d’un langage, mais cela peut sembler naturel aux programmeurs C, dont le langage n’a pas de système de build propre. Java aussi est passé par plusieurs systèmes de build regrettables avant de se fixer malheureusement sur Gradle
    Les systèmes de build propres à chaque langage ne font finalement pas tout, parce que chaque langage a ses conventions et son écosystème. Les plus modernes savent ce qu’ils font bien et s’en tiennent à ce périmètre
    C’est pourquoi les outils qui comprennent réellement plusieurs langages et artefacts sont souvent des scripts shell, des makefiles, des Dockerfiles, ou la CI elle-même. Parfois même, c’est fait à la main. La couche qu’ils essaient d’améliorer, c’est précisément celle-là
    Cela dit, l’intuition fondamentale expliquant pourquoi leur approche serait meilleure ne ressort pas encore clairement

  • Il y a quelque temps, j’ai brièvement examiné Earthly pour le travail. Il fallait écrire des intégrations pour plusieurs plateformes de CI : GitLab, Azure DevOps, Jenkins, et peut-être même GitHub Actions.
    Au final, nous avons choisi Dagger, un produit très similaire : un autre bon frontend BuildKit qui s’intégrait à plusieurs systèmes de CI, et dont le DSL utilisé à l’époque pour définir les pipelines me semblait meilleur.
    Mais j’ai fini par profondément regretter cette décision. Les développeurs de Dagger ont en pratique abandonné ce langage pour se tourner vers une avalanche de SDK pour langages de programmation populaires. Tous impératifs, tous Turing-complets, et à mon avis mal adaptés à ce domaine.
    Résultat, nous sommes revenus en enfer à intégrer tous ces systèmes à la main, et j’hésite désormais à confier à nouveau ce type d’outils à une startup.
    Pour moi, cela reste le cas d’usage le plus séduisant d’un outil comme Earthly. « Pousser et voir ce qui se passe » est la norme dans presque tous les systèmes de CI, et c’est un workflow horrible.
    Si, dans une grande organisation, vous devez soutenir des équipes qui utilisent différentes plateformes de CI/CD, quelque chose comme Earthly peut réduire pas mal de souffrance. Mais l’intérêt n’est pas d’ajouter une CI de plus : il réside précisément dans la prise en charge des plateformes de CI existantes.

    • La CI/CD et le provisionnement sont par nature des tâches où l’ordre compte ; personnellement, je préfère donc l’approche SDK à l’implémentation CUE.
      Le principal problème de l’ancienne implémentation CUE était qu’elle cherchait à faire correspondre le solveur de graphe orienté acyclique de BuildKit avec celui de CUE, alors que les deux fonctionnaient en sens inverse.
      Il y a environ trois ans, en tant qu’expert CUE, j’ai essayé d’aider à résoudre ce problème. Pour Dagger, je pense que les SDK sont une bien meilleure solution.
      Qu’on l’apprécie ou non, une bonne partie de l’industrie va dans cette direction. Pulumi en est un autre exemple. Je suis convaincu par l’infrastructure cloud impérative, et les builds semblent aussi s’y prêter dans une certaine mesure.
      À titre annexe, je vais explorer une nouvelle combinaison CUE + Dagger, mais elle fonctionnera différemment de l’ancien moteur Dagger.
    • En tant que CEO de Dagger, je dirais ceci : nous proposons bien des SDK pour des langages populaires, et il est vrai que ces langages sont impératifs. Mais Dagger reste un système déclaratif, donc ce que vous aviez apprécié dans les premières versions est toujours là.
      Le point essentiel est que nous avons déplacé la couche déclarative d’une configuration CUE statique vers des requêtes GraphQL dynamiques. Et nous avons généré des bibliothèques clientes pour plusieurs langages à partir du schéma GraphQL.
      Il est donc toujours possible, comme avant, de construire déclarativement un graphe orienté acyclique, mais aussi de le faire dans le langage de votre choix. Vous pouvez même exécuter directement le DAG en GraphQL pur. Il suffit de regarder https://play.dagger.cloud, utilisable directement dans le navigateur.
      Une analogie utile est SQL. SQL est un langage déclaratif, mais il est généralement utilisé avec d’autres langages, souvent impératifs.
      J’espère que cette explication vous sera utile et vous donnera envie de reconsidérer Dagger.

  • L’expression « builds 2 à 20 fois plus rapides » apparaît plusieurs fois dans l’article. Par rapport à quoi ? Sans référence de base, cette formule n’est que du baratin marketing sans valeur.

    • Par rapport à des builds exécutés sur d’autres plateformes sans cache ni parallélisation.

  • Le passage « pourquoi ne pas simplifier la stack ? Au lieu de payer à la fois le fournisseur de CI et nous, payez seulement nous » s’explique par le fait que la CI qu’ils « paient » est fournie avec le reste de la stack. GitLab et GitHub offrent bien plus qu’un simple produit de CI.
    Je comprends aussi le passage selon lequel « les nouveaux venus regardaient Earthly CI avec scepticisme, pensaient que toutes les CI se valaient et que seule la syntaxe changeait, puis n’allaient pas plus loin ».
    La CI en elle-même ne nous intéresse pas vraiment ; nous en avons juste besoin, et il faut qu’elle fonctionne correctement.
    Si une appli dispose déjà d’un manifeste de CI fonctionnel, une nouvelle appli reprend le même manifeste avec quelques remplacements ciblés. Il peut y avoir de la douleur à la première mise en place, mais en regardant les exemples, cela ne semble pas franchement plus simple que de faire la même chose dans GitLab.
    Honnêtement, s’ils avaient ajouté un convertisseur capable de prendre une configuration GitLab ou GitHub CI et de produire à la volée un Earthfile, cela aurait au moins pu donner envie d’essayer.