私たちが作った最速のCI、その失敗
(earthly.dev)- CI/CDツール市場で既存ベンダーと真正面から競争するのではなく、ビルド速度に集中していたEarthlyは、Earthly CIを終了し、EarthlyとSatellitesへの再注力を進める
- 当初のビジョンは、ビルドシステムとCIを1つに統合し、分散実行によって自動並列化・キャッシュ・ローカル再現性を同時に提供することだった
- EarthlyとEarthly Satellitesは、それぞれビルドの一貫性と2〜20倍高速なCIパイプラインで有効性を示したが、完全なCI置き換え製品は十分な転換を生み出せなかった
- 新規顧客は移行コストとスクリプト書き換えの負担を重く見ており、既存のSatellites顧客はGitHub Actionsのような既存CIとの組み合わせだけで、Earthly CIの価値の**95%**をすでに得ていた
- Earthly CIは2023年10月1日に終了し、Earthlyはユーザーが既存CIを維持したまま高速なビルドを得られる方向でSatellitesへの投資を進める
Earthly CI終了と再集中
- EarthlyはEarthly CIを終了し、EarthlyとEarthly Satellitesを中心に会社の体制を再編した
- 今後注力する価値は次の2つに絞られる
- ローカルビルドと再現性
- 既存CIと併用できるEarthly Satellites
- Earthly CIは高速なCIを目指していたが、市場で十分な初期採用のシグナルを生み出せなかった
「最速のCI」の当初ビジョン
- Earthlyは2020年4月、CI/CDツールの改善を目標にスタートした
- 出発点は2つの問いだった
- CIがノートPCでも実行できるとしたら、どのような形になるのか
- 地球上で最速のCIシステムとはどのようなものか
- Earthlyが見いだした答えは、ビルドシステムとCIは同一であるべきであり、同時に分散されていなければならないということだった
- 目標は、変更の影響を受けていないビルド段階を繰り返さず、自動並列実行を提供し、ビルドのどの部分でもノートPC上で安定して再現できるようにすることにあった
小さなチームが既存CIベンダーと競争する方法
- 初期のスタートアップは、完成度、機能数、統合範囲の面で、資金・人員・評判・10年以上の先行時間を持つ既存ベンダーと競争するのは難しい
- Earthlyが取った戦略は、市場全体を説得するのではなく、特定の問題に深刻に悩む少数のチームに10倍優れた解決策を提供することだった
- 初期検証とは、製品にバグや制約があっても熱心に使う小さなユーザー集団が生まれる状態に近い
- MVPが十分な検証を得られないとき、単純に機能を積み増すやり方は、既存ベンダーが有利な競争に引きずり込まれやすい
Earthly CIに向けた3段階の計画
- Earthlyは最終目標であるEarthly CIをいきなり作るのではなく、複数の独立製品に分けて段階的な検証を試みた
-
第1段階: Earthly
- 最初のマイルストーンはEarthlyだった
- Earthlyはまず、ビルド構文とオンデマンドのビルド実行体験を提供した
- 中核となる価値は、実行環境に関係なくビルドが同じように動くビルドの一貫性だった
- 当初はローカルと別のCIで実行され、その後は数千のリポジトリで使われるようになった
- VMware、Adobe、Namely、Roche、ExpressVPN、Bluecoreなどがユーザーとして挙げられている
- 1人の開発による無資金プロジェクトで、バグや制約もあったが、実際に使われたこと自体が検証シグナルになった
-
第2段階: Earthly Satellites
- 2つ目のマイルストーンはEarthly Satellitesだった
- Satellitesは、ノートPCや任意のCIから呼び出せるリモートランナーである
- キャッシュと並列化によりCIパイプラインを2〜20倍高速化するビルド速度が中核価値だった
- Earthlyはオープンソースだったため、商用サービスが出る前から、ユーザーはBuildkitベースのリモートランナーを自前で運用して似た効果を得ることもできた
- マネージド版Satellitesが登場すると、ユーザーはリモートランナーを自分で管理しないために製品を使い始めた
- 初期のSatellitesはバグがあり、非効率で不安定だったが、同水準のCI/CD速度を提供する代替が少なかったためユーザーが流入した
-
第3段階: Earthly CI
- 3つ目のマイルストーンはEarthly CIだった
- Earthly CIはEarthlyとSatellitesを組み合わせたフルCIプラットフォームで、GitHub Actions、CircleCI、JenkinsのようなCIと競合する製品だった
- Earthlyはビルドの一貫性を、Earthly CIはビルド速度をそれぞれ狙っていたため、無料のEarthlyがEarthly CIの収益化を侵食することはないと考えていた
- しかし後になって、一貫性対速度という価値提案の違いが問題として作用した
リリース後に明らかになった移行障壁
- Earthly CIは公開され、TechCrunchでも紹介され、RedditとHackerNews向けのブログ記事も用意された
- 公開後の最初の1〜2週間で、ウェイトリストには約50件のメールアドレスが登録され、目標を上回った
- 新規顧客と既存のEarthlyユーザーの間には明確な違いがあった
- 新規顧客は「CIは構文が違うだけでどれも似ている」と見なし、Earthly CIの差別化を深く見ないことが多かった
- 会話の大半は、既存スクリプトを書き直して適応しなければならない移行コストへと流れていった
- 既存のEarthlyユーザーはすでにEarthfileへの移行を終え、Earthlyの利点を体験していたため、組織内の支援者になる準備ができていた
- 新規顧客に対しては、Earthlyが約束する利点を大規模に提供できるという評判が不足しており、短いZoom通話で「10倍簡単だ」という既存ユーザーの体験を証明するのは難しかった
既存顧客もEarthly CIへ移行しなかった理由
- 既存のEarthly Satellites顧客の大半は、CI/CDですでにSatellitesを使っていた
- Earthlyは、CIベンダーがパイプラインのトリガーだけを担当し、実際の実行はSatellites上で行われるのだから、Earthly CIの必要性は検証されたと考えていた
- しかしSatellites顧客は、すでにEarthly CIの価値の**95%**を得ていた
- GitHub Actions + Satellites構成と比べると、Earthly CIは十分に優れておらず、切り替える理由が乏しかった
- 既存のEarthlyユーザーはすでにEarthfileを使っているので移行は簡単に見えたが、実際にはさらに多くの要件があった
- GitHubプラグインのエコシステム
- codecov action
- 手動トリガー
- git tag作成ベースのトリガー
- マシンサイズの選択
- 古いビルドのキャンセル
- ビルドシークレットを任せられる信頼
- Earthly CIのMVPは最速のCIだったが、一部の重要要件を満たしていなかった
- 数人の熱心なユーザーがEarthly CIを試したものの、予算を持つ規模のある組織で2〜3人以上に広がることはなかった
- 一部のEarthly CIユーザーはその後、GitHubエコシステムとSatellitesの速度を両立するためにSatellitesユーザーへ移行した
デモ依頼がむしろ否定的なシグナルだった理由
- Earthlyは潜在顧客と100回を超える通話を行ったが、対面の会話ではEarthly CI、Satellites、Earthlyのどの製品についても利用を説得するのが難しかった
- 逆に、ウェブサイト、プロダクト主導の成長、口コミ、コンテンツマーケティングを通じてユーザーが自発的に入ってくる場合には、Earthlyの採用は日々起きており、増加傾向も大きかった
- 開発者向けツール、特に統合作業が必要なツールは、従来型の直接営業では検証しにくかった
- 最も強い否定的な適格基準は、デモを求める見込み顧客だった
- 実際に転換するチームは、Earthlyをダウンロードし、ドキュメントを読み、自分でEarthfileを書いたうえで連絡してきており、デモを必要としなかった
- 統合作業が必要な開発者ツールは、ユーザーのスケジュールに合わせて導入されるものであり、無理に売り込んだり短期間で押し進めたりするのは難しい
「CI」ではなく「build」に変えたA/Bテスト
- 当時のEarthlyウェブサイトのメッセージは「Earthly makes CI super simple」で、ファーストビューの大半がCIを強調していた
- Gavin Johnsonは、ウェブサイト内の「CI」という単語を「build」に置き換えるA/Bテストを提案した
- 文言は「Earthly makes builds super simple」に変更された
- この1語の変更だけで、メインCTAである「Get Earthly」ページの転換率が2倍に増えた
- この結果を受けて、Earthly CIそのものへの疑念が強まった
ShiftLeftで得た教訓
- Earthly以前に立ち上げたShiftLeftは、現在はQwiet.aiと呼ばれている
- 初期ビジョンは、本番環境にインストールし、ソースコードの脆弱性を悪用した攻撃からクラウドアプリを守るセキュリティエージェントだった
- この製品には、複数のプログラミング言語をサポートするコード解析器、ランタイムごとのエージェント、それらすべてを統合する分散バックエンドが必要であり、小さなスタートアップが3社分の複雑さを同時に作るようなものだった
- 1年以上の努力の末に、1つのプログラミング言語でエンドツーエンド動作を実現したが、市場の反応はよくなかった
- セキュリティ製品の対象顧客は規制の多いエンタープライズで、製品をCI/CDと本番環境の両方に入れなければならず、導入経路は非常に難しかった
- 当時は、機能をさらに追加すれば導入の難しさを克服できると考え、さらに1年半作り続けたが、市場はそれを求めていなかった
- 後になって、複雑な製品を2つの別製品に分けられることに気づいた
- セキュリティ専門家向けのコードイントロスペクター
- 市場の他のコード解析器より40倍高速な独立したコード解析器
- 最大の後悔は、シグナルが出ていたときにもっと早く止まらなかったことだった
Earthlyが下した判断
- Earthlyが整理した状況は次のとおりである
- 人々はより高速なビルドを求めている
- 人々はCIの切り替えを嫌う
- 新しいCIには差別化されていないというレッテルがあり、ウェブサイトで「CI」を見た瞬間にユーザーが離脱する
- 顧客との直接接触によるデザインパートナー型の関与は、高い移行コスト認識のため機能しない
- Earthly CIのMVPは十分な初期導入者集団を作れなかった
- 既存CIを変えずにEarthly Satellitesで高速なビルドを得られると伝えると反応が良くなる
- 核心的な問題はEarthly CIの機能不足ではなかった
- 有望な初期製品であれば、機能不足を受け入れてでも利点を得ようとする集団が存在するはずだが、Earthly CIではそのレベルのシグナルが十分ではなかった
- そこでEarthlyはEarthly CIを終了し、うまく機能しているEarthlyとEarthly Satellitesに集中することを決めた
終了スケジュールとユーザー移行
- Earthly CIは2023年10月1日に終了する
- Earthly CIはベータ・実験段階として表示されていたが、Earthlyはユーザーの移行を支援する
- EarthlyはどのCIとも一緒に動作するため、Earthly CIから離れる移行は容易だと見ている
- 高速なビルドを引き続き求めるならEarthly Satellitesを接続でき、Satellitesには無料ティアもある
- 移行支援はEarthly Slack communityで直接提供される
Satellitesへの今後の投資方針
- Earthly Satellitesは、高速で一貫したビルドだけでなく、ユーザーが自分のCIを維持できることから成長シグナルを得ている
- Earthly CI終了で確保した時間は、Earthlyコミュニティが要望してきた機能への投資に充てられる
- CPU、メモリ、ディスク、ネットワークI/O使用量を含むSatellite metrics
- ローカルビルドとSatellitesビルドの両方に対応するWeb UIのBuild history
- 変更されたファイルがビルドに影響しない場合に即座にスキップするAuto-skip
docker buildの高速な代替として、Satellites上でDockerfileビルドをリモート実行する機能- self-hosted remote Buildkitをより強力にサポートする版であるself-hosted Satellites
- 単一ビルドを複数のSatellitesに分散して高速化する機能
- 完全分散型サーバーレスSatellitesであるCompute v2
- Earthly Satellitesは、どのCIとも連携できるリモートビルドランナーであり、Earthly Cloudを通じて利用できる
- Earthlyは、一度書けばどこでも実行できるビルドの一貫性を提供し、CIの失敗をローカルマシンで簡単に再現できるよう支援するオープンソースのビルドフレームワークである
1件のコメント
Hacker News のコメント
オープンソース化するときに、中核的な価値をすべて手放してはいけない理由をよく示している記事だと思う。Earthly がオープンソースだったため、Earthly Satellite のユーザーはすでに Earthly CI の価値の 95% を享受していた。
オープンソースは大好きだが、ビジネスモデルにオープンソースが含まれるなら、差別化要因が必要だ。単にものすごく速いという以上に、人々がクレジットカード、さらには経理の購買発注プロセスを持ち出す理由が必要になる。
GitLab は CI/CD を有料顧客に制限し、Travis/CircleCI はビルド時間やクレジットを制限し、Azure DevOps は悪魔的で、ArgoCD は複雑だ。GitHub Actions はランナーを動かすハードウェアがあれば悪くなく、エンタープライズでは Jenkins 群に慣れていることが多い。
元 DevOps ディレクターとして最初に尋ねるのは、「自前でホスティングせずに購入させる機能は何か」だ。自前で運用する技術力があり、自分のクラウドと DevOps パイプラインを自社のビジネスに合わせて運用できるなら、なぜあなたたちにお金を払うべきなのかを説得しなければならない。
ソフトウェアの動作に必須の機能を隠せという意味ではなく、サポートやエンタープライズ級の連携のようなビジネス機能を有料にする、といった話だ。上級ユーザーは自分でより多くをサポートするので、支払いが少なくて済む階層型もあり得るように思う。
残ったユーザーを有料に転換することはできるかもしれないが、かなり大きな賭けだ。最近の良い逆転例は Docker かもしれないが、そこでは厳格なオープンソースを放棄し、議論の多いライセンス・製品変更を行う過程が必要だった。
「オープンコア」の外側のコードを読んだり、バグ修正をコントリビュートしたり、自前でホスティングしたりできないのは非常にもどかしく、オープンソースライセンスとソース公開ライセンスを分ける要素は、私にはあまり必要ではない。
水を差したくはないが、これは文字どおりコピペ製品に近い。
Jenkins、Google Borg、Cloud Foundry、Concourse Pipelines があり、出自を見ると Ex-Google、Ex-VMW、RabbitMQ なので驚きでもない。
原文の著者が上記ツールの源流近くにいたわけではないとしても、少なくともその話のいとこくらいではある。
販売サイクルは長く、連携にはセキュリティやネットワーキングを含む複数の軸で経営陣の同意が必要になる。
良いものを作ったのは確かだが、上流の問題があまりに複合的で、カスタムと汎用商品の間を行き来し続ける領域における、あまり中身のない話のように感じた。監督不在からマイクロマネジメントまで、未熟さから「いつものやり方」を手放せないほどの過剰な経験までが混ざっている。
不人気な見方かもしれないが、ツールチェーンを売りながら問題の海を沸騰させているようなものだ。ビジネスと技術は水のように抵抗の最も少ない穴を探して流れ、その過程で「中核事業」の基盤を侵食することもある。私の経験では、指針や「育成戦略」のように機能しつつ、取り外し可能なガードレールを備えたツールチェーンが最大の報酬をもたらした。
「速い」は売り文句にならない。開発者は遅いパイプラインを望んではいないが、だからといって速いパイプラインを望んでいるという意味ではない。
パイプラインの速度は、パイプラインサービスのオーバーヘッドよりも、パイプラインをどう構成したかに大きく左右されるし、他の CI/CD サービスもすでに非常に速い。たとえば CircleCI でさえ GitHub Actions や GitLab CI/CD と比べて売りやすいわけではないのに、このサービスはどう差別化されていたのか。GitHub/GitLab/CircleCI などに比べて実質的な価値を加えていたのか。数分かかるビルドでミリ秒を削ることは答えではない。
失敗した理由は、マーケティングが露骨に雑で、かなり不誠実だったからだ。
Jenkins、Actions、Earthly のどれでコンパイルしても、同じビルドノードを使うならコンパイル時間は同じはずだ。CI が数秒で起動する状況で 20 倍速いと主張しても、あまり意味はない。
キャッシュと並列実行は CI では昔からある概念で、現代的なビルドシステムならどれも可能だ。
CI の核心はフィードバックだが、協業やデータを上位に引き上げる側面はあまり見えなかった。詳しく見たわけではないが、これが前面に出ているべきだ。最後に、ビルドのために二度と DSL を導入したくない。
高速なCIとは、いったいどういう意味なのか？
CIはビルドを実行して失敗を知らせる、肥大化しすぎたシェルスクリプトのようなもの。一般的にはビルドツール自体が遅すぎるので、CIランナーのコストはそれに比べればほぼゼロであるべき
高速なCIが欲しいなら、tsc、clang、rustcなどが速くなるべきであって、それらを
execで呼び出すプログラムがさらに速くなるべきという話ではないもう少し本題に沿って言えば、CIを売っていて事業が失敗したのなら、価値を提供できなかったから。人々はあなたなしでもビルドスクリプトを問題なく回せる
execを呼び出すプログラムがより速いという話ではなく、そもそもexecを呼び出す必要がないことを分かっているプログラムの話何を測定したのかは分からないが、一例を挙げると、Jenkinsのデフォルトのランディングページは速度面では惨事。クラスタ全体の最近のビルドデータをあちこちに表示しようとし、それほど大きくないクラスタでも、各ビルドを実行している個別ノードから数百〜数千件の項目を取得しなければならない場合がある
デフォルト動作を抑止する特定の設定なしにランディングページを読み込むだけで、Jenkinsを数えきれないほど落としてきた
CIサーバーは通常、独自のデータベースを持ち、ジョブ、成果物、ユーザー、シークレット値といったあらゆるCIエンティティを管理する。かなり大きくなり得るし、適切なインデックスなどにもきちんと気を配る必要がある
CIには複数のランナーがあり、それらはしばしば動的にプロビジョニングされる。VMやDockerイメージをランナーノードに配布しなければならないと考えればいい。これをクラスタに高速に分散するのも簡単ではない。成果物もクラスタ全体に分散したいはずだが、これも時間とリソースを食う
CIには事実上、ガベージコレクション、レポート、自己診断のための独自の帳簿管理も必要になる。十分に大きなクラスタでは、レイテンシを下げるために特別な努力をしなければ、これらすべてが非常に高いレイテンシを生み得る
ccacheは聞いたことがある？
だが本当に、「高速なtsc/clang/rustcさえあればいい」というのはあまりに素朴すぎる。CIという分散システムでビルドを高速化するには、このキャッシュをどう分散するか、ビルドをどうモジュール化するかも解かなければならない。プログラミングで最も難しいものの一つがキャッシュの無効化だという話を聞いたことがあるだろうが、あれは一部しか冗談ではない
かなり汚いGitHub Actionsスクリプトを整えるのに時間がかかったが、デバッグサイクルが10分だったからだ
サービスを単に終了するだけで、会社全体を畳むわけではないとのことで安心した。このツールが本当に好きで、採用ページをよく覗いていたほどだった
Earthfileの構文はDockerfile構文の非常に合理的で漸進的な進化であり、Dockerfileだけでは不可能だったり非常に不自然だったりした多くのことを簡単にしてくれる
DockerがBuildKitとbuildxを導入したとき、Dockerfileを汎用ビルドシステム、つまりコンテナだけでなくファイル成果物なども作る用途に推そうとしていた記憶がある。Earthlyはそのアイデアを実際にうまく実装していた
満足して使っているが、まだお金は払っていない
この文章だけでは、何が起きたのか正直かなり理解しにくかった。何度か読んでも、用語がまだ混乱する。少なくとも2つの別々の問題があったように思う
既存のCI YAML、つまりGitHub/GitLabから、EarthlyというMakefile/Dockerfileの混合型へCI設定を移行する問題
既存のCIから、Earthlyがホストするサービスへジョブ実行基盤を移行する問題
1つ目は難しいことだと思っていた。言語を変えるには数カ月、場合によっては数年かかることもあるから
でも、ブログ記事が何を言っているのかよく分からない。その部分は検証したと思っていたのだが、人々が移行できたという意味ではないのか？
ところが最後には検証されていなかったと言っている。顧客は1つではなく、2回の移行をしなければならなかったということなのか？
では今はどうなるのか？ Earthlyの構文は維持しつつ、CIは諦めるということなのか？ 移行が難しい部分はその構文ではなかったのか？ まだ混乱している
要点は、ずっと速いビルドがキラー機能だと仮定したものの、作る前にその仮定を検証していなかった、ということなのか？ それとも、ユーザーをきちんとセグメント化できず、高額顧客のニーズが違うことに気づかなかったということなのか？ あるいは、有料顧客の本当の課題を解決するものを、単に無料で出してしまったということなのか？
そして、このやや混乱した文章をCEOが書いていることを考えると、その混乱が単なる編集不足なのか、それともその過程全体を通じて社内にも実際に多くの混乱があったのか気になってくる
かなり昔、Steve Blankが「Founders and dysfunctional families」[1]という記事で、多くの創業者は混乱の中で育ったため、混乱を管理するのが得意だと書いていて、それは自分にも確かに当てはまる。彼はさらに、成功と失敗を分ける差は、創業者が非混乱状態も扱えるかどうかにかかっている場合がある、と付け加えていた
それができない創業者は、自分が得意な混乱レベルへ戻そうとして、自分の会社に「組織的な手榴弾」を投げ込む傾向がある。その観察は、その後何年にもわたって何度も私を立ち止まらせ、考えさせた
[1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
人々のCIは時間がたつにつれて、会社がそれぞれのソフトウェアを作り、デプロイする方法をすべてカプセル化した混合モデルになる。CIをAirflowのような任意の自動化ジョブ実行基盤として誤用している状況を想像すればよい
移行は、人々が以前に知っていたことをまずリバースエンジニアリングする作業から始まり、その後になって初めて、それらすべてを解きほぐして別の方法で表現できる
誰も世界を止めて、それを整理したいとは思わない
この文章は、書き手が問題に近すぎて混乱しており、詳細に入る前に外部者の視点から説明する必要がある。それでも必要な情報はあるように思う
結果として、言語別のビルドシステムと、それを実行する継続的ビルドシステムとの間にカプセル化レイヤーを作ったように見える
比較対象としてはBazelのようなものがあるが、Bazelは何でもこなす一方で、完全に導入するには、言語別ビルドシステムをBazelのビルド言語に置き換えることに全力で取り組む必要があり、動作させるためにソースファイルの位置を移すことも多い
これは言語自体のビルドシステムを使うやり方に比べると馴染みにくいかもしれないが、言語に独自のビルドシステムがないCプログラマーにとっては自然かもしれない。Javaもいくつもの残念なビルドシステムを経た後、不幸にもGradleに落ち着いた
言語別ビルドシステムは、言語ごとに慣習やエコシステムが異なるため、結局すべてを行うわけではない。現代的なものは、自分が得意な範囲を理解し、そこにとどまる
そのため、複数の言語や成果物を実際に理解するツールは、しばしばシェルスクリプト、makefile、Dockerfile、継続的ビルド自体になる。手作業で行うことさえある。彼らが改善しようとしているレイヤーは、まさにこの部分だ
ただし、彼らの方式がなぜ優れているのかについての根本的な洞察は、まだはっきりつかめない
以前、仕事の都合で Earthly を少し調べたことがある。GitLab、Azure DevOps、Jenkins、ひょっとすると GitHub Actions まで、複数の CI プラットフォーム向けの連携を書く必要があったためだ。
結局、非常によく似た製品である Dagger を選んだ。複数の CI システムと連携できる、もう一つのよくできた BuildKit フロントエンドで、当時パイプライン定義に使っていた DSL がより良さそうに見えたからだ。
しかし、この判断を深く後悔することになった。Dagger の開発者たちがその言語を事実上捨て、人気プログラミング言語向けの SDK を次々に出す方向へ進んだからだ。どれも命令型で、どれもチューリング完全であり、私の考えではこの領域にはあまり合っていない。
そのため今はまた地獄に戻って、これらすべてのシステムと手作業で連携しており、この手のツールを再びスタートアップに任せるのはためらわれる。
私にとっては、今でも Earthly のようなものの最も魅力的なユースケースはここにある。「プッシュして何が起きるか見る」というのがほぼすべての CI システムの標準だが、ひどいワークフローだ。
大きな組織で、さまざまな CI/CD プラットフォームを使うチームを支援しなければならないなら、Earthly のようなものはかなり多くの苦痛を減らせる。だが魅力は、さらに別の CI を追加することではなく、まさに既存の CI プラットフォーム対応にある。
以前の CUE 実装の主な問題は、BuildKit の有向非巡回グラフのソルバーと CUE の有向非巡回グラフのソルバーを合わせようとした点で、両者は逆方向に動作していた。
約 3 年前、CUE の専門家としてこの問題を解決する手助けをしようとした。Dagger には SDK のほうがはるかに良い解決策だと思う。
好むと好まざるとにかかわらず、業界のかなりの部分がこの方向へ移っている。Pulumi も別の例だ。命令型のクラウドインフラには納得させられたし、ビルドもある程度はここに合う面があるように見える。
付け加えると、新しい CUE + Dagger 構成を探ってみる予定だが、以前の Dagger エンジンとは違う動きになるはずだ。
要点は、宣言型レイヤーを静的な CUE 設定から動的な GraphQL クエリへ移したことだ。そして GraphQL スキーマから複数言語のクライアントライブラリを生成した。
そのため、以前と同じように有向非巡回グラフを宣言的に構成できるだけでなく、好みのどの言語でもそれができる。純粋な GraphQL で直接 DAG を実行することもできる。ブラウザからすぐ試せる https://play.dagger.cloud を見ればよい。
役に立つ比喩は SQL だ。SQL は宣言型言語だが、通常は別の言語、しばしば命令型言語と一緒に使われる。
この説明が役に立ち、Dagger をもう一度検討してもらえればうれしい。
「2〜20倍速いビルド」という表現が記事全体に何度も出てくる。何と比較しているのか。ベースラインがなければ、この文句は価値のないマーケティングのたわごとだ。
「なぜスタックを単純化しないのか。CI ベンダーと私たちの両方に払うのではなく、私たちだけに払えばよいのではないか」という部分については、彼らが「お金を払っている」CI が残りのスタックと一緒に提供されているからだ。GitLab と GitHub は、単なる CI 製品よりはるかに多くのものを備えている。
「新しい人たちは Earthly CI を懐疑的に見て、すべての CI は同じで構文だけが違うと考え、その先を見なかった」という部分も理解できる。
私たちは CI そのものにはあまり関心がなく、ただ必要で、正しく動けばよい。
アプリに動作する CI マニフェストがあれば、新しいアプリでは同じマニフェストを数か所検索して置換するだけで使う。最初に作るときの苦痛はあるかもしれないが、例を見ても GitLab で同じことをするより特に簡単そうには見えない。
正直なところ、GitLab や GitHub の CI 設定を受け取ってその場で Earthfile にする変換器を入れていれば、少なくとも試してもらうことはできたのではないかと思う。