DevOpsパイプラインの主要な構成要素
著者
0 分で読めます
今日のソフトウェア開発では、アプリケーションをすばやく開発、テスト、デプロイすることが重視されています。高度な自動化ツールは、その実現に重要な役割を果たします。DevOpsは、こうした方法論と技術的要素を取り入れ、実際のソフトウェアプロジェクトに適用します。
この記事では、DevOpsの概念とDevOpsパイプラインの主要な構成要素を解説し、ソフトウェア開発ライフサイクル（SDLC）にDevOpsの手法を取り入れるための実践的なガイドラインをご紹介します。
DevOpsパイプラインとは？
DevOpsパイプラインは、ツールとプラクティスを組み合わせて、チームがソフトウェアをすばやく効率的にビルド、テスト、デプロイできるようにします。また、ソフトウェアの保守や更新も容易になります。さらに、上流のリポジトリへのコード変更の継続的な統合を簡素化し、テストとビルドを自動化するとともに、コードの競合やバグ、脆弱性を効率よく解決・検出できます。このようにDevOpsのプラクティスは、市場投入までの時間（TTM）を短縮し、アジャイルなソフトウェア開発プロセスを実現します。
継続的インテグレーション（CI）
継続的インテグレーション（CI）では、開発者のコードを共有コードリポジトリに定期的にマージし、そのコードに対して単体テスト、ビルド、コード検証ツールを自動的に実行します。CIの主な目的は、効率的なコード検証プロセスを実現し、リリース時のコードの競合を防ぐことです。
そのため、共有リポジトリにプッシュされたコードは自動的にコンパイルされ、アーティファクトとしてテストされます。ビルドと呼ばれるこのプロセスで失敗が発生すると、開発者に失敗したテストと問題の原因となっているアサーションが通知され、コードを修正できます。CIパイプラインは通常、プルリクエストなどの標準的なコードレビューのプラクティスと組み合わせて運用されます。
CIは、コードベースの異なるブランチを調整する際に起こりがちな「インテグレーション地獄」や「マージ当日」の問題を防ぎます。
継続的デリバリー（CD）
継続的デリバリー（CD）では、コードを本番環境にデプロイできる単位にパッケージ化します。CDは、コード変更を本番環境に自動でデプロイする「継続的デプロイメント」と混同しないようにしましょう。
CD環境には、本番環境に近いサンドボックスが用意され、段階的なコード更新のテストとリリースを行います。コードレビューとテストの後、開発者は変更を本番環境にプッシュできます。小規模なコード更新を本番環境にリリースすることで、コードのトラブルシューティングが容易になり、ソフトウェアのボトルネックやマージの競合を防げます。サンドボックスで事前にテストするため、CDを通じて本番環境にデプロイされるアプリケーションは一般に安定性が高く、バグも少なくなります。
継続的デプロイメント（CD）
継続的デプロイメント（CD）とは、手動の確認やトリガーなしで、コードの更新をユーザーに自動リリースすることです。CDでは、自動ビルドとテストをコードに適用しますが、本番環境への変更はすぐに反映されます。そのため、最も迅速な製品リリースを実現できます。一方で、制約もあります。たとえば、自動チェックで見逃されたバグや脆弱性が本番環境に反映される可能性があります。そのため、慎重に適用し、小規模なコード変更に限定する必要があります。また、効率的なローリングアップデートのポリシー（ブルーグリーンデプロイメントやカナリアリリースなど）と組み合わせるべきです。
DevOpsパイプラインの構築
効率的なDevOpsパイプラインには、次の基本的な構成要素が必要です。
ソース管理
ビルド自動化ツール
コンテナセキュリティやIaCセキュリティのためのパイプラインツールも含めることができます。効率的なDevOpsパイプラインの構築に役立つオープンソースのDevOpsツールは数多くあります。
CI/CDフレームワーク
JenkinsやTravis CIなどのCI/CDフレームワークは、DevOpsパイプラインにCI/CDの仕組みを導入するのに役立ちます。こうしたフレームワークには通常、コードのコミットを受けてソフトウェアのビルド、テスト、デプロイを自動実行できるサーバーが含まれます。そのため、CI/CDツールをソースコードリポジトリに接続する必要があります。
ソース管理
ソース管理（バージョン管理）ツールを使うと、コード変更を追跡・管理できます。開発者ごとのコミットやプルリクエストを含む、コード開発の履歴を記録できます。また、コード変更をリモートリポジトリにコミットし、異なる貢献者による変更間の競合を解決するのにも役立ちます。ソース管理ツールの中でも、Gitは最も成熟したエコシステムを持ち、最も広く利用されています。
ビルド自動化ツール
ビルド自動化ツールは、アプリケーションのコードをデプロイ可能なオブジェクトにパッケージ化します。コンパイル言語かインタープリター言語かなど、使用するプログラミング言語の種類によって、ツールの機能は異なります。
C++やJavaなどのコンパイル言語向けツールは、コードをコンパイルするだけでなく、ソースコードのコンパイル、ライブラリの作成、ラッパーの生成、実行可能ファイルのビルドに対応するネイティブのビルド環境も生成します。JavaScript向けのGrunt、Webpack、Rollup、Babelなどのインタープリター言語向けビルドツールは、JavaScriptファイルの結合に加え、難読化や縮小にも使用できます。
コードテストフレームワーク
コードテストフレームワークは、開発中にアプリケーションのエラーを発見するのに役立ちます。通常、アプリケーションコードに組み込んで実行時に適用できる単体テスト機能が含まれています。また、既存のCI/CDツールに組み込むことで、テストプロセスを自動化できます。さまざまなプログラミング言語に対応するテストフレームワークがあり、たとえばPython向けのPytestやJava向けのJUnitがあります。
CI/CDにSnyk Codeのテストを追加すれば、ビルドプロセスにコード品質チェックや脆弱性スキャンを組み込むこともできます。
Azure DevOpsパイプラインの例
多くのクラウドプロバイダーは、本番環境向けのDevOpsパイプラインをクラウド上に構築するためのさまざまなツールを提供しています。実際のクラウドDevOpsパイプラインの例として、次のコンポーネントで構成されるMicrosoft Azure DevOpsパイプラインを見てみましょう。
これらのツールを使えば、先ほど説明したDevOpsの構成要素をすべて利用できます。
Microsoft Azure DevOpsパイプラインの利用プロセスは、次のようになります。
アプリケーションのコードを更新します。
Azure Reposのコードリポジトリに変更をコミットします。
CIイベントをトリガーとして、Azure Test Plansでアプリケーションのビルドと単体テストが実行されます。
Azure Pipelinesがアプリケーションのアーティファクトを自動でデプロイします。
アーティファクトがAzure App Serviceにデプロイされます。
アプリケーションのデプロイ後、DevOpsの専門家は稼働状況やパフォーマンスなどのアプリケーション指標を監視できます。
DevOpsパイプラインへのセキュリティの統合
多くの組織が今も採用している従来のアプローチによるアプリケーションセキュリティは、DevOpsと相容れません。従来のアプローチには、一般に次のような制約があります。
セキュリティは通常、組み込み機能ではなく、ソフトウェアのリリース後に追加されます。
従来のセキュリティプラクティスはフィードバックサイクルが遅く、スピードの速いDevOpsパイプラインに適していません。
従来のセキュリティ手法は、現代のアプリケーションが稼働する変化の激しい環境（クラウドサービス、コンテナ、Kubernetesなどのコンテナ管理システム）を考慮していません。
従来のアプローチを採用するセキュリティチームはDevOpsグループの外に置かれ、通常は別のチームリーダーに報告し、サイロ化した状態で業務を行います。その結果、専門家が情報共有の流れから外れ、必要な情報も得られないまま、安全でないアプリケーションがリリースされてしまいます。
さらに、セキュリティチームが監査に入ると、デリバリーが遅れ、本来のビジネス目標が損なわれる場合があります。状況をさらに悪化させるのが、サイバーセキュリティ業界で深刻化する人材不足によって、セキュリティチームの人員が不足していることです。
セキュリティチームが脆弱性などのリスクを発見しても、自ら問題を修正できない場合があります。修正対応は開発チームに引き継がれ、優先順位付けと対処が完了するまでリスクは残ります。これが、セキュリティ修正の新たなボトルネックとなります。
従来のセキュリティアプローチにはこうした制約があるため、自動化とCI/CDを軸に構築された現代のDevOps環境にセキュリティを統合するのは困難です。セキュリティは依然としてソフトウェア開発プロセスから切り離され、ソフトウェア製品の完成後に行う是正策として扱われています。しかし、この問題を解決する方法があります。
開発者ファーストのセキュリティとDevSecOps
クラウドとDevOpsによってデジタル変革が進む今、新しいセキュリティアプローチが必要なのは明らかです。DevSecOpsと呼ばれることもある新しいアプローチは、新たなテクノロジーや手法を基盤とし、その中にセキュリティを組み込む必要があります。自律的に動けるチームを支援し、ビジネスの足を引っ張るのではなく加速させることが求められます。つまり、開発者ファーストである必要があります。
DevSecOpsとは？
DevSecOpsとは、DevOpsのソフトウェアデリバリーモデルにセキュリティプラクティスを統合することです。DevOpsを自然に発展させたこのアプローチでは、「責任の共有」という考え方にセキュリティの視点を加えます。DevSecOpsでは、セキュリティをソフトウェアに組み込まれた機能と捉え、DevOpsパイプラインの他の構成要素と同様に検証とコンプライアンスのプロセスを適用します。
DevSecOpsの主なメリットは次のとおりです。
ソフトウェア開発ライフサイクルの早い段階で、セキュリティの活動とツールを導入できます。
バグや脆弱性を早期に発見し、デプロイ前に修正できるため、ソフトウェアのデリバリーが速くなります。開発者は価値ある機能のリリースに集中できます。
セキュリティ自動化ツールを使えば、セキュリティの専門家でない開発者も、安定性と安全性に優れたソフトウェアを作成できます。
DevSecOpsのアプローチを導入し、DevOpsパイプラインにセキュリティを統合した成功事例はまだ多くありません。Coveoでは、DevOpsチームのメンバーが、より大きな自律性と効率性をもって脆弱性を管理できます。各チームのSecurity Championは、脆弱性を監視し、対処方法や対応時期を自ら判断できます。CoveoのDevOpsチームには監督体制が用意されていますが、セキュリティ対策の優先順位を決める責任と権限は、全体としてチームに委ねられています。Snykがこの「信頼しつつ検証する」アプローチを支援したことで、組織全体への導入が大きく促進されました。
「まず少人数のチームでデプロイメントパイプラインを構築し、その後、すべての開発者が使えるようにしました」とBeaumont氏は語ります。「セキュリティと使いやすさの面で多くの利点があったため、新しいパイプラインを受け入れるよう開発チームを説得する必要はほとんどありませんでした。移行は自然に進みました。」
まとめ
この記事では、DevOpsパイプラインの主要な構成要素と、ソフトウェア開発プロセスへの統合方法を解説しました。DevOpsを始めるにあたって大切なのは、適切なツールを選ぶことだけではありません。責任の共有、自動化、開発者・管理者・運用担当者の協力を軸とする、健全なDevOpsの組織的プラクティスと文化を築くことも重要です。
ただし、DevOpsパイプラインの目的は、開発やリリースのサイクルを速めることだけではありません。アプリケーションのセキュリティを確保することも重要です。そのためには、DevOpsパイプラインにセキュリティを組み込み、セキュア・バイ・デザインのアプリケーションを構築するという共通の目的に向けて、さまざまなチームを連携させる必要があります。この記事で取り上げる新たなDevSecOpsのプラクティスが、現代のDevOpsの動きの中で注目を集めているのはそのためです。
DevOpsに関するよくある質問
DevOpsが必要な理由は何ですか？
DevOpsは、複数のチームや開発者が関わる複雑なプロジェクトにおいて、迅速かつ効率的なソフトウェア開発を可能にします。開発からテスト、デプロイまでの各段階を自動化することで、マージの競合を防ぎ、バグを減らし、ソフトウェアを迅速にデプロイできるようにするとともに、保守しやすくします。
DevOpsパイプラインはどのように構築しますか？
DevSecOpsとDevOpsにはどのような関係がありますか？
DevSecOpsは、ソフトウェア開発の初期段階からセキュリティのベストプラクティスを組み込みます。セキュリティをリリース後のチェックやバグ修正として扱うのではなく、静的・動的なセキュリティ分析、IaCセキュリティツール、コンテナセキュリティ分析などを通じて、DevOpsに不可欠な要素として取り入れます。