DevOps ツールと DevOps 自動化ツールチェインへのガイド

DevOps ツールチェインはあらゆる DevOps プラクティスのコアテナントであり、組織が SDLC に自動化を適用し、より高品質なソフトウェアを迅速にリリースするのを支援します。DevOps ツールチェインは、DevOps の具体的側面の 1 つでもあります。

DevOps ツールチェインを構築するために「オールインワン」プラットフォームに投資する組織もあります。さまざまな最善の組み合わせでソリューションを統合してツールチェインを構築する組織もあります。しかし、DevOps または DevOps ツールチェインを構築する万能なアプローチはありません。

このガイドでは、優れた DevOps ツールチェインが SDLC の各ステージにどのように対応しているのかについて説明します。これには、以下が含まれます。

計画およびコラボレーションツール
ビルドツール
継続的インテグレーションツール

*継続的デプロイツール

運用および継続的監視ツール
セキュリティおよび DevSecOps ツール

DevOps 計画およびコラボレーションツール

DevOps は主に、以前はサイロ化されていたチームを SDLC の全ステージにわたって統括することを目的としており、それは計画ステージから始まります。チャットアプリケーションからプロジェクト管理ツールまで、組織が DevOps ツールチェインに導入し、計画ステージで組織内の連携を強化し、コラボレーションを促進するツールは多数あります。

DevOps 計画およびコラボレーションツールは通常、次の 2 つに分類されます。

製品とロードマップ計画: 作業を計画、追跡、管理する一元化された場所を設けることは、現在の開発チームや DevOps 組織にとって基礎的な機能です。優れたツールは、組織が計画、スプリント、ロードマップを作成し、初期計画から配信された最終製品まで作業を割り当て、追跡可能にするのに役立ちます。例については、当社の公開された製品のロードマップ計画を参照してください。これは、GitHub のプロジェクトを使用して作成しています。
チームのコミュニケーション: 計画プロセス全体にわたりコミュニケーションを維持することは、コラボレーションを促進するうえで重要です。特定の決定に至った会話の記録を保存しておくことも非常に有用です。ここでは、GitHub Discussions、チャットアプリケーション、問題トラッカーなど、チームの会話に活用できるツールが重要になります。GitHub にはチームが Slack または Microsoft Teams と統合できるようにするアプリが用意されています。優れたツールはプロジェクト計画とも統合されます。つまり、ディスカッションを実行可能な作業に変えることも、作業を始める前にさらに会話が必要な場合はアイディアをディスカッションに変えることもできます。

DevOps ビルドツール

開発者がコード変更を中央リポジトリにコミットすると、ビルドステージが開始され、バージョン管理を使用した共有リポジトリの作成、開発環境のプロビジョニング、コードの統合などが行われます。このステージで、組織は通常、次の DevOps ツールを活用します。

バージョン管理とソース管理: バージョン管理システムは、ファイルの変更を自動的に記録し、以前のファイルバージョンの記録を保持するように設計されており、コードのロールバック、履歴の参照、複数のコードブランチを実行できるため、開発者は共同でコーディングし、並行して作業できるようになります。

GitHub などのプラットフォームには、プルリクエストなどの機能を使ったバージョン管理とソース管理が提供されており、main コードブランチに統合される前に個々の開発者は提案されたコード変更についてレビューを行うことができます。優れたバージョン管理とソース管理プラットフォームは広範な DevOps ツールチェインと統合され、製品チームは SDLC 全体でコラボレーションできます。
本番運用前開発環境: DevOps プラクティスでは、開発者は運用環境にできるだけ近い仮想環境を活用する必要があります。これらの環境は互いに同一であり、簡単にプロビジョニングできるため、どの開発者も一貫した環境でコード変更をすばやくビルドし、テストできます。

多くの場合、組織はコンテナ化されたプラットフォームや GitHub Packages などのレジストリを活用して、開発チーム向けに標準化された本番運用前環境をビルドします。理想的には、これらのプラットフォームをソース管理ソリューションと統合して、チームメンバーが新しいコードをコミットすると、本番運用前環境の自動化されたプロビジョニングがトリガーされるようにする必要があります。
クラウドベースの統合開発者環境 (IDE): クラウドベースの IDE では、事前に設定されて迅速にプロビジョニングできる包括的な開発環境が提供されます。これらのツールは、マシン間のセキュリティ設定などの開発者環境を標準化するのに役立つため、DevSecOps (および、より広範な開発サークル) でますます一般的に使われています。クラウドベースの IDE は一元管理されており、個々の開発者のコンピューターにコードを残さないため、開発全体のセキュリティが強化されます。

GitHub Codespaces などのツールもコア DevOps プラットフォームに密接に統合されます。これにより、開発者の環境を立ち上げるのに要する時間が短縮され、ローカルでビルドとテストを実行するまでの待機時間を減らすことで、開発速度を迅速化できます。
Infrastructure as Code: クラウドインフラストラクチャ、または Infrastructure as a Service (IaaS) の台頭により、リアルタイムの需要に合わせてリソースをよりシンプルかつ迅速にプロビジョニングできるようになりました。必要に応じた新しいリソースのプロビジョニングと、本番運用前環境および本番運用後環境に対するリソースクラスタの管理の両方について、複雑で大規模なクラウドベースのインフラストラクチャを管理する必要性も組織の間で生じています。

Infrastructure as Code (IaC) は DevOps のベストプラクティスを活用し、GitHub などのバージョン管理システムから YAML ファイルを介してクラウドインフラストラクチャリソースをプロビジョニングおよび管理します。これらのファイルはプルリクエスト、コードコミット、コードマージなどのイベントによってトリガーされる CI/CD ワークフローオートメーションを指定します。このイベントが発生すると、ワークフローによってクラウドインフラストラクチャリソースのプロビジョニングと管理が自動化されます。

IaC は共有リポジトリに保存される YAML 設定ファイルの組み合わせに依存しているため、バージョン管理と選択した CI/CD プラットフォームがシームレスに統合されていることを確認することが重要です。GitHub Actions などのツールによってこのタイプの統合が提供されるため、CI/CD を使用してリポジトリから直接インフラストラクチャを簡単に管理できます。

DevOps 継続的インテグレーションツール

継続的インテグレーション (CI) はあらゆる DevOps プラクティスの中心であり、頻繁なコードコミットの文化的プラクティスと、そのコードを正常に統合してビルドを作成するための自動化を組み合わせます。

CI を正常に導入するために、DevOps 組織は通常、次の 3 つのことを行うツールとプラットフォームを使用します。

CI: プラクティスとして、多くの場合、CI は 1 日に複数のコード変更を共有リポジトリにコミットし、自動化を使用してこれらの変更を統合し、マージされたコードベースに一連の自動テストを適用して安定性を確保し、デプロイするためのコードベースを準備します。このレベルの自動化にはバージョン管理ソリューションと大きな CI/CD プラットフォーム間の密接な統合が必要になります。これにより、DevOps 組織はコードコミットによってトリガーされる CI/CD パイプラインをビルドできるようになります。

優れた CI ソリューションを探すとき、バージョン管理ソリューションと簡単に統合できることを確認する必要があります。この統合は、開発チームがコード変更をコミットするとすぐに開始される自動化パイプラインをビルドできるかどうかを確認するうえでの鍵となります。

この統合レベルの良い例は GitHub プラットフォームに含まれており、GitHub Actions を介したプラットフォームネイティブの CI/CD や、多数のサードパーティ CI/CD サービスの事前構築済み統合を特徴としています。選択する CI/CD プラットフォームが SDLC の全ステージで自動的にテストを適用でき、コンテナ化プラットフォームのネイティブサポートが含まれていることを確認する必要もあります。
自動テスト: 自動テストツールは DevOps ツールチェインの中核となります。ほとんどのプラットフォームは、パイプラインの重要な部分、例えばコード変更が main ブランチにマージされた後などに自動テストを簡単に組み込むことができる機能を提供しています。

目標は、SDLC の重要な時点で適用される基本的なユニットテスト、統合テスト、受入テストを備えた包括的なテスト戦略を策定することです。優れたテストツールは CI/CD プラットフォームにシームレスに、またはその一部として統合され、コードカバレッジとテストの視覚化機能が組み込まれています。マトリックスのビルドテスト機能を実行でき、複数のオペレーティングシステムとランタイムバージョンにまたがるビルドを同時にテストできるテストプラットフォームを探す必要もあります。

使いたい自動テストソリューションに、お好みのチャットアプリケーションと統合される監視とアラートが備わっていることを確認することもお勧めします。それにより、何かが壊れた場合はすぐに通知を受け取り、発生した根本的な問題の修正に取り組むことができます。GitHub Actions などのツールを使用して、たとえばテストに失敗するとすぐに修復できるように、チャットアプリケーションにアラートを送信できます。
パッケージ化: コード変更が CI/CD パイプラインの全てのテストに合格すると、個別のコードユニットにパッケージ化され、デプロイの準備が整います。DevOps 組織は通常、GitHub Packages などのパッケージマネージャーを活用して、リリースに備えてソフトウェアパッケージを共有リポジトリに配信するのを促進します。

パッケージマネージャーは手動でインストールする必要性を取り除き、特定のプロジェクト内のコード依存関係をバンドルするのに役立ちます。コードライブラリごとにパッケージマネージャーは異なりますが、バージョン管理システムおよび CI/CD プラットフォームと統合できるソリューションを見つけることをお勧めします。

DevOps 継続的デプロイツール

継続的デプロイはソフトウェアのリリース時に人が介入する必要性を取り除くことによって CI/CD に構築されます。継続的デプロイプラクティスは、 SDLC の全ステージに自動化を適用します。つまり、コード変更が全ての自動テストに合格した場合、運用環境にデプロイされます。

継続的デプロイを導入する DevOps 組織は通常、次の 2 つのカテゴリーに該当するツールを使用します。

自動デプロイ: 自動デプロイは継続的デプロイの中核であり、自動デプロイをサポートするツールチェインが備わっています。これらの機能はほとんどの CI/CD プラットフォームに通常含まれます。ただし、継続的デプロイパイプラインをビルドする万能なアプローチはありません。これは、全てのアプリケーションや環境で動作するわけではありません。

継続的デプロイへの投資を決めたら、複数の環境の開発と管理をすぐにサポートできるプラットフォームを探します。重要なのは、「サーバードリフト」、つまり、開発環境、運用前環境、運用環境間の違いを起こさないようにするのに役立つソリューションが必要であるということです。ブルーグリーンデプロイをサポートするプラットフォームを検討する必要もあります。これにより、トラフィックをアプリケーションの旧バージョンから新しいリリースに徐々に移行できるため、運用環境での安定性が確保されます。

GitHub では、ネイティブ CI/CD ツールである GitHub Actions の一部として、デプロイダッシュボードと CI/CD 視覚化を提供し、継続的デプロイツールチェインにとって、これらは中核的な機能だと考えています。これは、さまざまなコードブランチ、自動テスト結果、監査ログ、進行中のデプロイの完全な視覚化を、発生と同時に DevOps 組織に提供することを意図しています。
構成管理: 構成管理は、製品のライフサイクルを通じてコアインフラストラクチャとアプリケーションシステムに必要なさまざまな環境構成を技術チームが管理するためのプロセスです。これは、自動化を通じて CI/CD およびバージョン管理と頻繁に組み合わされるプロセスでもあります。

CI/CD パイプラインが自動化を SDLC 全体に適用するように、構成管理ツールでも構成の変更はトリガーベースのイベントに応じて自動的に適用されます。これらの自動ワークフローは通常 CI/CD ツールに組み込まれ、共有 Git リポジトリにテキストファイル (YAML など) として保存されます。これらはプラットフォームによるコンテナクラスタのオーケストレーションおよび管理に使用できます。Infrastructure as Code (IaC) プラクティスの管理に使用することもできます。GitHub リポジトリと Issues により、IT プロフェッショナルは IaC と Configuration as Code (CaC) の両方に対してテキストベースの構成ファイルを生成するシステムを簡単に操作できるようになります。

継続的テストツール

DevOps プラクティスでは、テストは CI/CD にとどまらず、 SDLC 全体にわたり進行していくプラクティスです。さらに重要なことに、DevOps は、サイロ化された品質管理チームを SDLC 全体にわたり自動化と総合的なテスト戦略を活用する継続的テストプラクティスで置き換えることを目指しています。

各 DevOps 組織は必要性に従って独自の継続的テスト戦略を設計します。GitHub Actions はテストに関連するワークフローオートメーションを提供し、オープンソースと商用のテストツールの豊富なセットをサポートしています。全ての継続的テスト戦略で、SDLC 全体にわたり以下のテストタイプの組み合わせが活用されます。

ユニットテスト: ユニットテストはコードの小さなユニットをテストして、それらが分離されたコンポーネントで正しく構成されていることを検証する方法です。継続的テストのプラクティスにおいて、最も簡単にビルドでき、最も速く実行できる、自動化するための基礎となるテストでもあります。
統合テスト: リポジトリへのコード変更のコミットを行うと、統合テストにより、ビルドの安定性と、コードベースが継続して正常に動作することが確認されます。これらのテストはさまざまなアプリケーションプロセスやコードユニットがまとめてマージされる場合に発生する欠陥の特定に使用されます。統合テストは一般的に、コード変更がコードベースにコミットされるとすぐに開始され、アプリケーションの複数の部分の相互作用をテストするように自動化されます。
エンドツーエンドテストと回帰テスト: 統合テストにビルドされ、エンドツーエンドテストと回帰テストはコードベースがパッケージ化され、運用前環境にステージングされた後に適用されます。これらのテストはコードの変更によって古い欠陥、バグ、問題が再び発生しないかどうかをチェックするために使用されます。回帰テストは一般的に、アプリケーションが想定どおりに動作し、以前に特定された問題が含まれていないことを確認するために、デプロイの前後に使用されます。
本番運用テスト: アプリケーションがデプロイされた後、本番運用レベルのテストはアプリケーションヘルスと安定性を監視し、エンドユーザー対して問題が発生する前に問題を特定します。重要なのは、これらのテストは、運用前の環境では完全に再現できないライブユーザーのトラフィックを伴う本番環境の潜在的な問題を、組織が特定するのに役立つ点です。

DevOps 運用ツールと継続的監視ツール

成功する DevOps プラクティスは SDLC の全てのステージに影響します。これには運用レベルのソフトウェアも含まれます。つまり、企業はアプリケーションとインフラストラクチャのパフォーマンスを評価するためのコア操作と継続的監視ツールに投資する必要があります。正しく行えば、これらのツールは継続的に SDLC 全体にわたる潜在的な問題を特定します。

DevOps 組織は以下の機能を持つツールに投資することが最善です。

アプリケーションとインフラストラクチャの監視: アプリケーションとインフラストラクチャの監視は正常な継続的監視プラクティスの中心的なコンポーネントです。優れたツールはアプリケーションとインフラストラクチャの健全性を年中無休で自動監視し、問題が発生すると DevOps 実行者にアラートを送信して、根本的な問題が何であるかを可視化します。

理想的には、運用前環境と運用環境でアプリケーションヘルスを監視し、プロセスの問題や全体的なパフォーマンスを向上できる領域を追跡する必要があります。これは、インフラストラクチャにも当てはまります。つまり、監視によって、Infrastructure as Code (IaC) や構成管理ポリシーの改善方法に関する洞察を得ることができます。

バージョン管理ツールやチャットアプリケーションと統合できるツールを探して、適切な担当者に即座にアラートを送信し、問題を作成してソリューションの作業範囲を概説できるようにします。
監査ログ: 監査は効果的な運用と継続的監視プラクティスの中心であり、何かが発生した場合にあらゆるインシデントを解決します。DevOps 実行者は何がどこでいつ発生したのかを記録でき、問題につながる行動モデルが形成されたことに批判的になることができ、アプリケーションとインフラストラクチャの健全性を改善するうえで重要な役割を果たします。

コアサービスとアプリケーションのパフォーマンスを改善するために必要な情報をチームに提供する、ライブログと監査保持期間を使用する DevOps ツールを探します。
インシデントと変更の追跡: DevOps の主な目的は、密接なコラボレーションと自動化を通じて組織が高品質のソフトウェアをより迅速に出荷するのを支援することです。インシデントや変更を発生時に追跡して適切な担当者と共有することが極めて重要です。

成功する DevOps ツールチェインをビルドするには、コア DevOps プラットフォームと共有リポジトリ上でインシデントと変更を表示するツールを組み込む必要があります。インシデントと変更に関する全てのレポートを一元管理することが推奨されます。目標は、問題の特定と修正を容易にする信頼できる唯一の情報源を作成することです。
継続的フィードバック: DevOps のコアテナントである継続的フィードバックは、ユーザー動作やコア製品に関する顧客からのフィードバックを追跡し、新機能やシステム更新への今後の投資に役立つ実用的なデータの構築に重点を置いたプラクティスです。これにはユーザーが製品をどのように評価しているかに関する NPS アンケートデータを含めることができます。製品自体にユーザー動作の追跡とモデル化を含めることもできます。

継続的なフィードバックプラクティスを構築するためには、製品内のコアエリアを特定し、ソーシャルメディアやレビューのような製品外の場所でも、予期せぬユーザー動作や顧客の痛点を特定できる必要があります。ユーザー動作をモデル化して分析できるツールを探します。ソーシャルメディアやレビューサイトの履歴パターンを追跡するために使用できるソーシャルリスニングツールを検討することもできます。

セキュリティツールと DevSecOps ツール

DevOps がプラクティスとして進化するにつれて、コア SDLC からサイロ化されることが多いセキュリティに対して、より伝統的なアプローチから移行する必要性が強調されています。高品質なコードを確実に出荷するには、セキュリティを DevOps のプラクティスの中核とすることが重要です。このプラクティスは一般に DevSecOps と呼ばれ、セキュリティを SDLC の全ステージに統合し、CI/CD パイプラインの中核にすることを目的としています。

DevOps に投資する企業は、多くの場合、ソフトウェアセキュリティを確保するために DevSecOps プラクティスの構築にも投資する必要性を認識しています。これには通常、組織が潜在的な脅威をモデル化し、SDLC の主要ステージで自動セキュリティテストを適用するのに役立ついくつかのツールが含まれます。組織は個々のツールを取得してソリューションを作成しようとしますが、GitHub Advanced Security などの統合製品は DevSecOps をチームに導入する際の摩擦を軽減できます。DevOps ツールチェインを DevSecOps ツールで補完することで、多くの場合、企業は以下のようなソリューションを探します。

脅威モデリング: セキュリティの脆弱性や潜在的な弱点を見つけるのは、実際、ソフトウェアをリリースした後ではなく、開発中の方がはるかに簡単です。脅威モデリングは DevSecOps 実行者が SDLC の初期の計画ステージから取り組み、あらゆる問題を予測して解決するための計画を策定するプラクティスです。

現在の DevSecOps 組織は脅威と軽減策を予防的に特定するために自動化と監視を活用する脅威モデリングツールにも投資しています。優れたツールはアプリケーションとインフラストラクチャの脅威を調べて、基になるコードベースとインフラストラクチャアーキテクチャの変更を自動的に追跡します。

チームの関係者に更新を提供し、SDLC 全体にわたりリスク評価スコアを示すために、コア DevOps ツールチェインと統合できるソリューションを探します。
セキュリティダッシュボード: 潜在的なリスク、テストカバレッジ、アラートなどを含むセキュリティプロファイルを一元表示することは、どの DevSecOps プラクティスにとっても不可欠です。セキュリティダッシュボードは関連する全てのセキュリティ情報を照合して分類し、問題のトリアージとタスクの割り当てを迅速に行う方法としてよく使用されます。GitHub では、プロジェクトとリポジトリにまたがるリスクカテゴリーやアラートの詳細を示すのに役立つGitHub Advanced Security を使ったセキュリティの概要ページを提供しています。理想的には、広範な DevSecOps セキュリティツールチェインと統合してセキュリティプロファイルを一元表示できるツールを探す必要があります。
静的アプリケーションセキュリティテスト(SAST): SAST ツールは、実行する前にコードを評価し、潜在的なセキュリティリスクや脆弱性を特定するために使用されます。重要なのは、これらのツールは実行に稼働中のシステムを必要とせず、静的なコードベースに対して実行できる点です。

優れたツールは共有リポジトリに直接統合され、セキュリティの脆弱性を検出し、依存関係のレビューを実施し、機密のパスワードやシークレットをスキャンし、運用環境に移行する前にコーディングエラーを特定します。これらのツールは、コードベースに存在するあらゆる問題を検出、トリアージし、修正の優先順位付けを簡単に実行します。

理想的には、リポジトリと統合し、分析に基づいて問題を構築するように自動化できるソリューションを探す必要があります。GitHub では、たとえば Dependabot という SAST ツールがあます。これは、既知のセキュリティの脆弱性に対する全ての依存関係を分析し、プラットフォーム上のあらゆるリポジトリと直接統合されます。
動的アプリケーションセキュリティテスト (DAST): DAST はアプリケーションに対する悪意のある攻撃を再現し、実際のセキュリティを危険にさらす可能性のある潜在的な脆弱性を見つけるために使用されます。DAST ツールは通常、運用前環境のアプリケーションを分析し、運用環境に移行する前に DevSecOps 実行者がセキュリティ上の欠陥を特定しやすくします。これらの欠陥には通常、攻撃者が SQL インジェクション攻撃やクロスサイトスクリプティング (XSS) 攻撃などを実行するために悪用できる根本的な問題が含まれています。

優れた DAST ツールは、広範な SDLC 内でデプロイを自動化できるように、あなたが選んだ CI/CD プラットフォームと統合します。
対話型アプリケーションセキュリティテスト (IAST): IAST ソリューションは実行中のアプリケーションのリスクと脆弱性を特定してプロファイリングを行うために、多くの場合、SDLC の初期ステージでリリース前に使用されます。これらのソリューションはソフトウェアインストルメンテーションを活用し、手動テストと自動テストを通じて運用前環境の情報を監視して収集します。優れた IAST ソリューションにはオープンソースコンポーネントの脆弱性を特定するソフトウェア構成分析 (SCA) ツールが含まれます。
コンテナイメージスキャン: コンテナのアーキテクチャは軽量であるため、DevOps 組織はアプリケーションのビルド、テスト、デプロイ、更新を高速かつ柔軟に行うことができます。ただし、大規模なコンテナ環境は、外部からのアクセス数や脆弱性の可能性から、セキュリティリスクをもたらします。あらゆるリスクを軽減するために、DevSecOps 実行者はコンテナスキャンツールを活用してコンテナレジストリの問題を特定し、実行時にコンテナクラスタをスキャンして、脆弱性が運用環境に入り込むのを防止します。CI/CD パイプラインに統合でき、デプロイ前のビルド、統合、パッケージ化ステージなど、SDLC の特定の時点で実行されるように自動化できるツールを探します。