CI/CDパイプラインで考慮すべき3つのポイント
「継続的デリバリーとは、コード変更をトリガーとして本番環境へのリリースまでのプロセスを自動化すること」と、継続的デリバリーの復習から杉野氏は話を始めた。 ソースコードを書いたらリポジトリにコミットして、ビルドしてテストして、それがOKだったらマージして、さらに検証環境で確認して、本番環境にデプロイするという一連のプロセスの集まりをCI/CDパイプラインと呼ぶ。このようなCI/CDパイプラインでは、3つのポイントを考慮する必要があると杉野氏は語った。
最初のポイントはバージョン管理である。そのパイプラインを、誰が、いつ、どのように変更を加えたかを管理する。パイプラインをバージョン管理していない場合、変更していくと最新のパイプラインだけが手元にある状態になる。このパイプラインを使ってデプロイした場合、直前の状態にすぐに戻すことができない。また、差分を把握するのも容易ではないだろう。
2つ目のポイントは、パイプラインの正常性確認である。パイプラインを変更して、動作はしたけど環境を壊してしまったという場合を防止するためには、パイプラインが期待通りに動作することを確認する必要がある。
3番目のポイントは陳腐化防止である。突然の動作不良や脆弱性にさらされないよう、作成したパイプラインの見直しや更新が必要になる。パイプラインのメンテナンスをしないでずっと塩漬けにしていると、利用アプリケーション・デプロイ先環境のバージョンによって突然動かなくなる可能性がある。
要するに、CI/CDパイプラインを塩漬けにしていると、継続的デリバリーが阻害される可能性が高まり、ひいてはユーザーへの継続的な価値提供が阻害されるリスクが高まることになるのだ。
「皆さんも、アプリケーション開発で当たり前のようにコードのバージョン管理やリリース時の機能検証、利用しているライブラリの定期的なバージョンアップやセキュリティスキャンなどをやっていると思います。CI/CDパイプラインも、アプリケーション開発と同じように管理していくことが望ましいと思っています」（杉野氏）
そこで杉野氏らのチームでは、CI/CDパイプラインをコード化して管理するPipeline as Codeを実践することで、望ましいパイプライン管理の実現を目指すことにした。
Pipeline as Codeの実装からend-to-endテストを導入
そして杉野氏は、これまでやってきた取り組みを5つのステップに分けて順番に解説した。
1番目のステップは、Pipeline as Codeの実装である。TektonというCI/CDパイプラインを構築するCloud Nativeなオープンソースソフトウェアを利用した。
この段階では、最低限のPipeline as Code実装になっていたという。コード化したパイプラインを更新のたびにコードレビューして問題ないと確認したものを検証環境で試し、そこで問題が出なければ本番環境に適用することで品質を担保していたのだ。
「とはいえ、コードレビューで全ての問題が発覚するかというと、そんなことはありません。検証環境に入れてから問題が見つかることも当たり前のようにありました」（杉野氏）
そこで2番目のステップとして、CI/CDパイプラインに対するend-to-endテストを導入した。テスト専用の実行環境を用意しておいて、プルリクエストを起点にしてパイプラインをテストして、パスした場合のみコードをマージ可能にしたのだ。
このように、end-to-endテストを導入したことで、ほとんどの問題を確認できるようになり、安定性を向上できた。
CI/CDパイプラインの標準化、パッケージ化、結合テスト
3番目のステップで取り組んだのはパイプラインの標準化だという。杉野氏のチームは、自分のチームだけでなく、社内やNTTグループの複数の開発チームにCI/CDパイプラインを提供しており、個別対応が増えてしまう状況にあった。
そこで、各種マイクロサービスで共通して利用可能なCI/CDパイプラインの開発標準を確立するとともに、運用フローや手順書なども整備していった。その結果、さらにCI/CDパイプラインの安定性や変更容易性を向上できたという。
このようにしてCI/CDパイプラインの標準化を進めていったものの、複数のアプリケーション開発に適用するのが難しい個別要件がたびたび発生した。しかし、共通のパイプラインという関係上、個別要件を考慮していくとどうしても大きく複雑な仕様になってしまう。その結果、時間が経つにつれてCI/CDパイプラインの安定性や変更容易性の確保が難しくなってきたのだ。
そこで、4番目のステップとして、コンポーザブルなパイプライン構築に取り組んだという。パイプラインの共通部品をパッケージ化しておいて、開発チームがパッケージを組み合わせることでパイプラインを構築できるようにしたのだ。
コンポーザブルなパイプラインの実現のために、CUE言語というオープンソースのデータバリデーション言語を採用した。このCUE言語でパッケージを実装しており、開発者はパッケージを選択し組み合わせるだけで標準化されたパイプラインを生成できるようにしたのだ。CUE言語は、パッケージ化できるだけでなく、シンプルに制約を記述できたり、複数のデータ構造を直感的に結合できるといった特徴を持っている。
こうしたパイプラインのパッケージ化を可能にしたことで、個別要件への対応しやすさとさらなる安定性・変更容易性を両立できた。
さらに、5番目のステップとしてパッケージを利用した結合テストに取り組んだ。このための仕組みはGo言語で実装されたという。
「この3年間、このようにPipeline as Codeという形でCI/CDパイプラインをメンテナンスしてきました。その結果として、Secret管理サービス機能を利用した機密情報管理やBlue/Greenデプロイ機能のインテグレーションなどの実装を安定して組み込むことができました」（杉野氏）
なお、パッケージ化してパイプラインを提供する技術を用いて、パッケージを組み合わせるだけで独自要件に合わせたアプリケーション基盤とそれを継続的に改善する仕組みを提供するDevOpsプラットフォームである「Qmonus Value Stream」を社内外の開発チームに提供していると紹介し、セッションを締めくくった。
クラウドの複雑さに課題を感じている方に！
クラウドは近年ますます複雑化してきています。本来は顧客への価値創造に使うべきエンジニアの時間は、クラウドの検証や学習にも多く使われるようになってきています。Qmonus Value Streamは、パッケージを組み合わせるだけでお客様の独自要件に合わせたアプリケーション基盤とそれを継続的に改善する仕組みを提供するDevOpsプラットフォームです。現在フリートライアルをご用意しておりますので、ぜひこの機会に無料でお試しください。
