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のような企業にとっては非常に望ましいことだろうが、われわれは彼らとは違う」といった具合だ。