DevOpsライフサイクルとは

DevOpsプロセスは、ソフトウェアがアイデア創出から本番、フィードバックを経てアイデア創出に戻る過程を、開発チームとオペレーションチームが単一の協力的な単位として作業することにより、動きを表しています。これは、DevOpsチームがソフトウェア・リリースの計画、開発、実行、最適化に使用できるプラクティスと自動化ワークフローのエンドツーエンドのフローで構成されている。

DevOpsライフサイクルの各フェーズは、多くの場合、左側に開発アクティビティー、右側に運用アクティビティーが連続した 1 つの連続したパスで接続された「無限ループ」の一部として示されます。

ループの「計画→コード→ビルド→テスト」の段階では、チームはソフトウェア要件を小さなユーザー・ストーリーに絞り込み、コードを段階的に（しかし頻繁に）コード・リポジトリーにコミットし、継続的統合（CI）ツールを使用して、すべてのコード変更を自動的にビルドし、テストします。

「リリース→デプロイ→運用→監視」では、オートメーションワークフローによって変更がIT環境を通じてユーザーにプッシュされます。一方、オブザーバビリティー・ツールは、システムの正常性、ソフトウェアのパフォーマンス、ユーザーの行動を追跡して問題を検知し、全体的な影響を測定します。

インフィニティループは、DevOpsライフサイクルの各フェーズが他のフェーズに影響を与えることを強調しています。チームは、作業、知識、責任をサイロ間でやり取りするのではなく、共有します。このループは、DevOpsワークフローがどのようにソフトウェア配信と最適化プロセスを合理化できるかも示しています。理想的には、すべてのサイクルが最終サイクルよりも高速、安全、自動化されることです。

このように、DevOpsライフサイクルにより、企業は人材、プロセス、ツールを連携させて、高品質なソフトウェア・アプリケーションとシームレスなユーザー・エクスペリエンスを提供できます。

DevOpsライフサイクルのすべてのフェーズは、他のフェーズと重複していますが、それぞれのフェーズには明確な目的と関連する一連のアクティビティーがあります。フェーズには以下が含まれます。

計画フェーズでは、DevOpsチームはビジネスニーズとユーザーからのフィードバックを、明確で優先順位付けされた期限付きの作業計画とプロジェクト管理ワークフローに変換し、後続フェーズでの開発とオペレーション活動の指針とします。このフェーズでは、ソフトウェア・リリースまたはシステム・ビルドのビジョン、範囲、ロードマップを明確にし、何を構築しているのか、なぜそれが重要なのか、そして成功をどのように測定するのかを全員が理解できるようにします。

一般的な計画アクティビティーには、次が含まれます。

• 製品バックログ（新機能、バグ修正、技術的負債など）の改善と優先順位付け。

• 利害関係者からのインプットを分析して、ユーザーのニーズと制約を把握する。

• 作業をタスク、ユーザーストーリー(ユーザーの視点から書かれたソフトウェア機能説明)、エピック(単一のソフトウェアの反復で対応できない膨大なユーザーストーリー)に分けて、リソース要件の推定と依存関係の特定を行います。

• 主要業績評価指標（KPI）、サービス・レベル指標（SLI）、サービス・レベル目標を定義することで、後のフェーズで「良い」がどのようなものかを把握できるようになります。

コーディング・フェーズでは、開発者は品質保証と将来のオペレーションを見据えて、計画されたインフラストラクチャとソフトウェアの要件を実用的なソースコードに変換します。新しいコードを書くだけではありません。また、パイプラインで後で自動化されたビルド、テスト、統合、デプロイメントのプロセスに必要なすべてのコンポーネントをセットアップすることも重要です。

コーディングのプロセスには以下が含まれます。

• 新しい機能を実装し、欠陥を修正し、非機能的なニーズ（セキュリティーなど）に対処するためのコードを書くこと。

• 小規模なコード変更をバージョン管理システム (Git や GitHub など) 内の共有リポジトリにレビュー用にコミットする。

• コードのコミットをテストして、シームレスに構築し、コードベースと統合できるようにします。

• 自動化された単体テストとコンポーネントテストを追加または更新して、将来のCI実行で各コミット後のコード動作を自動的に検証できるようにする。

ビルドフェーズでは、ソースコードの変更が自動的にコンパイル、検証され、デプロイ可能なビルドアーティファクトにパッケージ化されます。DevOpsツールはバージョン管理システムからコード変更を取得し、自動チェックを実行し、バージョン管理済みのパッケージ(Dockerコンテナイメージやコンパイル済みバイナリなど)を作成し、展開やさらなるテストに備えます。

より具体的には、

• 自動化されたスクリプトとビルド・ツールは、ソースコードをコンパイルし、依存関係（ライブラリー、フレームワーク、モジュールを含む）を解決してダウンロードし、すべてを実行可能ファイルまたはイメージにリンクします。

• 基本的な自動テストはビルドの一部として実行されます。ビルドが失敗した場合、「壊れた」とマークされ、ビルド段階のままです。ビルドが合格すると、ライフサイクルの次のフェーズに進みます。

テスト・フェーズ（検証とも呼ばれる）は、コード変更が実際の状況で期待どおりに動作することを確認することを目的としています。DevOpsチームは、一連の高度なテストツールを使用して、パイプラインをさらに下る前に、または本番環境に到達する前に、各変更が機能し、安全で、パフォーマンスであることを継続的に検証します。

通常、テスト・プロセスは継続的インテグレーション/継続的デリバリー（CI/CD）パイプラインに緊密に統合されているため、開発者はコードの品質に関するフィードバックを迅速かつ頻繁に得ることができます。

ソフトウェアテストの主な目的は、欠陥をできるだけ早期に（修正コストが安く、修正が容易な段階で）特定し、欠陥のあるビルドがリリースに向けて進むのを防ぐことです。テストでは、新しい変更が既存の機能を壊さないことも検証されるため、開発者はソフトウェア製品の進化に合わせてシステム全体の安定性を維持できるようになります。

リリース・フェーズでは、「テスト・ビルド」と「ライブ・デプロイメント」の間に管理されたゲートウェイを提供します。ここでは、コード変更が本番環境で承認され、ターゲット・ユーザーに公開されます。開発チームは、実証済みでテスト済みのコードをパッケージ化し、本番環境に対応していることを検証し、ステージング環境および本番環境への移行方法とタイミングを調整することで、デプロイ向けの準備をします。

一般的なリリースプロセスには以下が含まれます。

• 事前に定義された受け入れ基準に照らして、最終的な品質、セキュリティー、コンプライアンス・チェックを実施する。

• ビルド成果物を特定のリリース・バージョンに添付し、変更ログとドキュメンテーションを作成する。

• 次のリリースの脆弱性を特定し、問題に対処するための緩和戦略（ロールバックなど）を計画します。

デプロイメントフェーズでは、テストされパッケージ化されたコードが自動的にターゲット環境（ステージングまたは本番環境）へデリバリーされます。構成管理ツールとコードとしてのインフラストラクチャ（IaC） ツールは、構成ファイルと高レベルの記述的コーディング言語を使用して、ソフトウェアリリースのインフラストラクチャのプロビジョニングとオーケストレーションを自動化します。これにより、DevOpsチームはソフトウェアが信頼性が高く再現可能な方法で確実に提供されます。

デプロイは通常、継続的デリバリー（CD）とコンテナ化プラットフォーム（Kubernetesなど）によって推進され、ソフトウェアのデプロイプロセス（ビルドアーティファクトのプル、コンテナとバイナリの更新、最終テストの実行、新しいバージョンへのトラフィックの切り替え）をオーケストレーションします。

DevOpsチームは、新しいバージョンを段階的に導入し、必要に応じて迅速にロールバックできるように、さまざまなデプロイメント戦略を使用することがよくあります。

たとえば、ブルー・グリーン・デプロイメントでは、アプリは2つの並行する本番環境にデプロイされ、それぞれの環境でアプリケーションの異なるリリースが実行されます。「青」の環境はライブアプリケーションを実行し、「緑」の環境は新しいアプリバージョンのテストと検証を行います。新しいイテレーションが経過すると、グリーン環境はライブ環境になり、ブルーはアイドル状態のままですが、ロールバックに対応するために利用可能になります。

カナリア・デプロイメントでは、チームはアプリをユーザー・ベース全体に展開する前に、ライブ環境の監視とテストのためにアプリケーションを少数のユーザー・サブセット、つまり「カナリア」にデプロイします。

炭鉱労働者に有毒ガスを警告するためにカナリアが使用されたように、カナリアのデプロイメントは、すべてのユーザーに影響を与える大規模なパフォーマンスの問題を危険にさらすことなく、開発チームにアプリの欠陥を警告します。アプリケーションがカナリア・グループで適切に機能する場合、開発者は段階的に、より大きなグループに展開し、すべてのユーザーが利用できるようにしていきます。

オペレーションフェーズでは、ライブ・システムの安定性、パフォーマンス、安全性を維持し、実際のワークロード下で実際のユーザーが利用できるようにすることに重点を置きます。それはアプリケーションのライフサイクルの「終了」ではありません。むしろ、データと洞察を以前の段階にフィードバックします。

このフェーズでは、DevOpsチームは次のことを行います。

• 関連するインフラストラクチャー、サービス、依存関係を含むアプリケーションを実稼働環境で実行および監視します。

• トラフィックの流れが時間とともに悪化しないように、キャパシティプランニングとスケーリングのプロセスを管理します。

• 問題を検知してトリアージし、性能のボトルネックに対処し、必要に応じて修正プログラムやロールバックを適用します。

• セキュリティー・パッチを適用し、ガバナンス手法（アクセス制御やコンプライアンス監査など）を実施して、システム・セキュリティーを最適化します。

監視フェーズでは、チームは本番環境のアプリケーションとインフラストラクチャーを継続的に監視して、問題を検知し、実際のユーザーの行動を理解し、洞察を開発および運用に送り返します。

DevOpsチームは、アプリ、サーバー、ネットワーク、 データベース から観測データ(メトリクス、ログ、トレース)やその他の情報を収集し、リアルタイムでパフォーマンスを追跡します。しきい値とアラートを設定し、異常（高いAPI レイテンシーや不審なアクセスパターンなど）が発生した場合は、迅速な調査と修復のための通知が行われるようにします。

監視ツールがソフトウェアの欠陥やユーザビリティーの問題を発見した場合、その情報を問題トラッカーやバックログに転送し、チームがその後の反復を調整できるようにします。

無限ループには「安全性」フェーズは明示的に含まれていませんが、DevOpsパイプラインには、ライフサイクル全体にわたってセキュリティー対策を組み込んだプラクティスとテクノロジーが含まれることがよくあります。

そこで DevSecOps がフレームワークに登場します。

DevSecOpsは、Development（開発）、Security（セキュリティー）、Operations（オペレーション）の略で、セキュリティー・プロトコルを開発ライフサイクルの右側（完了時）から左側（開始時）にシフトさせるソフトウェア開発手法です。シフト・レフトでは、開発者はコードを書きながらセキュリティ・プロトコル（データ暗号化、インプット検証、役割ベースのアクセス制御、多要素認証など）を実装します。

DevSecOps には「シフトライト」アクティビティも組み込まれており、セキュリティプラクティスをデプロイ後の本番環境に拡張します。シフトライト・プラクティスでは、現実世界の状況下でランタイム時にアプリケーションを監視、テスト、保護することが優先されます。本番環境で発見されたセキュリティー問題が初期の開発フェーズに反映される継続的なフィードバック・ループを作成することで、シフトレフト・セキュリティーを補完します。

シフトレフト・セキュリティーとシフトライト・セキュリティーを併用することで、企業はDevOpsライフサイクルのあらゆる段階にセキュリティー管理を組み込むことができます。二重の「どこでもシフト」セキュリティー戦略によって、DevOps チームは、早期予防と導入後の脅威検知・対応の両方を実施できるようになり、全体的なセキュリティー体制が強化され、継続的な改善が促進される。

DevOpsライフサイクルは、ウォーターフォールやアジャイルなど、従来のソフトウェア開発アプローチを進化させたものです。

ウォーターフォールは、線形かつ順次的なプロセスに従う開発手法であり、ライフサイクルの各フェーズ（要件収集、設計、実装、テスト、デプロイメント、保守）は、次のフェーズが開始する前に完全に完了し、承認される必要があります。事前対応的な計画、詳細なドキュメンテーション、予測可能性を優先するため、安定して明確に定義された要件があり、予想される変更がほとんどないプロジェクト（官公庁・自治体や医療関連プロジェクトなど）に適しています。

ウォーターフォールは強力なプロセス管理を提供しますが、開発チームはサイロ化されています。フェーズの完了後に変更を行うには、コストと時間がかかります。要するに、ウォーターフォールは俊敏性に問題を抱えています。

アジャイルは、短いサイクル（「スプリント」と呼ばれる）を通じて、作業の小さな機能単位を提供する反復的な開発手法です。利害関係者のフィードバックに基づく適応型計画、早期デリバリー、継続的な改善を優先し、開発チームが変化する要件や条件に迅速に対応できるようにします。

アジャイル手法は、スタートアップのような動的環境において効果的であることが証明されています。包括的なドキュメンテーションよりもソフトウェアの機能を優先する部門横断的なチームを使用して、ウォーターフォール・アプローチの線形柔軟性を軽減します。しかし、アジャイル・アプローチは、オペレーションを除外し、ソフトウェア開発プロセスに焦点を当てています。

DevOpsは、CI/CDツール（GitLabなど）を活用してテスト、デプロイ、監視の自動化を行い、開発チームとオペレーション・チームを統合する最新の文化的かつ技術的な実践を提供します。アジャイルやウォーターフォールとは異なり、DevOpsのプラクティスは、企業がソフトウェアのリリースを加速し、今日の非常にダイナミックなマイクロサービス・アーキテクチャやクラウド・ベースのIT環境において、パフォーマンスと機敏さを維持するアプリケーションを構築するのに役立つ。

7つのCは、DevOpsライフサイクルを7つの継続的なプロセスの成果物として概念化する別の方法を提供します。

継続的な開発には、ソフトウェアの計画とコーディングが含まれ、開発者はプロセスをより小さく管理しやすい反復に分割していきます。開発者は、変更をバージョン管理システムに保管し、コードを利害関係者の要件に合わせて継続的に調整することで、チームがリスクを最小限に抑え、変更に迅速に適応できるようにします。

継続的統合は、複数の開発者によるコード変更を共有リポジトリにマージし、コミットごとに自動的にビルドをトリガーする方式です。これにより、DevOpsチームはソフトウェア・アプリケーションを継続的に改善し、一貫したフィードバックを受け取り、エラーがソフトウェアの性能に影響を与える前に検出して修正し、より高品質なソフトウェアを予測可能なスケジュールで提供できるようになります。

継続的テストにより、開発者はコードレビューとテストプロトコル (ユニットテストなど) を自動的に開始できます。テストツールを使用して、統合コードにバグ、ユーザビリティの欠陥、性能の問題がないかを継続的に調べます。継続的なテストにより、開発者はライフサイクルを遅らせることなくソフトウェアを改善するために必要なフィードバックを迅速に得ることができます。

継続的デリバリーでは、アプリケーションと検証済みのコード・ベースの変更（更新、修正プログラム、さらには主要な機能）の、必要なすべてのインフラストラクチャー環境へのデリバリーを自動化し、さらにテストを行います。統合テストと検証のすべての段階に合格したコード・ビルドはパッケージ化されてコード・リポジトリーに格納され、デプロイ可能な状態でコード・パッケージを一元化して保管します。

継続的デプロイメントは、承認されたすべての変更を人間の介入なしに本番環境に自動的にデプロイすることで、デリバリーをさらに一歩進めます。コード更新がテスト、検証、承認されると、継続的デプロイメント・ツールは、ソフトウェア・アーティファクトを運用前のステージング環境、またはユーザーがアクセスできる公開サーバーや配布プラットフォーム（アプリケーション・ストアなど）に移動します。

継続的なフィードバックでは、DevOpsチームが、モニタリング・データ、ユーザー・エクスペリエンス・データ、利害関係者からのインプットから洞察を得て、製品のバックログを改良し、各改善の緊急性を判断する必要があります。

継続的な監視により、アプリケーションとインフラストラクチャーの性能をリアルタイムで追跡し、問題を事前に特定して、システムの信頼性を維持します。ほとんどの監視ツールは、ダッシュボードを使用してCI/CDパイプライン・データを視覚化し、技術スタックの可視性を高め、データ駆動型の最適化を可能にします。

オートメーション・ツールは、インフラストラクチャーのプロビジョニング、リソースのスケーリング、データのバックアップ、トラフィック・ルーティング、システムの保守を処理し、DevOpsチームが新しいアプリのイテレーションにフィードバックを継続的に適用できるようにします。

DevOpsのベスト・プラクティスを活用することで、企業には次のようなさまざまなメリットがもたらされます。