ビルドシステム対CI：違いと意義

ビルドシステムとは何でしょうか？そして、また、ビルドシステムとCIは何が違うのでしょうか？この記事では、「ビルドシステム対CI」の疑問について解説しています。

若い人たちへ、まず歴史の話から

私は個人的にビルドシステムを継続的インテグレーションシステムと同一視しています。少なくとも、最近はそう思っています。20年前はそうではなかったかもしれません。結局のところ、私たちは同じコインの裏表を比較しているのです。この問題は、ソフトウェア開発において昔から存在するものです！というのは冗談ですが。「ビルドシステム」という言葉は、60年代ごろから英文で使われるようになりました。

ソフトウェアが普及し始め、メインフレームがクレーンを使って本社に設置されるようになった頃です。ソフトウェアとのやりとりを楽しむ顧客はいませんでした。CDパイプラインなんて夢のまた夢で、リードタイムやデプロイメント手順、リリースについて話す人さえいませんでした。

Dave Farley氏、Jez Humble氏、Nicole Forsgren博士など、CDツールやCDプロセスについての考え方を変えた立役者たちは、まだ生まれてもいなかったのです。ソフトウェア開発の実践は、開発中の技術であり、その後、コンパイラーやトランスパイラー（トランスコンパイラー）など、当時流行していたあらゆる技術が生み出されました。少なくとも、ビルドツールの初期バージョンのようなものはありました。

しかし、その後、新しいものがタイムライン上に転がり込んできました。バージョン管理は開発環境において、おそらく最高の新機能だったでしょう。開発環境において、バージョン管理はおそらく最高の新機能だったでしょう。Googleによると、継続的インテグレーションは、ソフトウェア開発における２番目のカテゴリーとして、1990年代に一定の成熟度に達したといいます。アプリケーションはあらゆる組織の最優先事項となり、オープンソースは爆発的に普及し、ビルドサーバーは極めて厄介なものになりつつあったのです。そのため、私たちは、ソフトウェア開発プロセスを強化し、以前の手作業によるプロセスを継続的に自動化するために、最新かつ成熟したCIを導入しました。

NISTの定義は異なるが、こう考える：ビルドシステム対CI

多くの人にとって同義語である２つの用語について考えてみたいと思います。ただし、この議論のポイントは、同じ意味かどうかよりも、むしろ開発者がどのように使いたいかということです。

この２つの概念を分ける明確な線は、ビルドシステムが、通常は開発者のマシン上でローカルに動作するツール（またはツールのセット）を指していることです。継続的インテグレーションは、当初は ソースコードのリポジトリーをバックグラウンドでポーリングして、プロセスを起動するための変更を探すデーモンでしたが、今では開発者が頻繁にコードの変更を中央リポジトリーにマージして、自動ビルドとテストを実行するためのベストプラクティスのセットとほぼ同じ意味になります。しかし、継続的インテグレーションの利点やCIとは何かを知りたい場合は、別の記事を参照してください。

興味深いのは、やはりその細部にあることです。ビルドシステムの背後のニュアンスは、開発者が惹かれる傾向にある孤立感です。コーディングには高度な抽象化と膨大な量の集中力が必要ですが、開発者の欲求にきめ細かく対応したマシンがあれば、その要求に応えることができるのです。メインブランチ、フィーチャーブランチ、設定ファイルなど、扱うものはたくさんあります。ローカルでは、あらゆる依存関係がうまく管理され、IDEは開発者が最も好む特定のワークフローにパーソナライズされているなどです。しかし、その作業は、たとえ生産性のピークであっても、高速なビルドはできても統合が少なく、最終的にはエンタープライズレベルの開発者チームにおけるマージの衝突という恐怖に連鎖してしまうだけでしょう。コミュニケーションのスピードと統合の頻度が遅すぎて、解決までの期間が長いコンフリクトが発生しやすいので、どの企業も望んでいるコーディング哲学とはいえません。

それこそが、CIが継続的デリバリー（CD）手法の一部として成功した理由なのです。このコンセプトは、Kent Beck氏がXtremeプログラミングで唱え、Martin Fowler氏が2000年の論文で普及させ、その後2006年に改訂および更新され、CIツールとしてはCruise Control（Thoughtworks開発）が最初の実装となりました。

ビルドシステムは、どのCIシステムでも核となるものですが、最近のCIシステムは、Continuous Build, Occasional Integration（CBOI）を奨励せず、コラボレーション、頻繁な統合、継続的なコードレビューなど、最終的にソフトウェアの品質、セキュリティー、開発チームの速度と信頼性に貢献する多くのベストプラクティスを促進します。CIの素晴らしさは、システム（または、少なくとも、開発者が変更によって何も壊れないと確信するために必要な部分、つまり彼らのマイクロサービスも）を完全にスピンアップし、変更と統合し、構文、テスト、スキャナーなどを実行して、成果物をユーザーに提供するための健全性テストの結果を返すことができることです。

結局のところ、この違いは「統合」の部分に帰着します。継続的アプローチとは、プロセスを実行するために常に準備された状態にあるシステムの特性を指します（毎週または毎月ではなく、毎日または１日に何度も小さな変更が行われることを想定してください）。しかし、統合の本当の意味は何でしょうか？最も浅い定義では、統合テストを実行することが含まれるでしょう。つまり、異なるチームや個人のコードが、コードベース自体が提供することを意図している全体的な機能を壊していないかどうかを知ることができることです。この文脈での統合には、高レベルのシンタックスチェック、リンティング、ある種の静的コード解析も含まれます。

本題：なぜこれが重要なのか？

ビルドシステムかCIシステムか、あるいはCI（より可能性が高いのはCBOI）による継続的デプロイメントを本当に行っているのかどうかは、ほとんどの場合どうでもいいことです。クリエイターである開発者は、自分の仕事に集中したいものです。そのためには、パイプラインを提供する必要があります。それは、ローカルで動作していても、チームメンバーとパブリッククラウドインスタンスで共有していても、必要なときに即座に利便性の高い形で提供されるものであることが必要です。

構成は、民主化されるか、あるいは完全に抽象化され、セルフサービス方式である必要があります。Jenkinsのような従来のCIシステムは、この点で失敗し、開発者やビルドエンジニアに、古いデーモンが行っていたような、ディレクトリーやリポジトリーの変更を調べる大量のGroovyコードで負荷をかけることになったのです。これについては、Dependency / Integration Hell that is Jenkinsについての記事をお読みになってください。

しかし、多くのエンジニアがファイルを編集し、リポジトリー構造が複雑で、ガバナンスとIPへのアクセスがビジネスにとって重要な大規模組織においては、スケーラビリティーに欠けるというのが実情です。その代わり、CIは現代のソフトウェア開発チームが求めるものの中核に位置します。プラットフォーム、つまりクラウドネイティブのセットアップの上にあるレイヤーは、DevOpsがベースラインのパイプラインを設定し、開発者がそこから必要なものをセルフサービスで提供することを可能にするのです。

また、CBOIは、エンジニアが単独で作業を行うという生来の習慣を超えた、より大きな何かの徴候でもあるのです。システム全体を起動させ、必要なチェックとスキャンを全て通過させることは、どんなインフラでもこなせることではありません。キューと遅いビルド、そして遅いソフトウェアデリバリープロセスは、最も頻繁に発生する結果です。しかし、例え実現可能であっても、完全なシステムとそのテストを毎回実行することの経済的トレードオフは、信じられないほどコストがかかります。新しい機能に対して古き良きTDDを実践するならば、テストスイートは増えるばかりで、ビルドプロセスはよりがっしりしたものになるでしょう。新しいコードは、ローカル環境かパブリッククラウドかにかかわらず、ソフトウェアビルドファームで実行するコストが高くなります（これは、コストを下げようとするあらゆる試みに逆行するようなものです）。コンピュート、ネットワーキング、ストレージの料金は、あえて言うならば、高くつくでしょう。

CIとは、このように、繰り返されるパターンから学ぶことでもあるのです。結局のところ、CIパイプラインは何度も何度も繰り返されるものであり、ほとんどの場合、増分的な変更のみが行われ、最終的に本番環境には最小限の変更しか行われません。QAチームとそのテスト環境には過剰な負荷がかかっており、そこにある最高のCIシステムは、変更点のみを検出し、そのコードのサブセットに必要なテストを適用することができるインテリジェントな機能を備えています。

結論

最終的にチームは、適切な開発者エクスペリエンスを確立し維持することが、進むべき道であることを理解することになります。開発者が自分のビルドシステムで全てをローカルに動かしているか、共有CIサーバーで共同作業しているかは、実際の問題ではないかもしれません。

この論文で指摘されているように、開発者はインパクトを与えることを望んでいます。自分の苦労が解決につながることを望んでいるのです。そのためには、開発者が使用するシステムが、自分たちの貢献がどのようにエンドユーザーに届けられているか、フィードバックを提供する必要があります。このフィードバックの仕組みがもたらす自信こそが、開発者に力を与え、成長速度の向上を促すのです。この調査結果を引用すると、「開発者は、配信プロセスに時間がかかる場合、配信が複雑すぎる場合、またはメインラインに頻繁に配信することに明白な価値がない場合、その配信頻度を減らすだろう」と述べています。

だから、Harnessはこのような作りになっているのです。特に、開発者に確かな体験を提供するためです。コードのコミットからコードの検証および更新までのフィードバックサイクルを短縮させます。このことを念頭に置いて、Harnessのエンジニアとデザイナーは、開発者の信頼を高め、複雑さを抽象化し、リスクを低減するCI/CDプラットフォーム（さらにフィーチャーフラグ、クラウドコスト管理、および追加製品）を構築しています。ぜひ一度、Harnessをお試しください。

まだ導入に踏み切れないようでしたら、最適なCIツールや、Harnessの継続的インテグレーションプラットフォームについて、さらに詳しくご紹介していきますので、お気軽にお読みください。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。