「DevOpsチーム向けCI/CD」のベストプラクティス12選：「避けたい間違い」も紹介

TechTargetは「DevOpsチーム向けCI/CDのベストプラクティス」に関する記事を公開した。CI/CDのベストプラクティスを実装すれば、パイプラインが大幅に改善され、ソフトウェアの品質が向上し、手作業に費やす時間を減らすことができる。

[Matt Grasberger,Stephen J. Bigelow，TechTarget]

　TechTargetは2024年8月8日（米国時間）、「DevOpsチーム向けCI/CD（継続的インテグレーション／継続的デリバリー）のベストプラクティス」に関する記事を公開した。CI/CDパイプラインを構築して管理するには、自動化を連鎖させるだけでは不十分だ。開発とデプロイメントの取り組みを最大限に高めるため、本稿で説明するCI/CDのアプローチを参考にしてほしい。

「DevOpsチーム向けCI/CD」のベストプラクティス12選（提供：TechTarget）

　CI/CDのベストプラクティスは幾つかあるが、プロジェクトによって“何が最適か”は異なる。プロジェクトの目標に応じて、「セキュリティ」「自動化」「リリースまでの時間」のいずれか一つを選ばなければならない場合もある。「早い段階で失敗する」戦略は安全性の面で懸念があるが、リリースまでの時間を優先するチームにとっては価値がある。チームはプロジェクトの優先順位と制約に基づいて、さまざまな自動テストツールを選択することもできる。

　DevOpsパイプラインを効果的に改善するには、プロジェクトの特性や目標に合わせてCI/CDのベストプラクティスを選択し、適切に調整して適用することが重要だ。

　本稿で紹介するベストプラクティスは以下の通り。

1. セキュリティ、テスト、リリースまでの時間に優先順位を付ける
2. CI/CDパイプラインの具体的な目標を定める
3. CI/CDパイプラインを使ってコラボレーションを促す
4. 優先目標に役立つツールを選ぶ
5. CI/CDの実装にチーム全員を関係させる
6. 一度ビルドし、テストを繰り返す
7. 開発環境ではサービスをモックする
8. スクリプトが使える一時的な環境を使用する
9. 「早い段階での失敗」を心がける
10. 小さく考える
11. デプロイメントのアプローチを洗練する
12. 自動化を利用する

1．セキュリティ、テスト、リリースまでの時間に優先順位を付ける

　CI/CDパイプラインによって「ソフトウェアの安全性を高める」「テストを自動化する」「リリースまでの時間を短くする」といった目標を達成できる可能性がある。時間がかかる手作業のプロセスに頼ってきたのであれば、CI/CDパイプラインの導入で、この3つの目標を全て実現することもできるだろう。だが、それぞれの目標の達成に向けた改善が競合することは、十分に考えられる。CI/CDパイプラインの価値を最大限に高めるには、最も重要な目標を優先し、その目標を実現するツールとプロセスに注力することだ。

　例えば、ソフトウェアリリースまでの時間を短縮することが最優先だが、セキュリティも強化したいのであれば、CI/CDパイプライン内にそれぞれ別の自動化プロセスを作成することを検討する。新機能を開発する際にソフトウェアのビルド、テスト、リリースをするメインのパイプラインを用意する。このパイプラインによってメインの開発プロセスを遅滞させないようにしながら、別プロセスとしてアプリケーションの徹底的な自動セキュリティスキャンを実行し、セキュリティの脆弱（ぜいじゃく）性を特定することも可能だ。

　最終的には、変更を実装する前に、優先順位とワークフローの変更による潜在的な影響を評価、検討し、その影響がビジネス目標に沿っていることを確認することが重要になる。

2．CI/CDパイプラインの具体的な目標を定める

　プロジェクトに着手する前に、CI/CDパイプラインによって実現したい目標を自問する。リリースまでの時間の短縮、ソフトウェアの品質向上、自動化するテスト数の増加などがその答えになるだろう。その目標を全て、CI/CD導入のチェックリストに含める。

　目標を明確にすることで、チーム全員が情報を共有し、ツールの選択と目標実現のための自動化の作成に全員が注力するための信頼できる指針となる。また、目標実現に向けて必要な作業をより正確に見積もれるようにもなる。

　目標の重要性を過小評価してはいけない。DevOpsの実装は全て同様の原則とパターンに従う。一方で、ツール、開発プロセス、デプロイメントの方針、指標には多くのバリエーションがある。DevOpsにおけるデプロイメントが同じでも、どのチームでも同じように機能するとは限らない点には注意が必要だ。

主要なDevOpsメトリクス

3．CI/CDパイプラインを使ってコラボレーションを促す

　CI/CDパイプラインは「自動化」を重視するが、手作業での介入なしで完全な自動化を実現することは難しい。自動化の仕組みを整えるには数週間から数カ月の時間を要することもある。またDevOpsに欠かせない、継続的インテグレーション（CI）、継続的デリバリー（CD）、継続的デプロイメント（CD）などは新たな“考え方”となる。そのため、チームメンバーは、技術的観点から新しいプロセスに適応するための時間が必要になる。また、自動化するメリットを理解して信頼を築くことも求められる。

　まずは開発チームがCI/CDパイプラインにおける担当業務を共有するようにメンバー全員に働きかけることが重要だ。CI/CDパイプラインでは「開発者がコードの変更をテスターに渡す」「テスターがそのコードをテストする」「テスト済みのコードを運用チームが展開する」といったように、担当業務ごとに運用がサイロ化されてしまう、といったことはよくある。

　自動化がチーム間のコラボレーションを阻害するような形で導入されると、それはDevOpsの本来の目的に反することになる。担当業務を共有しないと、バグの修正に時間がかかり、全体的な品質が低下する。CI/CDパイプラインでテストに不合格になったら開発者にトリアージを依頼し、必要に応じてテスト手法やコードの修正を求める。テスト担当者は開発者にベストプラクティスを示して支援することも必要だが、テストを保守する負担を共有することの方が重要だ。

4．優先目標に役立つツールを選ぶ

　アプリケーションのビルドに利用できるツールは、自動UI（User Interface）テストやセキュリティテストなど無数にある。例えば「自動ビルドシステム」は一時的なリモート環境を提供する。その環境内で開発者はアプリケーションのビルドとテストを実施し、コマンドラインシステムで動作する他の自動ツールを実行できる。よく使われているツールには「Ansible」「Jenkins」「Bamboo」「Travis CI」「CircleCI」「GitHub Actions」「GitLab CI/CD」などがある。これらのツールは全て、アプリケーションのパイプライン用のコマンドを指定する構成ファイルを使用する。Dockerの「Docker」コンテナと統合可能なため、アプリケーションのビルドとテストに必要な依存関係を使用して適切にビルド環境を構築できる。

　テストツールとしては「Selenium」「Cucumber」「Jasmine」「Test Studio」「TestComplete」などがよく使われている。他には「BrowserStack」「Sauce Labs」など、テスト実行専用のリモートマシンを用意してテストスイートの実行速度を大幅に向上しているモバイルアプリテストツールもある。互換性テストの優先度が高い場合、こうしたツールを使えば、多種多様なデバイス、画面サイズ、プラットフォームで同じテストを簡単に実行できる。人気の高い「Cypress」などの広く使われている自動テストツールも、テストを実行するためのテストフレームワークとリモート環境を提供する。

　テストツールは、カスタムコードを大量に記述することなくパイプラインを強化する経済的な方法だ。時間と労力をかけて一から何かを作成するよりも、既存のソリューションを使用する方がよい場合が多い。例えば、既存のテンプレートを備えたツールを使用すると、スクリプトを一から作成するよりもはるかに効率が高い。

5．CI/CDの実装にチーム全員を関係させる

　これは“コラボレーション”の延長線上にある取り組みだ。小規模なチームでCI/CDパイプラインを実装するのではなく、CI/CDパイプラインに対応するチームメンバー全員に何らかの役割を担当させる。チームがパイプラインの実装に慣れてくると、機能リクエストなど、プロセス全体を通じて多くの小さな作業が発生する。グループとして関係することで、CI/CDプロセスが最初からチームに浸透する。コラボレーションが広がれば、わずかな担当者しか修正できないとか、理解できないといったことで開発が遅れたり停止したりすることがなくなる。

　開発者、テスト担当者、DevOpsエンジニアが協力して作業すれば、自動化を使用してプロセスを置き換えたり拡張したりすることで、パイプラインで価値を提供できるようになる。パイプラインを高レベルから共同で設計し、チーム内で作業を均等に分担する。ベストプラクティスに関するガイダンスはDevOpsエンジニアが提供する必要があるとしても、結局はCI/CDパイプラインの最終ユーザーは開発チームとQAチームだ。チームの担当意識が高ければ高いほど、バグと修正の間のフィードバックループは緊密になる。

6．一度ビルドし、テストを繰り返す

　効率の高いCI/CDパイプラインを作成する方法の一つは、プロジェクトのビルド成果物を1回だけ作成することだ。例えば、アプリケーションのデプロイメントでDockerコンテナを使用するのであれば、パイプラインの冒頭でそのDockerコンテナをビルドし、その後の全てのデプロイメントとテストで同じコンテナを再利用する。そうすれば、時間が短縮されるだけでなく、デプロイメント間の継続性が確保され、Dockerビルド中に取り込まれる依存関係に関する問題を回避できる。

　逆に、パイプラインのステージが変わるたびに（あるいは環境が変わるたびに）ソフトウェアのビルドをやり直すと、コードベースに不整合が生じ、互換性、テスト、バージョン管理、デプロイメントに深刻な問題が生じる可能性がある。

7．開発環境ではサービスをモックする

　テストを妨げる可能性がある項目の一つが、サードパーティー製サービスによって課されるレート制限だ。例えば、アプリケーションでのユーザーの登録と認証にAmazon Web Services（AWS）の「Amazon Cognito」やAuth0の「Auth0」などのサードパーティー製認証サービスを使用することがある。これらのサービスは本番環境レベルの負荷を処理することが想定されているため、本番環境では問題なく機能する。ただし、開発環境では、本番環境レベルの負荷処理に伴うコストを避けるため、サービスのエンドポイントではレートが制限されるのが一般的だ。オンライン決済会社Stripeが提供する同社サービスの「テストモード」について考えてみよう。Stripeは帯域幅を提供し、同社サービスからのリクエストに対応するコストを負担している。テストモードではレートを制限しなければ、同社にとっては不経済になる。

　開発環境と本番環境で同じレベルのサービス料金を負担することも考えられるが、両環境に対応するには少なくとも2倍の料金負担が必要になる。それよりも経済的なアプローチは、これらのサードパーティー製サービスをモックし、サービスを模した実装を有効にする機能フラグを提供することだ。そうすれば、レート制限に直面することなく、サービスは常に正常に応答し、負荷テストとパフォーマンステストによってコードのパフォーマンスをより正確に測定できる。ただし、運用環境にリリースする前にモックではない実際のサービスを統合してテストすることを忘れてはいけない。

8．スクリプトが使える一時的な環境を使用する

　CI/CDパイプラインに静的環境を用意し、CI/CDの一部としてビルドを組み込むことは可能だ。だが、パイプラインには動的環境の方が適している。CI/CDに1つの静的環境を用意すると、一度にデプロイしてテストできるビルドは1つだけになる。だが、動的環境を用意すれば、ビルドの数に応じてパイプラインを拡張できる。「Docker Compose」や「Kubernetes」などのツールを使えば、クラウドコンピューティングサーバのみを使用する場合に比べて、動的環境の構成と起動が速くなる。

　さらに、動的環境を用意すると、柔軟性と多様性が高くなり、幅広いプロジェクトの種類と要件に対応できるようになる。動的環境では、必要なワークフローやプロセスをスクリプトで定義する。例えば、プロジェクトのタイプが異なれば、テストやテストデータセットから得られるメリットも異なる。こうした違いは全て、プロジェクトに関連付けるスクリプトを使って定義できる。

9．「早い段階での失敗」を心がける

　重大な欠陥を早い段階で発見できるようにパイプラインを設計する。アプリケーションの最も重要な機能を検証するテストを幾つか集め、集めたテストを新しいデプロイメントで実行する。その後、さらに集中度の高いテストに取り組む。そうすれば、最小限の時間で、そのデプロイメントを「徹底的にテストをする価値があるかどうか」を確認できる。多くの場合、開発直後に見つかった欠陥は、その開発者が他の作業に移った後に発見された欠陥よりも修正は容易だ。

　ここで重要なのが可観測性と評価指標だ。可観測性と評価指標があれば、開発者はプロセスの内部を確認でき、即座にフィードバックを受け取れるため、修正も迅速になる。可観測性と評価指標はツールやプロセスのワークフローに密接に関係するため、常に一緒に議論する必要がある。

10．小さく考える

　従来のウォータフォール型開発の最大の弱点は、そのアプローチが“オール・オア・ナッシング”であることだ。DevOpsなどのアジャイル型開発パラダイムが魅力的なのは、小さく、迅速で、段階的な変更が重視される点にある。各変更を小さく抑え、その変更を頻繁にコミットする。各コミットによって新しいビルドをトリガーし、単体テスト、ブルーグリーンテスト、カナリアテストなどの比較的迅速なテストをトリガーする。テストに合格したら、メインブランチに即座にマージする。そうすれば、バージョン管理やブランチの管理を制限しながら、開発全体を強化できる。

11．デプロイメントのアプローチを洗練する

　ワークフローの重要な部分となるのが、最終デリバリーとデプロイメントの段階だ。この段階で、テストを終えたビルドがデプロイメント用に利用できるようになる。ただし、ソフトウェアのデリバリーでは、デプロイメントは義務付けられていない。つまり、デプロイメントは必ずしもプロセスの一部に含まれるわけではない。DevOpsチームは、完成したビルドをデプロイメント用にデリバリーする継続的デリバリーか、検証済みのビルドを運用環境に自動的にデプロイする継続的デプロイメントのいずれかを選ぶ必要がある。

　DevOpsチームは、デプロイメントのアプローチに関する深い知識を身に付ける必要がある。例えば、デプロイメント中に注意すべきCDツール、リソース、ポリシー（クラウドの利用ガイドラインなど）といった知識が必要になる。DevOpsチームは、デプロイメントの計測を可能にし、パフォーマンスメトリクスを収集するための詳細な計画を作成しなければならない。また、新しいビルドのデプロイメント後に問題が発生した場合に備えて、ロールバックとリカバリーの明確な計画を用意する必要もある。

12．自動化を利用する

　DevOpsパイプラインは複雑で、頻繁に反復作業が発生するため、手動運用は困難だ。人の手が介入することで、遅延やエラーが発生する可能性が高くなる。そのため、DevOpsは高度な自動化を実施することでメリットが得られる。ビルド、成果物管理、バージョン管理から始まり、テストと検証を経て、ステージング、デプロイメント、指標の収集と報告書作成まで、あらゆる段階の作業を自動化する。成熟度の高いDevOpsプロセスでは、コードのコミットをきっかけとするパイプラインのほぼ全てが自動化される。

　CI/CDパイプラインの構築は、さまざまな経路を持ちながら絶えず進化するプロセスになる。パイプラインの構築には確かに価値があるが、効率的で価値のあるパイプラインを構築するはさらに価値がある。本稿で説明したヒントに従えば、プロジェクトの品質を向上し、時間が短縮されるプロセスを構築できる。

DevOpsの主要な自動化領域

CI/CDで避けたい間違い

　CI/CDによって得られる成果には魅力があるとしても、予期しない落とし穴につながることもある。このような課題は、CI/CDの取り組みの効果を制限し、プロジェクトの成果を損ない、そもそものCI/CDの目的を台無しにしてしまう可能性がある。よくあるCI/CDの間違いには以下のようなものがある。

不適切または不完全な自動化

　CI/CDの効果が高まるかどうかは、コーディング、ビルド、テスト、ステージング、デプロイメントまで、各イテレーションを管理する包括的でしっかりと計画された自動化ワークフローにかかっている。部分的な自動化や不完全な自動化（特にパイプラインツール同士が適切に統合されていない自動化）は、CI/CDプロセスの問題につながる可能性がある。

指標が不適切または指標がない

　CI/CDパイプラインは、1日当たりのコードコミットの回数など、パイプラインのパフォーマンスと結果を客観的に測定できる。開発マネジャーや開発チームは、プロジェクトにとって重要な指標を理解し、適切な計測とレポート出力の機能を実装するよう努めなければならない。目標は、CI/CDのパフォーマンスを検証し、改善の機会を見つけることだ。

リソース配分が不適切

　成功しているCIでは、複数の開発者（複数のチーム）が関与し、全員が同時にコードベースで作業することがある。だが、コードベースで作業する開発者が多過ぎると、開発効率が低下する可能性がある。例えば、一部のコードがチェックアウトされたため、他の開発者が作業できなくなることがある。頻度が高いCIには、かなりのリソースが必要になる可能性がある。効率的なCI/CDを実現するには、ジョブやコミットの規模、その頻度、そして処理に必要なリソースの3つの要素間で適切なバランスを取ることが重要だ。

デリバリーとデプロイメントの混同

　“継続的デリバリー”と“継続的デプロイメント”はどちらも「CD」と表現されるため混同されやすい。継続的デプロイメントは多くの組織にとって負担が大きいと感じられる一方で、継続的デリバリーは歓迎される成果となることがある。チームはデプロイメントをサポートできるようにパイプラインを設計すべきだが、CI/CDパイプラインとチームがデプロイメントの追加要求に対応できるほど成熟していない限り、継続的デプロイメントを強制する必要はない。

コラボレーションの欠如

　全てのアジャイル開発手法はコラボレーションを重要な要素として掲げているが、自動化によって意図せず新たなサイロ（部門間の壁）が生まれることがある。次のチームに仕事を「投げっぱなし」にしたわけではないのに、自動化ワークフローが同じ結果をもたらしてしまう可能性がある。プロセスがどれだけ成熟しても、開発チームはパイプライン全体を通じて協力体制を維持することが重要だ。