DevOps における継続的デプロイの基礎

今日の企業は、ソフトウェアの開発においてソフトウェアの迅速なリリースと大規模なイノベーションという2つの大きな課題に直面することがよくあります。DevOpsは、software development lifecycle (ソフトウェア開発ライフサイクル、SDLC) の全体を通じてオートメーションを適用し、よりセキュアで信頼性に優れたソフトウェアの素早い提供を促進することで、問題の解決を目指します。

継続的デプロイは、DevOpsプラクティスの中でも最も高度なオートメーション例の1つです。これには、アプリケーションの設計と開発プロセス全体での厳格なテスト、チーム間の密接なコラボレーション、高度なツール導入、およびワークフロープロセスの組み合わせが必要になります。

継続的デプロイは、正常に実装されるときに能力を発揮します。継続的デプロイを導入するDevOps組織は、コードをより迅速にリリースし、他の企業よりもパフォーマンスが4～5倍高いことがわかっています。

このガイドでは、以下について詳しく検証していきます。

継続的デプロイのメリット
継続的デプロイプロセス
継続的デリバリーと継続的デプロイの違い
継続的デプロイパイプラインの説明
継続的デプロイパイプラインモデル
組織内で継続的デプロイを機能させる方法

継続的デプロイのメリット

継続的デプロイが正常に実装されると、企業がお客様の要求に素早く対応し、ソフトウェアアップデートを極めて迅速にリリース (大抵の場合はコード変更をコミットしてから数分以内) することが容易になります。

とは言うものの、継続的デプロイの実装は、ソフトウェアリリースの準備に数日間、または数週間を費やす状態を根本的に転換させることになり得ます。しかし、時間、リソース、およびツール導入に投資する企業は、明確なメリットを得ています。

一般的なメリットには以下が含まれます。

完全に自動化されたデプロイサイクル。 このサイクルは、組織が“リリース日”に備えて開発作業を休止する代わりに、ソフトウェアの構築により多くの時間を費やすことを可能にします。
より定期的でインクリメンタルなデプロイ。 これは、より迅速な製品デプロイ作業につながり、継続的な改善モデルの促進に役立ちます。
新機能に関する迅速なフィードバックループ。 組織は、新しい機能、アップデート、およびコード変更に関するリアルタイムのフィードバックを素早く受け取ることができます。

継続的デプロイプロセスとは

プロによるアドバイス: このガイドでは、継続的インテグレーションと、自動化されたパイプラインの概念に関する知識があることを前提としています。これらのDevOpsプラクティスに関する知識がない場合は、GitHubのドキュメントをお読みください。

DevOpsは、SDLCの各ステージにオートメーションを適用することによるイノベーションと価値提供の速度向上を目指します。この観点から考えると、継続的デプロイは、一連の定義済みテストに合格する場合にすべてのコード変更が本番環境にプッシュされる、完全に自動化されたSDLCというDevOpsの最終的な目的となります。

自動化されたパイプラインの構築は、ある意味で、継続的デプロイモデルの導入において最も簡単な部分の1つだと言えます。しかしながら、DevOps組織への旅（ジャーニー）を始めるにあたって、まず継続的デプロイプラクティスを構築することから始める組織はほとんどありません。というのも、継続的デプロイが象徴する文化的変化と、必要とされるテストスイートにある程度の成熟度レベルが必要とされるからです。

既存のツールとのインテグレーションを追加設定なしで利用できることは、GitHubの大きな魅力です。GitHubは、DevOpsを実現するのに極めて有用です。

P&G、Agile & DevOpsリード、Danilo Suntal氏

このため、完全に機能する継続的デプロイプラクティスを実現するためのプロセスとジャーニーを理解しておくことが推奨されます。

以下の図は、組織がSDLCの自動化について考え始める一般的な過程を示す、おおまかなジャーニーマップです。

ジャーニーを開始するには、組織が継続的インテグレーションプラクティスを構築する必要があります。強固な継続的インテグレーションプラクティスの基礎的要素 (定期的なコードコミット、バージョン管理ツール、およびCIプラットフォーム) は、組織が継続的デプロイプラクティスの開発を開始する土台となります。

組織で継続的インテグレーションプラクティスの構築を開始する方法を学ぶ >

基本的に、継続的デプロイは自動化されたビルド、テスト、およびデプロイを単一のリリースワークフローにまとめます。目的は、ソフトウェアビルドの本番環境へのデプロイを自動化することです。各企業は、テストスイートを構成するユニットテスト、機能テスト、およびストレステストの適切な組み合わせを特定する必要があります。また、ビルドとリリース候補の効果的なステージングとテストのためにも、本番環境における負荷を本番前環境に反映することが重要です。

すべてを適切に行うことは、より迅速でより安定したリリースという大きなメリットにつながります。これは、組織が完全に自動化されたCI/CDパイプラインで継続的デプロイを実現する態勢も整えます。

テスト計画、オートメーショントリガー、ワークフロー構成、およびCI/CDプラットフォーム全体でDevOpsプラクティスが細かく調整されていき、自然と継続的デプロイにつながることが理想的です。その結果、ソフトウェアリリースのオーケストレーションにおける人的介入の必要性が、時間とともに消失します。

しかし、実際のところは、耐久性に優れたスケーラブルな継続的デプロイモデルを実現するには、エンジニアリングリソースとツール導入に多額の投資を行う必要があります。CI/CDプラットフォームと関連するツール導入は継続的デプロイプラクティスを維持するうえで大きな役割を果たしますが、チーム間のコラボレーションと、定期的なコードコミットを強調する文化的な変化も極めて重要です。

継続的デリバリーと継続的デプロイの違い

継続的デリバリーと継続的デプロイは、混同されやすい2つのDevOpsオートメーションプラクティスであり、どちらも CD と略されることが多く、同じような責任を担うことも混同の原因となっています。

しかし、継続的デプロイはリリースプロセス全体にオートメーションを適用する一方で、継続的デリバリーはデプロイ (またはリリース) そのものまでのプロセスのすべてを自動化します。デプロイ時には、デプロイのステージングに人的介入が必要になります。

分かりやすく言うと、デリバリーはデプロイ前に行われます。

継続的デリバリーと継続的デプロイの違いについて考えるうえで役立つ方法は、それぞれが何を実行するかを考えることです。継続的デリバリープラクティスでは、ソフトウェアをいつでも手動でリリースできる形でソフトウェアが構築されます。オートメーションは、コード変更がレビュー、マージ、テスト、およびパッケージ化され、本番環境に移行されることを確実にして、ソフトウェアをお客様にリリースする準備を整えるために使用されます。

それに対して、継続的デプロイはソフトウェア自体のリリースを含めたプロセス全体を自動化します。コード変更が正常にマージされ、定義済みの自動テストのすべてに合格すると、ソフトウェアは直ちにお客様にリリースされます。

多くの点で、継続的デプロイは継続的デリバリーの自然な進化です。継続的デリバリーパイプラインが正しく設定され、リリース前にソフトウェアのすべての要素をテストするように設計されていれば、誰かがソフトウェアをお客様に向けて手動でリリースする必要性は時間とともに減少します。

継続的デプロイパイプラインの説明

継続的デプロイパイプラインは、コード変更を本番環境にプッシュするために、ビルド、テスト、およびデプロイを1つにまとめる自動化されたワークフローです。ワークフローの各ステップは、次のステップのインプットを提供するアウトプットを生成します。継続的デプロイパイプラインの全体を通じて自動テストと監視が行われ、潜在的なエラー、機能的な問題、およびバグを検出します。この検出によってリアルタイムのアラートが生成され、潜在的な問題がソフトウェアのメインブランチ、または本番環境に取り込まれないようにします。

その結果、エンジニアリングチームはメインブランチにコード変更をプッシュして、それが本番環境で使用されるのを通常数分間で素早く確認できるようになります。ソフトウェア開発に対するこのアプローチは、エンドユーザーへの継続的な価値提供というDevOpsの主要目的を裏付けます。これは、私たちが使用するアプリケーションやWebベースサービスの多くが、新しい機能やシステム変更を定期的に受け取る主な理由でもあります。

それでは、継続的デプロイパイプラインが実際にどのように機能するかを見てみましょう。

継続的デプロイパイプラインモデル

まず、継続的デプロイに単一の“モデル”はないことに留意してください。組織それぞれが、組織のニーズ、ソフトウェア開発プラクティス、およびお客様の需要に固有の継続的デプロイパイプラインを構築することになります。

しかし、継続的デプロイパイプラインには、すべての組織がエンジニアリング計画に組み込む必要がある、一般的に認められた4つのステージがあります。これには、次が含まれます。

検証

継続的デプロイは、継続的インテグレーションに基づいて構築されます。継続的インテグレーションが終了し、継続的デプロイが開始されるのはこのステージです。新しいコードがコミットされ、コードベースに統合されると、リリース候補ビルドで一連のテストを実行する、自動化された検証プロセスがトリガーされます。これには、リリース候補がデプロイ後も機能することを確実にするための、機能、インテグレーション、セキュリティ、および本番環境レベルのテストが含まれます。

一般的な検証プラクティス

自動テスト: 一連の定義済みテストで、機能テストから、インテグレーション、および受け入れテストまで多岐にわたります。
非機能要件テスト: 多くの場合、セキュリティとパフォーマンスのテストのほか、組織のニーズに応じて必要とされるテストがデプロイ前に実行されます。

展開

テストを通じてコードが検証されると、自動デプロイプロセスが開始されます。通常、より高度なインプリメンテーションでは、コミットされると同時にコードをデプロイに移行するオートメーションワークフローを作成します (もちろん、コードが継続的インテグレーションステージのすべての定義済みテストに合格することを前提としています)。

一般的なデプロイプラクティス

自動デプロイ: ビルドが定義済みテストに合格した後でのコードデプロイを自動化します。
バージョン管理: 人とチームがソフトウェアプロジェクトで連携するときの変更履歴を追跡します。
ブルーグリーンデプロイ: システムがユーザートラフィックをアプリケーションの古いバージョンから新しいバージョンへと徐々に移行するデプロイを可能にします。
本番運用テスト: デプロイ後に自動化された品質テストと機能テストがビルドに適用され、本番環境での安定性を確認します。
ダークローンチ: 大規模なリリースをオーケストレーションする前に、コード変更を小規模のユーザーグループにリリースして、リアルタイムの使用状況とシステム需要を確認します。

監視

継続的監視は、継続的デプロイをサポートするために組織が投資する必要がある重要な要素です。監視は、SDLC 全体で実施される必要がありますが、デプロイの前、途中、およびその後で、何が機能しており、何が機能していないかを確認し、リアルタイムのアラートを受け取る能力が重要になります。チームがパフォーマンスメトリクスを可視化し、システムの負担を表示できるようにするツール導入も、役に立つ投資のひとつです。

一般的な監視プラクティス

アプリケーションの監視: 稼働時間、API レスポンス、およびフロントエンドとバックエンドの安定性などの主な重点分野を用いてアプリケーションヘルスを監視します。
インフラストラクチャの監視: リアルタイムのシステム需要と、コアインフラストラクチャがシステム需要をサポートする方法を監視します。
ユーザー動作の監視: アプリケーション内のユーザー動作を追跡することで、潜在的な本番環境レベルのシステムエラー、またはユーザーエクスペリエンスの妨げとなる要素を追跡します。この監視は、将来のアプリケーション開発のための情報提供に使用することもできます。
セキュリティの監視: 悪意のある攻撃者によるアクティビティを追跡するとともに、製品コードに含まれるセキュリティの脆弱性を追跡します。

対応

本番環境レベルのシステムエラーに対応したり、セキュリティインシデントを特定したり、今後開発の余地がある潜在的な新機能を特定しているかにかかわらず、イベントに対応できることは、継続的デプロイパイプラインの重要な要素です。継続的デプロイのメリットは、コードが本番環境に即時的にリリースされることです。これは、組織がデプロイ後に発生するあらゆる問題に対応して対処する準備を整えておく必要があることも意味します。対応時間を評価するために使用される一般的なメトリクスには、MTTR (平均修復時間) があります。これは、経時的な改善を評価するために組織が追跡するメトリクスです。

一般的な対応プラクティス

デプロイのロールバック: アプリケーションを以前のビルドにロールバックして、新しいリリースで発生した問題を解決します。
インフラストラクチャチェック: デプロイ後に本番環境レベルの設定または環境が変更されないようにするためのコントロールを導入します。
アクティビティログ: アクティビティログを維持することで、ユーザー動作やプロセス実行を再現し、チームが潜在的な問題を特定できるようにします。

継続的デプロイのステージと環境

組織のほとんどは、スケーラブルなCI/CDパイプラインを構築するために、継続的インテグレーションによるコードのコンパイルとテストを促進するためのビルドサーバーの構築にリソースを投資します。これは通常、継続的デプロイの本番前環境および本番環境と組み合わせられます。

本番前環境と本番環境の目的は、オートメーションワークフロー経由でのリリース候補のテストとデプロイを促進することです。リリースが本番前環境に達すると、問題や、デプロイを一時停止する理由を特定するために、さまざまな自動テストがコードベースに適用されます。

通常、このプロセスは4つのステップで行われます。

コード変更が共有リポジトリにコミットされます。 これによって、継続的インテグレーションサーバーでの自動ビルドがトリガーされます。ここでは、依存関係が解決され、ユニットテストが適用されて、コードのパッケージ化とコンパイルが行われます。
リリースが本番前環境にデプロイされます。 継続的インテグレーションサーバーでコードがすべてのテストに合格すると、リリース候補を継続的デプロイサーバーに送信するオートメーションワークフローがトリガーされます。
追加の自動テストが実施されます。 リリースが本番前環境にデプロイされると、デプロイの本番環境へのリリース前に追加のテストが実施されます。これには、機能テストやパフォーマンステストなどが含まれます。
ソフトウェアアップデートがユーザーにリリースされます。 リリース候補が開発者環境とテスト環境の自動テストのすべてに合格すると、候補がエンドユーザーにリリースされます。

最適な継続的デプロイ環境は、厳格なテストと、継続的監視およびアラートの組み合わせで構成されており、チームが問題を素早く解決するために役立ちます。継続的デプロイ環境とテスト計画は、環境と計画を開発する組織固有のものですが、これらはすべて、エンドユーザーへの継続的で迅速な価値提供というシンプルな目標によって結び付けられています。

組織内で継続的デプロイを機能させる方法

DevOpsオートメーションのより高度な例の1つである継続的デプロイには、正常に導入するための時間、エンジニアリングリソース、およびツール導入が必要です。また、SDLCのすべてのステージ全体での強固なコラボレーションを強調する、堅牢なDevOps文化も必要です。

GitHubでは、継続的デプロイに単一のモデルがないことを理解しています。組織のそれぞれが、組織のニーズを満たし、ビジネス上の優先事項に適合するプラクティスを構築する必要があります。その一方で、継続的デプロイの導入で成功を収めたすべての一流DevOps組織に共通する一般的なベストプラクティスも存在します。これには、次が含まれます。

最初は継続的インテグレーションに焦点を当てます。 強固な継続的インテグレーションプラクティスは、優れた継続的デプロイプラクティスとパイプラインを構築するための基盤です。これには、開発者全員が1日複数回コードをコミットする継続的インテグレーション文化の取り入れが含まれます。また、すべてのコードコミットが、本番環境への移行前にスクリーニングされることを確実にする、強固な自動テスト戦略の策定も関与します。組織は、SDLCを可能な限り自動化することに焦点を当てるとともに、メインコードブランチをグリーンに保つ、つまり潜在的な問題が一切ない状態に保つことにも焦点を当てる必要があります。例えば、GitHubではGitHub Actionsを使用した独自のCI/CD機能の構築に投資して、組織のために充実したマネージドまたはセルフホステッドエクスペリエンスの両方を実現しました。
強固なテスト戦略を策定します。 継続的デプロイプラクティスとは、コード変更を行うと同時にリリースすることを意味するので、テストで検出できなかった問題は本番環境に取り込まれることになります。このため、コードベースの大部分を対象とする強固な自動テスト戦略を策定することが重要になります。ほとんどの組織は、少なくとも75%のテストカバレッジを目標としています。

ユニット、機能、パフォーマンス、アプリケーション、またはセキュリティなどのテストが有効であることを確認することに時間を費やすこともお勧めします。広範なテストカバレッジを確保することと、コードベースを強化し、製品コードの信頼性を確実にする、優れたテストを確保することは、似て非なるものです。
継続的監視プラクティスに投資します。 強力なテストスイートと優れたテストカバレッジは、継続的デプロイプラクティスに不可欠です。しかし、テスト環境と本番環境でリアルタイムの監視が行われていなければ、失敗するリスクにさらされることになります。コード変更または新しい機能は、デプロイ前にテストが発見する、意図しない問題を生じる場合があります。コードベースが安定していることをテストが示す場合でさえも、ユーザーアクティビティによって予期しない可変要素が生じたときに、インフラストラクチャ問題が突然発生する可能性があります。

継続的監視のツール導入に投資して、リアルタイムの需要、システムパフォーマンス、およびアプリケーション動作を追跡することが重要であるのはこのためです。最適なツール導入は、アプリケーションとシステムのパフォーマンスの追跡だけでなく、システム内のセキュリティ問題や異常の追跡にも役立ちます。これらは、リアルタイムのアラートとアクティビティログも提供するので、エンジニアリングチームは潜在的な修正策に取り組むことができます。
新しいコードに開発に伴って新しいテストを開発します。 コード変更のすべてが本番環境に移行される継続的デプロイプラクティスでは、コードを検証するための新しいテストを作成する時間が短くなります。これは、開発者が新しいコードを記述して新しい機能を導入した後で、QAチームが作業する時間が長いことが多いその他の開発手法とは一線を画しています。この問題を解決するためにも、新しいコードの開発に伴って新しいテストを開発することが推奨されます。製品チームが新しい機能を計画するときにテスト戦略について考え始めることができれば、なお良いでしょう。

テスト要件を計画および開発ステージに組み込むことは、継続的デプロイにおける良いプラクティスです。製品開発作業と並行してテストカバレッジも拡大されるため、長期的なメリットもあります。
SDLC全体でシフトレフトを実施し、セキュリティを強調します。 セキュリティは今日のソフトウェアにおける重要なコンポーネントです。これは特に、すべてのテストに合格したすべてのコードコミットが直ちに本番環境に移行される継続的デプロイプラクティスに当てはまることです。 DevSecOpsは、DevOpsの進化、または自然な成り行きであり、SDLCのあらゆる部分にセキュリティを組み込むことを目指します。これは、SDLCのできる限り早い段階でセキュリティを組み込む、つまりシフトレフトを実施して、組織がテストの開発を優先し、潜在的な脆弱性を探し出し、可能な限りシステムを強化することを意味します。

GitHub Advanced Securityなどのツールと、セキュリティを念頭に置いて開発にアプローチすることを全員に推奨する文化的慣行の組み合わせが重要です。クラウドIDE (統合開発者環境) などのその他ツールも、開発環境がセキュアであることを確実にするために役立ちます。

GitHub で DevOps プラクティスを構築する

GitHub は、集中的な開発者体験と強力なフルマネージド型の開発、自動化、テスト用インフラストラクチャを一体化させ、アイディアから計画、構築、本番稼動まで一貫して支援する統合プラットフォームです。

料金プランを比較する >

DevOps ソリューションを比較する >

私たちの哲学は、将来の企業のために自動化と優れた DevOps をビルドすることです。

Adobe、シニア SCM エンジニア、Todd O'Connor 氏

計画から構築へ	開発の速度を上げる
プロジェクトと完全に統合した優れたプロジェクトボードとテーブルを使用して、コードベースのすぐ隣でロードマップ計画を作成し、チームメンバーにタスクをすばやく割り当てましょう。 GitHub Issues について知る >	コミットまでの時間を短縮しましょう。開発者の環境管理やコンテキストスイッチングをなくし、クラウドの安全なマネージドスペースにより、IT 調達とメンテナンスを簡素化しましょう。 Codespaces について知る >

すべてを自動化	コード作成時のセキュリティを確保
----------	----------
GitHub Actions で全てのソフトウェア開発ワークフローを自動化しましょう。GitHub のフルマネージド型の強力な開発、テスト、自動化インフラストラクチャにより、信頼性と安全性を高めることができます。 GitHub Actions について詳しく知る >	ソフトウェア開発ライフサイクル全体を通じて、コード、依存関係、トークン、極秘データのセキュリティを確保し、脆弱性を自動で解決します。 GitHub でどのようにセキュリティを確保できるかを知る >