TechTargetは「CI/CDパイプラインに関するBuildkiteの取り組み」に関する記事を公開した。Buildkiteと同社の大規模ユーザーは、プラットフォームエンジニアリングの時代において「CI/CDパイプラインとテストは開発者チームの管轄下に置くべきだ」という考えを変えていない。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
TechTargetは2024年10月11日(米国時間)、「CI/CDパイプラインに関するBuildkiteの取り組み」に関する記事を公開した。Buildkiteは設立から10年間、エンタープライズIT業界で注目されることは少なかったが、開発者中心という考え方をさらに主流に近づけようと、自社製品の拡大を続けている。
Buildkiteは過去10年間、CI/CD(継続的インテグレーション/継続的デリバリー)パイプラインプラットフォームを市場に展開しており、クラウドネイティブ企業の中でも著名な企業を顧客として獲得してきた。同社の強みは、自社インフラ上で運用できるビルド実行環境「セルフホステッドランナー」(作業エージェント)にあり、これによって企業はマルチクラウド環境でのビルドを効率的に管理できる。高いスケーラビリティを求める企業は、このランナーを活用してパフォーマンスを最適化できる。同社は、SaaS(Software as a Service)バックエンドとともに、一部の顧客に対してホスト型ランナーも提供している。
BuildkiteのCEOと同社の顧客は、「CI/CDパイプラインを開発者から隠し、別のチームに管理させる」というプラットフォームエンジニアリングのトレンドに反対の立場を取っている。
BuildkiteのCEO、キース・ピット氏は「本当に優れたソフトウェアエンジニアリングチームは、デリバリーを製品の一部として扱う」と語る。
「『自分のチームにはCI/CDを気にしてほしくない』などと言うエンジニアリングリーダーは、間違ったアプローチを取っている。開発者が自ら書いたコードが顧客の手に届くまでのプロセスについて執着するくらいが理想的だ。むしろデリバリーシステムを開発者に担当させない方がデメリットがある。担当から外れた開発者はやがてデリバリーシステムを恐れるようになり、その結果、デリバリーシステムは劣化し、崩壊し始めるだろう」(ピット氏)
2024年10月上旬、Buildkiteは開発者向けプラットフォーム市場での存在感を高めるため、新たな機能、サービスを発表した。追加されるのは、パッケージレジストリ「Package Registries」、テスト自動化機能「Test Engine」、ホスト型モバイル開発サービス「Mobile Delivery Cloud」の3つだ。
Package Registriesは、2023年に同社が買収したPackagecloudの技術を基にしており、異なるプログラミング言語向けのオープンソースアーティファクト管理を一元化する機能がある。さらに、パッケージデータのセルフホステッドストレージや、プロベナンス(起源)証明といったソフトウェアサプライチェーンセキュリティ機能も備えている。
Test Engineは、CIにおけるテストの有効性を評価し、信頼性に欠ける“不安定なテスト”を削除(またはリファクタリング)するよう推奨する。また、不具合の修正を担当する開発チームを自動的に割り当てる機能も備えている。
Mobile Delivery Cloudは、Appleの「Apple M2」を使用したMacハードウェアで構築された事前構成済みのインフラストラクチャと最適化されたキャッシングを提供し、顧客が「macOS」「iOS」のコードをテストできる環境を整える。
「Buildkiteのハイブリッドモデルとセルフホストランナーという2つのアプローチによって、Buildkiteパイプラインをスマートフォンや自動車といった独自のハードウェアにデプロイできる。ただし、iOSアプリケーションのバックエンド依存関係を処理するためのホスト型Macコンピューティングの問題はまだ解決されていない。これを提供するハイパースケーラーもあるが、高度に仮想化されていることが多く、使い勝手が悪く、利用コストも高い傾向にある」(ピット氏)
これら3つの新機能は全て、Buildkiteの「Scale-Out Delivery Platform」に含まれており、2024年10月から一般提供されている。「Proエディション」の価格はアクティブユーザー1人当たり月額30ドルからで、企業向けのボリュームディスカウントやカスタマイズオプションに対応した「カスタムEnterpriseエディション」も用意されている。BuildkiteのCI/CDパイプラインツールの価格は、以前はアクティブユーザー1人当たり月額19ドルからだったため値上がりすることになるが、ピット氏は「既存の顧客がアップグレードを強制されることはない」と説明している。
パッケージマネジャーやテスト自動化ツールなどについては、既に別の製品を使っている企業がいるかもしれない。だが、これについてピット氏は「Test Engineと直接競合する商用製品は多くなく、多くのチームがこうした仕組みを自前で構築している」と語る。
これまでのところ、Buildkiteの代表的ユーザーは、Webをベースとし、テクノロジーを重視する企業だ。例えばeコマースのサービスプロバイダーであるShopify、ホスピタリティオーケストレーターのAirbnb、ライドシェア企業Uberなど。ランナーをセルフホストで使えるのに加えて、Buildkiteのアーキテクチャは高い並列性をサポートしており、数千人の開発者が1日に数千もの変更を比較的短期間で実施できるという。
IDCでアナリストを務めるジム・マーサー氏はこう語る。
「Buildkiteはある種の“次の段階”として選択されるものであり、最初から使うツールではないかもしれない。一方、非常に大規模なアプリケーションを複数抱えるエンタープライズには特に魅力的なツールだ。ビルドするたびに開発者が待たされるのは事実であり、どのチームもスピードアップを望んでいる」
ID検証サービスプロバイダーPersonaに、Shopifyは大きな影響を与えた。それは、同社のコアアプリケーションもShopify同様「Ruby on Rails」で構築した「モノリス」であるためだ。Personaでインフラ担当の責任者を務めるイアン・チェサル氏によると、同社が2022年にインフラを評価した際に「CircleCI」「Jenkins」「GitHub Actions」「Bitbucket」とともにBuildkiteが候補に挙がったという。
「Buildkiteが大きく際立っていたのは制限なく並列処理を実行できる点だ。これによって「RSpec」(Rubyコードのテストツール)のテストスイートを大規模にリファクタリングしたり、選択的テストの実行方法を模索したりする手間を省けるようになった。特にRubyにおいて、これらの作業は非常に困難だ」とチェサル氏は語る。
最終的にPersonaは、ソースコードのバージョン管理をBitbucketから「GitHub」に移行し、CI/CDにBuildkiteを採用することでテストにかかるクラウドのコストを50%削減した。Buildkiteのセルフホストランナーを「Google Cloud Platform」(GCP)の安価なスポットインスタンスに配置することで、20分以上かかっていたテストスイートの実行時間を10分未満に短縮することに成功した。
チェサルによると、PersonaはTest Engineのβ版をいち早く採用した。同社にとって、メインブランチを常にクリーンでデプロイ可能な状態に保つことは非常に重要で、かなり前から「モノリスのRuby on Railsアプリケーションにマージキューを導入したい」と考えていたという。
「だがそのためにはテストが安定していることが絶対条件だった。不安定なテストがあると、プルリクエストをマージするのにどんどん時間がかかってしまうからだ」
Test EngineによってPersonaにおける不安定なテストの割合を40%から10%に減少させることができた。2025年にはPackage Registriesを試す予定だという。現在PersonaはJFrogの「JFrog Platform」からBuildkiteに成果物(アーティファクト)を移行するためにエグレスコスト(データの外部転送にかかる費用)を支払っているが、Package Registriesによってこのコストを削減できる可能性があるからだ。
「このエグレスコストが別のCIプロバイダーを検討するきっかけの一つだった。Bitbucketは『Amazon Web Services』(AWS)にホストされている一方で、PersonaはGCPを利用している。そのため、アーティファクトレジストリからCIシステムにアーティファクトを移行させるために、月1万ドル以上のコストが発生していた。パイプライン側やわれわれのキャッシュ処理の効率性の問題もあるが、クラウドベンダー間のデータ転送コストは無視できないものだ」(チェサル氏)
DBaaS(Database as a service)を提供するPlanetScaleも2022年にBuildkiteを採用し、大規模ビルドサーバの開発スピードを向上させた。同社のCTO(最高技術責任者)であるニコラス・ヴァン・ウィゲレン氏によると、32〜64CPUを搭載したサーバを利用しているという。それまでPlanetScaleがCIに使っていたGitHub Actionsは「一部のビルドプロセスで複数のソースコードリポジトリ間の複雑な調整が必要」という理由から、現在も同プラットフォームの一部を使用している。
「GitHub Actions側にはGitHubネイティブの機能が幾つかあるため、統合の前にBuildkiteがその機能をサポートできるかどうか確認する必要がある。GitHub ActionsのワークフローをBuildkiteに自動インポートするといった機能があれば申し分ないのだが、なかなかその夢はかなわない」(ウィゲレン氏)
本稿執筆時にBuildkiteに確認したところ、同社には他のベンダーからの移行を支援する専門サービスチームがあり、変換用のパッケージ化されたパーサーの開発に現在取り組んでいるさなかだと同社の広報担当者は答えている。
ヴァン・ウィゲレン氏はTest Engineを試してみたいと語る。
「開発者の作業時間の半分は、コードが正常に動作することを確認することに費やされている。つまり、テストを実行し、書き加え、修正する作業だ。そのテストを可能な限り早く実行し、結果を迅速にフィードバックできる機能は、私にとって利益そのものだ。全体的に見れば、ビルドサーバハードウェアにかかるコストは安価だと言える」(ウィゲレン氏)
IDCのマーサー氏によると、Buildkiteは「DevOpsプラットフォーム」という言葉を使わないようにしているが、今回追加された新機能によって、HarnessやJFrogなど過去5年間で機能を拡充してきた他のCI/CDパイプラインベンダーと競合することになるという。
「Buildkitは、プラットフォームエンジニアが開発者向けパイプラインを構築するために使われる可能性はあると考えている。Buildkiteのリーダーたちは『DevOps』や『DevOpsプラットフォーム』といった表現を避けているが、拡張された機能を見る限り、その方向に進んでいるように感じられる」(マーサー氏)
GitLabやGitHubといった他のDevOpsプラットフォームベンダーは、自社製品で多くの機能要件を満たすことができ、大企業で購入決定権を持つビジネスリーダーの間で高い知名度を誇っているとマーサー氏は指摘している。
「Buildkiteは確かに開発者にとって魅力的だが、次に考えなければならないのは、『誰がこのソフトウェアを購入するのか』という点だ。エンタープライズレベルでの魅力を問われる場面では、例えば『なぜMicrosoftやGitHubとの大規模契約ではなくBuildkiteを選ぶ必要があるのか』という疑問に答られなければならない。この答えを探すことがBuildkiteにとっての課題となる」(マーサー氏)
Copyright © ITmedia, Inc. All Rights Reserved.