デプロイメントパイプライン

ここで高市氏は「デプロイメントパイプライン」について解説。これはCI/CDを含めたソフトウェア変更から本番環境を経て、ユーザーがそのソフトウェアを使うまでのプロセス全体を指すという。つまりCI/CDはデプロイメントパイプラインの一部であるという発想だ。

デプロイメントパイプラインの解説

ここから継続的デリバリの書籍を参考にして、デプロイメントパイプラインの各ステージについて解説を行った。

コミットステージ

最初のステージであるコミットステージの解説

デプロイメントパイプラインの最初のステージはコミットステージと呼ばれ、デベロッパーが完成したコードをソースコードリポジトリーにコミットする段階を指す。ここではデベロッパーが書いたコードが仕様通りに動作することを確認するのが目的だ。

そのために、SonarQubeなどのツールを使ってソースコードの静的解析などを行うことが必要であると解説した。高市氏はSonarQubeに関する書籍を執筆したこともあり、その気になればツールの詳しい解説も行えたはずだが、ここでは敢えて紹介するに留め、デプロイメントパイプラインの解説に注力していることがポイントだろう。

静的解析の必要性を解説

コミットステージでは最後の段階でバイナリを生成すること、環境ごとのビルドは行わないなどのポイントを解説し、CIについてのルールが必要であることを強調した。

コミットステージのCIに関するルールを紹介

最低でも1日に2回はコードをメインブランチにチェックインすること、コミットテストが終わるまで次の作業に進まないこと、5分以内でプロセスを終わるようにすることなどの経験則が解説されている。

受け入れステージ

次のステージは「受け入れステージ」（インテグレーションテスト）と呼ばれるもので、疑似的な本番環境において動作だけではなく処理性能なども評価するステージとなる。開発されたコードが実際のビジネスとして利用される場合に、必要な要件を満たしているか？を確認する段階だ。

コミットステージを経て受け入れステージに移行

コミットステージでは実装された機能の確認がメインだったが、受け入れステージにおいては「ユーザーの求める価値」を確認することが重要だと解説した。ここでは抽象的に説明されているが、一番わかりやすい例は処理速度だろう。いわゆるEC系やフライトの予約システムなどでは、検索から予約の実施～完了までに時間がかかればかかるほど離脱率が上がることが知られている。つまり、単に検索と購入ができるという機能が動いているだけではビジネスの価値は提供できないという観点である。

本番環境と同じように動くことを確認するのが受け入れステージ

ここで重要なのは、この段階からデベロッパーだけではなくビジネスのオーナー（プロダクトマネージャーと言い換えても良いだろう）が関与するということだ。そのために価値を検証するには、ビジネスオーナーが理解できるテスト内容であることが大切だ。

ビジネスオーナーが理解できる言語で検証を行う

このスライドではCucumberという特別な言語でテストを記述できるツールを使うことも効果があると解説している。

このステージでのポイントは次のスライドに要約されている。

受け入れステージでのポイント

テストの失敗にはチーム全体で対応する、開発環境でテストを実行できるようにする、外部システムとの連携がある場合は疑似的なスタブを使う、本番環境へのデプロイメントと同じプロセスを使うなどがこのステージでの要点となる。

ここでKubernetesを利用したアプリケーションをデプロイメントパイプラインに乗せた場合にどうなるか？を例を使って解説した。

Kubernetesを例にデプロイメントパイプラインを解説

GitHubのリポジトリーから生成されたバイナリをテストの後にJFrogのアーティファクトリーに格納し、疑似環境にデプロイして受け入れテストを行うという流れになる。

テストについてはコミットステージ、受け入れステージそれぞれに観点が異なるという点を解説したのが次のスライドだ。

コミットステージと受け入れステージのテストの違い

コミットステージのテストはデベロッパー目線、受け入れステージのテストはビジネスオーナー目線というのが大きな違いだろう。ここで初めて開発されたコードがビジネスとして使い物になるのか？を試されることになる。

テストについて

ここからはテストについて書籍を引用しながら解説を行った。

アジャイルテストのマトリックスを紹介

スマートフォンなどをフロントエンドにするアプリケーションであればGUIのテストは必須となる。これまではGUIのテストには多くの時間が必要だったが、メルカリの事例を紹介して大幅にテスト時間の短縮に成功したことなどを解説した。

GUIテストについてメルカリの例を使って解説

キャパシティステージ

そして受け入れステージと平行して実施されるキャパシティステージについても解説を行った。

キャパシティステージの解説

ここでは開発されたコードがシステム全体のキャパシティ（性能）に対してビジネスオーナーが許容可能なレベルに達しているかを検証することが目的であると解説。

キャパシティは機能とは異なり、明示的には提示されない要件であり、デベロッパーも開発段階ではあまり意識しない傾向があると説明。速度が遅いなどについては最後の最後の段階まで問題が表面化しないこと、逆に性能を重視しすぎて難解なコードになってしまうなどの問題があることを説明した。

非機能要件の留意点

キャパシティステージのプラクティスとして紹介されたのは、本番であり得るシナリオをベースにテストを行う、負荷をかけた状態でテストを行うのがポイントという点だ。

本番環境へのデプロイ

キャパシティステージのポイント

最後の段階となる本番環境のデプロイについては、デプロイとロールバックをワンクリックで行えるように準備する必要があることを強調した。

本番環境へのデプロイやロールバックはワンクリックで実施できるように準備

特に注意したい点として、本番環境でエラーが起こった際に本番環境を直接修正するのではなく、ロールバックを行った上でコードから見直すことを挙げた。

ゼロダウンタイムを実現するポイント

継続的デプロイメントのポイントは、デベロッパーが開発したコードを即本番環境に反映するプロセスであり、もしもエラーが発生したとしてもその変更だけをロールバックすることで大きな障害を回避できることであり、本番環境に即時反映しなくてもいつでもそれが可能な状態を作り上げることであると解説した。

継続的デプロイメントの目的

CI/CDはツールではなくプラクティスが大切

最後に、デプロイメントパイプラインを実装するためにはプロジェクトが開始間もない時期に環境を整備して試行することが重要であると語った。また何度でも繰り返して語られたのは、CI/CDはツールではなくプラクティス、つまり実際の業務の中に組み込むことであるというポイントだ。

CI/CDはツールではなく実際に業務に使ってみること

日本では多く採用されているスクラムによるアジャイル開発においても「炎上スプリント」を紹介し、機能開発に注力してしまう結果、リリースを行うというプロセス自体が軽視されてしまう傾向について解説を行った。機能要件以外にも性能などの非機能用要件も満足させるためには、本番環境への頻繁なリリースを行うことで検証が容易になることを解説した。

最後にまとめとして、人間は見えないことを先延ばしにしてしまう生き物であることを理解して、リリースのリスクを軽減するためにデプロイメントパイプラインを使うこと、デベロッパー以外にビジネスオーナーも巻き込んだプロセスを作ることの重要性を説明してセッションを終えた。