「CI/CD」実践のポイント 取り組む前に把握しておきたいメリットと課題：CI/CDのベストプラクティスとは

DevOpsの最初のステップとして、CI/CDパイプラインの作成から着手するチームは珍しくない。着手に当たっては、CI/CDの基本的なメリットや課題を理解しておく必要がある。

[Clive Longbottom，TechTarget]

　CI/CD（継続的インテグレーション／継続的デリバリー）は、DevOpsを採用している組織にとって中心的な役割を果たすものだ。CIは、チームが頻繁にコードを統合し、自動でビルドやテストを行うプロセスを指す。CDは、変更が本番環境に安全にデプロイできることを確認するプロセスを指す。

　両者を組み合わせてCI/CDフィードバックループを構成することで、運用環境への継続的なアップグレードが可能になり、円滑なソフトウェアデリバリーを通じて自社のニーズに素早く対応できるようになる。

　迅速なソフトウェアデリバリーは、CI/CDアプローチのメリットの一つにすぎない。CI/CDを導入した組織は、変更管理の改善、テストサイクルの短縮、フィードバックループの強化といったメリットも享受できる。ただし、課題も伴う。人材、プロセス、テクノロジーに多くのコストがかかる。

　これらのメリットと課題を比較して、CI/CDが組織に適しているかどうかを判断する必要がある。

そもそもCI/CDパイプラインとは

　CI/CDパイプラインは、CI/CDの作業を自動化する一連のツールとプロセスで構成される。

　このプロセスは、ソフトウェア開発におけるアジャイルアプローチに適しており、ウオーターフォール型のアプローチとは対極にある。ウオーターフォール型のアプローチの場合、開発の後半で問題が見つかると初期段階に戻って作業をやり直す必要があるため、ロールバックに時間がかかることもある。

　CI/CDの開発プロセスを導入している場合、変更を加える必要が生じると、提案される変更に優先順位を付け、その中で最も大きなメリットを得られる変更部分に取り組む。定義上、変更部分はウオーターフォール型アプローチに比べて小さなコンポーネント単位にする。小さな粒度のコード変更を既存のコードに盛り込み、具体性が高い機能テストと統合テストを実施して、新たなコードが後工程に望ましくない影響を与えないようにする。

　その後、運用環境にリリースする。このプロセスを継続的デプロイメントと呼ぶ。リリースしたソフトウェアが想定通りに機能しない場合は、そのコード単位を単に前のバージョンに戻すことでロールバックをする。

　システム管理者がバグを発見して修正を求めたり、業務部門のユーザーが新たな機能を要求したりすると、その要請がCI/CDパイプラインに加えられ、開発ワークフロー内で必要に応じて優先順位が付けられる。

　このようにして、CI/CDパイプラインは自社のニーズやユーザーに常時対応するものとなる。そのため、ウオーターフォール型アプローチに比べて対応が迅速になる。

CI/CDパイプラインのメリット

　CI/CDパイプラインは、柔軟性の高い反復的な開発アプローチを土台として重要なメリットを数多く提供する。ここからは、CI/CDプロセスの主なメリットを幾つか見ていく。

• 開発の対応力が高まる：CI/CDでは、開発者は自社のニーズに優先順位を付けて迅速に対応できる。開発チームは、フィードバックを受けて要件の変更に効率良く対応し、パイプラインを通じてアップデートを迅速にデプロイできる
• 組織との密接な連携：CI/CDを用いることで、開発者の技術的な関心ではなく、自社のニーズに基づいて開発を進められる。そのため、作業範囲が自社にとって最も有益な作業に限定され、価値の低いアップデートや修正作業に開発者が作業時間を浪費することがなくなる
• チームワークの向上：ウオーターフォール型アプローチでは、全てが厳格に管理される大規模なチームで作業が行われる。その結果、問題が生じることもある。CI/CDでは、特定の項目を小さなチームが集中して作業できるため、他のチームを心配することなく、自チームの作業に専念できる
• コード品質の向上：担当範囲が小さいため、変更が必要なコードの量も少なくなる。そのため、毎回の変更でテストする範囲も限定される。従って、完全なテスト環境にコードをリリースする前にコードの品質を徹底的に確認できる
• エラーの修正を迅速化できる：開発者はDevOpsプロセスの早い段階で問題点を特定して解決できるため、ソフトウェアリリースの信頼性が高まる。ソフトウェアがユーザーベース全体にリリースされる前に開発者がバグを解決できるため、アプリケーションのダウンタイムが削減される
• テストサイクルが短縮される：確認するコードの複雑さが少なく、コード量も少なくなるため、CI/CDプロセス全体で同じ機能を繰り返しテストする必要性も少なくなる。その結果、テストに費やす時間の無駄が省ける
• 運用環境での監視が容易になる：毎回リリースする変更が1つか2つなら、リリース中に問題が起きても、根本原因の分析は狭い範囲に限定できる。変更管理と根本原因分析の範囲が狭ければ、変更プロセスがシステム全体に与える影響も最小限に抑えられる
• 必要に応じたロールバックが容易になる：問題が起き、プラットフォームを既知の正常時点に戻す必要が生じても、毎回の変更単位が小さければ、ロールバックに必要な作業量も少なくなる
• フィードバックループが強化される：変更単位が小さければ、ユーザーにとってもヘルプデスクにとっても対応が容易になる。変更のリリース後にユーザーからエラーが報告されても、ヘルプデスクや開発者が根本原因を見つけるために調べるべき情報も少なくなる

CI/CDの課題

　CI/CDのアプローチには、以下に示すように対処しなければならない課題もある。

継続的な変更がユーザーに受け入れられないリスク

　CI/CDでは、バックエンドデータベースやビジネスプロセスなどユーザーの目には見えないものの変更も多いが、関数名の変更、メニューバーでの項目の位置移動、確立されている手順の変更など、ユーザーエクスペリエンス（UX）に影響するものもある。

　こうしたUXへの絶え間ない変更はユーザーには受け入れられない可能性がある。そのため、UXに影響を与える変更は、可能な限り早くユーザーに通知する。可能なら、画面上にガイドや説明を表示するなど、適切なサポートが重要になる。

　UXに関する変更をヘルプデスクに通知しないCI/CDプロセスが時折見受けられるが、この場合、ヘルプデスクはユーザーからの質問や苦情に悪戦苦闘することになる。

　CI/CDプロセス全体にヘルプデスクを関与させ、リリース前にヘルプデスクのスタッフが変更を確認してコメントできるようにする必要もある。

マイクロサービス環境でのドミノ倒し現象

　マイクロサービス環境では、サービス間に依存関係が存在することもある。そのため、他のマイクロサービスとの連携やデータに変更の影響が及ぶ可能性がある。異なるマイクロサービス間の依存関係の追跡には構成管理ツールが役立つ。

　オーケストレーションツールを活用し、任意の変更が他のストリームに影響を及ぼさないようにすること、開発チームが必要に応じて変更をロールバックできるようにすることも重要となる。

継続的な変更に対するモニタリングとレポート

　CI/CDで行われる変更は、その性質上、リリース先のプラットフォームに影響を及ぼす。問題点を把握し迅速に対応するには、プラットフォームのリアルタイムモニタリングとレポートが必要になる。変更によって問題が生じたら即座に把握し、問題が他のサービスに波及したり、ユーザーの苦情がヘルプデスクに殺到したりするのを防ぐ必要がある。

応答性の高いリソース管理

　事前に綿密なテストを行わないと、CI/CDによる変更がリリースされるまで、その変更によって生じるリソースやパフォーマンスへの影響を開発者やテスト担当者が予測できない可能性がある。リソースに関する予期しない問題が発生するのを防ぐには、ワークロードに依存しない形で準備やプロビジョニングをするために、できる限り多くの作業を自動化する。

　そのために、レシピやマニフェストを使用してワークロードを準備、プロビジョニングし、オーケストレーションツールを通じて適切に展開することが求められる。

CI/CDと業務の相性を確認する

　CI/CDはDevOpsと同様、業務から開発、運用へと向かう単純な一方向のプロセスと見なすことはできない。プロセスの各段階にフィードバックループを設け、次の点を判断しなければならない。

• 要求された変更が技術的に実現可能か？
• 開発段階での費用対効果は高いか？
• UXを変更する必要なくシンプルな調整で問題を対処可能か？
• 変更に必要なリソースを十分確保するためにハードウェアへの投資は必要か？
• ユーザーは変更の結果に満足しているか？
• 変更がどれほど効果的だったか、ヘルプデスクは、開発者や業務関係者に効果的なフィードバックを提供できるか？

　CI/CDは環境への変更をより迅速かつ効果的に進めることで、ITが業務をサポートする方法を変えることができる。ただし、万能薬ではない。チームはCI/CDを慎重に追加して運用する必要がある。そうしないと、新たな混乱が生じてしまう。

CI/CDのベストプラクティス

　もしCI/CDが適していると判断した場合は、次のようなベストプラクティスに従ってCI/CDの取り組みを進める必要がある。

• 継続的なフィードバック：CI/CDは、業務ニーズに応えることが大前提だ。そのため、ヘルプデスクや広範な業務部門が問題報告と機能改善の要求に関与し、連携を確保、強化する必要がある
• 自動テスト：ツールの改善により、手作業でのテストは必要最小限に抑えられるようになった。チームは、スクリプトを繰り返し使用して、変更がプラットフォーム全体の他の機能に影響を与えないことを確認できる。AI（人工知能）を使用して自動テストスクリプトを作成することも可能だ
• バージョン管理：ウオーターフォール型アプローチからCI/CDに変えたとしても、バージョン管理が不要になるわけではない。むしろ、それぞれの変更についてコンポーネントごとのバージョン管理が必要になる。バージョン管理によって、任意の要素のロールバックを管理する効率が上がり、ドキュメントを保守できる
• ドキュメンテーション：ウオーターフォール型アプローチでは、通常、バージョンやサブバージョンごとにドキュメントを管理する。CI/CDでは、この単位での管理は適切なアプローチではなく、構成する各コンポーネントの機能、影響範囲、問題解決のために選択したアプローチを詳細にドキュメント化する必要がある