CI/CDは何がまずいのか、コード作成から本番デプロイまでの時間短縮に注力：継続的デリバリーの遅れを問題視

オブザーバビリティツールを手掛けるhoneycomb.ioの共同創業者でCTOを務めるチャリティ・メージャーズ氏が、CI/CDの問題点を指摘した。CIにばかり注力せず、CDにも気を配るべきであり、特にコード作成から本番環境へのデプロイまでの「時間の短縮」にフォーカスすべきだという。

[＠IT]

　オブザーバビリティツールを手掛けるhoneycomb.ioの共同創業者でCTO（最高技術責任者）を務めるチャリティ・メージャーズ氏が2021年1月19日（米国時間）、開発者向けのQ＆Aサイト「Stack Overflow」のブログに記事を寄稿し、コード作成から本番環境へのデプロイまでの時間の短縮にフォーカスしてCI/CD（継続的インティグレーション／継続的デリバリー）に取り組むべきだと提言した。

　以下では、メージャーズ氏の主張の概要を紹介する。

　CI/CDは導入が進んでおり、特にCIはこの10年で取り組みレベルが向上している。だが、その一方で、CDは立ち遅れている。

　CI/CDはプロセスと方法論を指す用語だ。メインリポジトリにマージした全てのコードをテストし、いつでも本番環境にデプロイ可能な状態にしておき、自動的にデプロイできるようにする設計を目指す。

　CI/CDの目標はソフトウェア変更のリードタイムを短縮することにある。アドレナリンやドーパミンによって促される人間の学習機構が、コード作成からリリースに至るフィードバックループにマッピングできるような短い間隔にリードタイムを合わせるためだ。

　チームのエンジニアが一連の変更をメインリポジトリにマージした後、人間のチェックや手動の介入がなく、例えば15分後に変更がテストを経て、本番環境にデプロイされる目算が立つなら、CI/CDを実現したことになる。

　こうしたCI/CDを実行しているチームは実際にはほとんどないが、ほぼ全てのチームが実行すべきだ。それがソフトウェアの健全性を確保する基本的な方法だからだ。

コードの作成から本番環境へのデプロイまでに時間がかかると何が起きる？

　リードタイムが長いと、多くのソフトウェア開発者による多数の変更をまとめて扱わなければならない。コードの差分が大きくなり、コードレビューに手間取るようになって、コードにある問題の発見と修正が難しくなる。その結果として雪だるま式にリードタイムが長引く恐れがある。

　こうした状況を解決するために、人員を増やして調整コストが上昇したり、サイト信頼性エンジニア（SRE）や運用担当者、品質保証担当者、ビルドエンジニアといった専門職が必要になって、かえって管理が複雑化したりする恐れもある。そうなれば、一連のプロセスの複雑さが膨れ上がり、副作用としてセキュリティリスクも大きくなる。

　コードが作成されてから、本番環境にフルにデプロイされるまでの時間に対して徹底的にフォーカスすることで、こうしたソフトウェア開発の問題を根本から解決できる。デプロイ間隔にこだわり、そこで発生する作業を自動化し、デプロイ間隔を追跡して時間とともに短縮することにエンジニアリングリソースを投入する必要がある。

　フィードバックループが効果的に機能するのに十分なほどにデプロイ間隔が短い間は、機能不全の兆候を管理するだけで済む。この間隔が長いほど、こうした兆候がより多く現れ、チームが問題の対処に追われる時間が長くなる。

　デプロイ間隔を15分まで縮められれば素晴らしいが、1時間未満なら上々といえるだろう。デプロイ間隔と同様に重要なのが、予測可能性だ。人間のチェックを排除しようとするのはそのためだ。

　ただし、自社の現在のデプロイ間隔が例えば15日間といった長さなら、予測可能性などよりも、間隔を短縮する取り組みに集中すべきだ。どんな改善も実を結ぶはずだ。

直観と合わないかもしれないが、CDが最も重要

　このような取り組みに懐疑的な声もあるだろう。例えば、「われわれのチームにそれができるかどうか分からない」「FacebookやGoogleのような企業にとっては非常に望ましいことだろうが、われわれは彼らとは違う」といった具合だ。

　意外かもしれないが、継続的デプロイこそが、コードを作成、リリースして、本番環境で実行する一番簡単な方法だ。これは、ソフトウェアに関する直観に反した真実だ。多くの小さな変更を迅速に進める方が、幾つかの大掛かりな変更にゆっくり取り組むよりも、格段に簡単だ。

　こう考えると分かりやすいだろう。「自分が今日書いたコードのバグと、チームの誰かが昨年作成したコードのバグでは、どちらを発見し、理解し、再現し、修正しやすいだろうか」

　コードの作成からリリースまでの間隔が短いチームは通常、バグの80％以上をその間隔内で発見する。見直す対象のコードは、先ほど書いたばかりでまだ記憶に新しく、問題が見つかっても、原因を探しやすい。そして修正方法も思い付きやすい。

　毎月リリースしてきたアプリケーションを、毎日10回リリースするように変えるのは、容易なことではない。だが、新しいアプリケーションの開発に際して、最初からCDを採用し、リードタイムが15分を超えないようにして開発を継続するのは、驚くほど簡単だ。

　レガシーアプリケーションにCDを導入するのは負担が大き過ぎると考えられる場合は、新しいリポジトリやサービス、アプリケーションで、最初からCDを実践するとよい。コードの一部だけでも、変更後に自動的にデプロイするようにすれば、バージョン間での下位互換性の維持といった多くの良いパターンがチームに波及する。

なぜCDへの取り組みが難しいのか、マネジメント層とエンジニアのどちらに効果があるのか

　リードタイムの短縮と緊密なフィードバックループの効果は顕著で、広く知られ、よく理解されているにもかかわらず、CDへ優先的に取り組むチームが非常に少ないのはなぜか。

　それは、CDが解決するソフトウェア開発の問題が、技術の問題ではなく人の問題と思われてしまうからだ。すると管理の問題に分類されてしまう。マネジャーは管理の問題を、増員などの管理手法で解決することに慣れているが、それは逆効果になりがちだ。

　さらにリードタイムを短縮しようとすると、経営層への説得が難しいかもしれない。将来に向けたロードマップの短期的な遅延や、ことによると、不確定な期間にわたる信頼性の低下を、認めてほしいと要請することになるからだ。なぜ信頼性が低下するかというと、CDの取り組みが人間の基本的な本能、つまり安全性を高めるためにスピードを落とすことに全く反しているからだ。

　それにもかかわらず、一般のエンジニアはCDの価値を認識しているようだ。CI/CDによって最大限迅速に、最大限の信頼とともに前進できるチームで働くことを、多くのエンジニアは切望している。CI/CDの推進は、エンジニアの採用においても、大きなアピールポイントになる。さらに重要なことは、チームがCI/CDによって、既存のエンジニアリングサイクルを格段に効率的に利用できることだ。

　全体の結びとして、全世界のエンジニアリングマネジャーとディレクターにコード作成から本番デプロイまでの間隔の短縮にフォーカスして、CI/CDを推進することを進言したい。

　なぜならトラブル対応や、延々と続く技術的負債の支払い、お互いのレビュー待ちに費やす時間を最小限に抑えることで、チームが高い熱意とエンゲージメントを持ち、時間いっぱいまで働き、ピークキャパシティーを発揮できるからだ。