DevOps パイプラインとは 完全ガイド
2022年5月23日 // 2 min read
DevOps パイプラインは、プロセス、ツール導入、自動化を組み合わせ、Organization とソフトウェア チームが迅速に高品質なソフトウェアをビルド、テストし、エンド ユーザーに提供できるようにするためのものです。
DevOps は、ソフトウェア開発ライフ サイクル (SDLC) のあらゆるステージに影響を与える人材、プロセス、製品の組み合わせを通じ Organization がソフトウェアをビルドし、デプロイする方法を再形成しています。その主な目標は、より優れた高品質なソフト ウェアソリューションを通じ、エンド ユーザーにより迅速に価値を提供することです。
この目標を達成するために、多くの Organization が、SDLC 内の主要ステージに自動化を適用し、テストを通じてソフトウェアの品質を向上させ、デリバリー速度を向上させる必要があります。こうした自動化をツール導入や適切なプロセスと組み合わせたものが、一般的に DevOps と呼ばれます。
このガイドでは、DevOps プラクティスのインプリメンテーションを成功させるうえで DevOps パイプラインが果たす役割を説明し、以下の質問に回答を提供します。
- DevOps パイプラインとは
- DevOps パイプラインのメリットとは
- DevOps パイプラインのステージとは
- DevOps パイプラインの作成方法とは
DevOps パイプラインとは
DevOps パイプラインは、開発とエンド ユーザーへのソフトウェアのデプロイを容易にするために、SDLC 全体にわたる自動化、ツール導入、プラクティスを組み合わせたものです。重要なことは、DevOps パイプラインを構築するための万能なアプローチはなく、多くの場合、Organization ごとに設計とインプリメンテーションが異なるということです。とは言え、ほとんどの DevOps パイプラインには、自動化、継続的インテグレーションと継続的デプロイ (CI/CD)、自動テスト、レポート、監視が含まれています。
DevOps パイプラインを成功させるための重要な概念は、反復可能で継続的であり、常時稼働している、ということです。DevOps パイプラインには孤立したイベントがあってはならず、代わりに、各ステップがそれ自体の再現性によって定義される、より大規模なシステムを構成する必要があります。
重要なことは、DevOps パイプラインの構築は、多くの場合、DevOps の導入を検討している Organization にとって最も具体的な要素の 1 つであり、これは、自動化や特定のツール導入によって定義されるように、密接なコラボレーションを好む文化的側面によっても定義されます。
適切なテクノロジーと、人材とプロセスへの投資があれば、最初はシンプルなものだとしても、どのような Organization でも常時稼働の DevOps パイプラインを構築できます。ただし、段階的な開発作業と SDLC 全体にわたる緊密な部門横断的コラボレーションを優先する DevOps 文化を完全に採用しなければ、Organization は DevOps の価値を十分に実現できない可能性があります。
DevOps パイプラインのメリットとは
DevOps パイプラインの最も基本的な機能は、自動化されたプロセスとツール導入を利用して、Organization がソフトウェアを迅速にビルド、テストし、エンド ユーザーに提供できるようにすることです。つまり、DevOps パイプラインの主なメリットはデプロイまでのスピードです。
一方で、最高レベルの DevOps パイプラインには、デプロイまでのスピードと、Organization が高品質でセキュアな ソフトウェアを確実に出荷することを両立するための自動テスト スイートも含まれています。これは、あらゆる DevOps プラクティスの主な目標である、より優れたソフトウェアをより速くエンド ユーザーに提供することを強調するものです。
実際、DevOps パイプラインの設計とインプリメンテーションに成功した Organization は、一般的に次のようなメリットも享受することになります。
ソフトウェアの提供にかかる時間を短縮
DevOps パイプラインは、一連の自動化されたプロセス、SDLC、Organization がソフトウェアを迅速にビルド、テスト、出荷できるようにするツール、高速で段階的なコード変更を推奨するプラクティスを通じて、エンド ユーザーに価値 (一般的にはソフトウェア) を迅速に提供できるように設計されています。最も一般的な例は CI/CD で、DevOps パイプラインでのソフトウェアのビルド、テスト、提供を自動化し、ソフトウェアの提供を高速化します。
より信頼性に優れた高品質なソフトウェア
DevOps パイプラインは一般的に、機能とセキュリティの両方の面で、SDLC 全体に自動テストを適用します。特に、セキュリティを優先して DevOps を構築するDevSecOps を採用している Organization の場合に顕著です。最終的な結果は、Organization が自動化してパイプラインに適用するテストのレベルによって異なりますが、DevOps パイプラインを立ち上げた後に期待できる一般的なメリットは、デプロイ前に一貫した一連のテストを受けることで、ソフトウェアの信頼性と品質が向上することです。 **
リスクの軽減
SDLC 全体で一貫して適用される自動テストを優先することで、DevOps パイプラインは、Organization が本番ソフトウェアに問題やバグが混入するリスクを軽減できます。また、自動化は反復的な作業に適用されることが多く、ヒューマン エラーのリスクを低減できます。このメリットは、主に CI/CD などのプラクティスによってもたらされます。CI/CD は、自動化を活用してソフトウェアの提供を迅速化するほか、自動化テストを活用してコード変更がコード ベースにコミットされるとすぐに潜在的な問題を検出します。
自動化による手作業の必要性の軽減
DevOps パイプラインの中核は、コンピューターによる処理が適切な手のかかる作業を自動化することです。自動化を進めることで、時間のかかる反復作業を手動で行う必要性が減り、効率が向上します。また、ソフトウェア チームが持つ最も貴重な資産の一つである時間を解放することで、Organization はソフトウェアの構築と出荷にリソースを充てることができます。
レビュー時間の短縮（解決までの時間の短縮）
DevOps パイプラインでは、コード変更の機能とセキュリティ プロファイルを評価するために、SDLC 内の主要ポイントで自動テストが適用されます。Organization はそれぞれ、独自のテスト スイートを実装しますが、究極のメリットは、DevOps パイプラインにより、多くの場合、新しいコードのレビュー時間が短縮されることです。また、DevOps パイプラインでは、継続的監視とレポートの組み合わせにより、コード内で問題が特定された場合にも、一般的に解決時間が短縮されます。
DevOps パイプラインのステージ
DevOps を説明する時によく引き合いに出されるのが組み立てラインとの比較です。SDLC の各部分を分析して、自動プロセスと手動プロセスの一貫したセットを確立します。その結果、全体的な出力の効率と一貫性が向上します。
しかし、組み立てラインと違い、DevOps は明確な開始と終了を伴うエンド ツー エンドのプロセスではありません。DevOps は継続的な改善のサイクルであり、ソフトウェアが出荷された後も改善が継続されます。
実際、新しいソフトウェア機能が開発ステージを経て直線的な経路をたどるとしても、システム全体 (およびその機能) は継続的な反復サイクルをたどることになります。
この仕組みを理解するには、DevOps パイプラインのステージと、ステージ間のフィードバックを細かく見ていきましょう。
計画
どの DevOps パイプラインもスタート地点は、新しい機能や修正が導入され、スケジュールが行われる計画ステージです。計画ステージでの主な目標は、大規模な DevOps プラクティスの中でさまざまな役割を担う人々が最初からコラボレーションできるようにすることです。つまり、協力してユーザーのニーズを理解し、ソリューションを設計し、変更の影響を理解し、変更点が既存のシステムにスムーズに適合するようにします。
コード
コーディング ステージでは、Organization は計画に従ってコードを書き始め、Git などのバージョン管理システムを介して作業を追跡します。DevOps パイプラインのコーディング ステージでは、開発者は開発環境でさまざまなツールを使用して、コード スタイルに一貫性を取り入れたり、潜在的なセキュリティ上の欠陥を特定したりできます。これには、クラウド ホスト IDE (統合開発環境) などのツールの利用が含まれる場合があります。これらのツールは、開発者ワークフロー全体で一貫性を取り入れ、コーディング環境を高速化するためによく使用されます。
ビルド
ビルド ステージでは、DevOps パイプラインが完全に始動しています。開発者が共有リポジトリにコード変更をコミットするとビルド ステージが始まります。この時点で、開発者はプルリクエストを送信して、コード変更をコード ベースにマージすることができます。これにより、チームの他のユーザーにマージを承認する前にコードを確認するよう警告が表示されます。同時に、一般的な DevOps パイプラインは、コード ベースをマージし、一連のインテグレーション テストとユニット テストを開始する自動ビルド プロセスを開始します。これらのテストやビルド自体が失敗した場合、プルリクエストも失敗し、開発者にその問題が通知されます。
DevOps パイプラインにおけるこのレベルのワークフロー オートメーションは、Organization が潜在的なビルド インテグレーションの問題を軽減し、SDLC の早い時点でバグやセキュリティ問題を特定するのに役立ちます。
テスト
ビルドが承認されると、DevOps パイプラインのテスト ステージが開始され、ビルドは本番環境に近いテスト環境にデプロイされます。Organization によっては、ステージング用のテスト環境のプロビジョニングを自動化するために、DevOps パイプラインに infrastructure-as-code (IaC) を採用する場合があります。また、どのような新しいビルドにも対応できるように、専用のビルド済みテスト環境を用意している場合もあります。こうした選択は、Organization のニーズとコンピューティング リソースによって大きく異なります。
ビルドがテスト環境にデプロイされると、さまざまな自動テストと手動テストが実施されます。これには、脆弱性やリスク領域を特定するための、動的アプリケーション セキュリティ テスト (DAST) や対話型アプリケーション セキュリティ テスト (IAST) などの自動セキュリティ テストが含まれる場合があります。また、チーム メンバーがアプリケーションを使い、顧客が遭遇する可能性のある問題やバグを記録する手動ユーザー受け入れテスト (UAT) を含めることもできます。
Organization は DevOps パイプラインのテスト ステージにおいて、それぞれが独自の自動および手動のテスト スイートと戦略を持っています。そして、重要なことに、このステージでは開発者ワークフローを中断することなく、Organization がテストを適用できる場所が提供されます。
リリース
リリース ステージでは DevOps パイプラインで新しいビルドが完全にテストされ、デプロイの準備が整っています。コード自体のテストに加え、運用パフォーマンスのテストも完了しているため、Organization は未発見のバグや問題の影響を受けることなく本番環境で正常にコードを実行できることを確信できます。
このステージでは、いわゆる継続的デプロイと呼ばれるプラクティスで、このステージに達したコードを自動的にデプロイすることを選択する Organization もあります。そうすることで1 日に複数回、コード変更をデプロイするソフトウェア チームもいます。一方で、新しいビルドを手動で本番環境にリリースし、最終的な承認ステージを含めるようにするチームもいます。他にも、特定の日または特定の時間に自動リリースが行われるようにスケジュールするチームもいます。
CI/CD プラットフォームやその他の DevOps ツールを使用すると、Organization は最適なリリース サイクルを構築し、DevOps パイプラインのリリース ステージ全体に自動化を適用できます。
デプロイ
ビルドはリリースが終わると、本番環境にデプロイできるようになります。DevOps パイプラインのデプロイ ステージでは、Organization は IaC を介して新しい本番環境をプロビジョニングしたり、ブルーグリーン デプロイを調整したりすることで、デプロイ プロセスを自動化するためにさまざまなツールを活用します (これは、古いコード ベースが別の環境の他のユーザーに対して運用可能なままである間、新しい環境の一部のユーザーにコード変更が徐々にロールアウトされる場合です)。また、ブルーグリーン デプロイ戦略により、Organization は、問題が発生した場合に、ユーザーを以前のビルドにすばやく戻すことができます。
運用
DevOps パイプラインはアプリケーションがデプロイされたら終わりではありません。デプロイ後は運用ステージが始まり、Organization は全てがスムーズに実行されていることを確認する必要があります。
運用ステージには、リアルタイムの需要に合わせてリソースを自動的にスケーリングするルールを適用するインフラストラクチャ オーケストレーションと構成設定が含まれます。また、多くの場合、行動ログや顧客フィードバック フォームなど、アプリケーション内のユーザー アクティビティをキャプチャするメカニズムも含まれます。
運用ステージの目標は、ステージの名称そのものが示唆するとおり、アプリケーションと基になるインフラストラクチャを適切に運用し、ソフトウェア自体の運用プロファイルを改善する方法を模索することです。
監視
DevOps パイプラインの運用ステージを足場として、Organization は自動監視ツールをセットアップして、潜在的なパフォーマンスのボトルネック、アプリケーションの問題、ユーザー動作を特定します。このステージでは、アプリケーションとインフラストラクチャのパフォーマンスに関するデータを収集するツール導入を実装し、実行可能な項目を製品チームに渡し、未解決の問題を解決するか、アプリケーションの既存のユーザー動作をサポートする新機能を開発する必要があります。
監視は DevOps パイプラインのいわば「最後」のステージですが、プロセス自体は継続的であることを理解することが重要です。つまり、監視ツールは Organization が、DevOps パイプラインを通じてフィードバックする追加の計画とイテレーションが必要な領域を特定するのに役立ちます。
DevOps パイプラインの構築方法とは コア プラクティスを理解する
DevOps パイプラインは一つとして同じものがありません。というのも、それぞれが利用者である Organization の具体的ニーズを反映するものだからです。とは言え、共通して DevOps パイプラインでよく使用されるツール導入とプロセスの要素があります。
こうした核となる要素には、プロセス、文化、ツール導入が混在しており、以下の核となるプラクティス領域が含まれます。
継続的インテグレーション (CI): 多くの人が同じコード ベースで作業する場合、作業を続けるにつれて、各人のコード ブランチ間の差異はますます大きくなります。変更が大きくなるほど、それをメインのコード ベースにマージし直すのが難しくなります。継続的インテグレーションでは、各自が自分の作業をメイン ブランチに頻繁にマージすることを推奨しています。そうすることで、矛盾を発見しやすくなり、各自の作業が同僚の作業と乖離する可能性が低くなります。
継続的デプロイ: 継続的デプロイは継続的インテグレーションを足場として構築されます。共通のツール セットを使用して自動化された方法で、パイプラインを介してさまざまな環境 (共有開発者環境、テスト環境、UAT 環境、さらには本番環境まで) に新しい変更を自動でプッシュします。DevOps プラクティスにおける自動化の先進的な例の一つと考えられている継続的デプロイでは、全ての必要な事前定義済みテストに合格すると、コード コミットを簡単に本番環境に移行できます。
継続的テスト: コード コミットが行われると、ほとんどの DevOps パイプラインは何らかの形で自動テストを開始します。回帰テストでは、変更によって既存の機能が損なわれないことを確認します。ユニット テストでは、コード変更によって期待どおりの出力が得られることを確認します。機能テストでは、ユーザーが介入して新しいバージョンのコードを使用するように求められる場合があります。テストが失敗すると、パイプラインが停止し、コードのマージやデプロイができなくなります。
継続的監視: データは DevOps の生命線です。監視ツールは各ステージで役立ちますが、主に本番環境でアプリケーション ヘルスを把握するために使用されます。
特定の DevOps ツールを使用すると、Organization はこれらのプラクティス領域を強化できます。たとえば、CI/CD プラットフォームを使用して、継続的インテグレーションと継続的デリバリー (または継続的デプロイ) をサポートするオートメーション ワークフローを構築できます。
しかし、ツールだけでは DevOps パイプラインを成功させることはできません。そのためには、理想的な SDLC を計画し、デプロイの速度と品質を向上させるために自動化できる主要領域を決定するための専用リソース、戦略的な自動テスト スイート、SDLC 全体にわたるさまざまな役割間の緊密なコラボレーションを優先する文化が必要です。
DevOps プラクティスを構築するための CI/CD パイプラインの構築方法を学ぶ >
GitHub で DevOps パイプラインを構築して高速化する
コードからクラウドまで自動化し、あらゆるステップで一歩先を行きましょう。GitHub は統合型のプラットフォームで、アイディアから計画、運用まで、焦点を絞ったデベロッパー エクスペリエンスと、強力なフルマネージド型の開発、自動化、テスト インフラストラクチャを組み合わせて企業を支援します。
DevOps の自動化を実現
重要なコードにより多くの時間を費やし、開発者のスピードを低下させる作業を軽減します。GitHub Actions や Packages などのツールにより、GitHub は強力な CI/CD と自動化を DevOps パイプライン全体に組み込むことができます。
計画
GitHub Issues、GitHub Discussions、プロジェクト ボードを使って作業の調整、管理、更新を一か所で行います。すでに使用している計画ツールやプロジェクト管理ツールを統合することで、整理された状態を維持し、計画どおりに作業を進めます。
コード
GitHub と Codespaces を使ってコードをコラボレーション、作成、格納し、開発を迅速化します。コード品質統合を追加してコード レビューを自動化し、必要に応じてスタイル、品質、セキュリティ、テストカバレッジをチェックできます。
ビルド
GitHub Actions と GitHub Packages により自動化された継続的インテグレーションを使って迅速にリリースします。GitHub イベントに基づいてワークフローをトリガーし、必要に応じて全てネイティブ ツール コマンドを含めたパッケージを公開します。
モバイル CI、コンテナ CI、その他の CI ツールについて知る
テスト
Actions ワークフローにパートナーやコミュニティからの統合テストなどのテストを追加することで、バグが運用環境で発生するのを防ぎます。
デプロイ
Actions で継続的デリバリーを自動化したり、GitHub で一般的な CI/CD プロバイダーや主要パブリック クラウドからのデプロイ統合をトリガーしたりします。
管理
チームが運用で使用する管理ツール、ログ ツール、アラート ツール、監視ツールにコードを接続します。システムおよびユーザーに対する影響の測定、パフォーマンスの分析、コードによる影響の監視を簡単に行います。
分析ツール、アラート ツール、ログ ツール、監視ツールについて知る
セキュリティ保護 CodeQL、Dependabot や現在使っているセキュリティ ツールで、コードが全てのステップで安全であることを把握します。
リソース
より優れた DevOps のためのより優れたプラクティス
| GitHub での自動化と CI/CD の仕組み | GitHub の DevSecOps ガイド | 開発をスピードアップするための重要なヒント |
|---|---|---|
| 他の自動化ツールや CI/CD ツールと比較して、GitHub Actions は GitHub フロー内にネイティブな機能を提供します。ガイドを入手 > | DevOps ワークフローとパイプラインにセキュリティを組み込み、より高品質なソフトウェアを提供する方法を学ぶ。ガイドを入手 > | クラス最高レベルのチームから、ソフトウェアを迅速に構築する方法に関するベスト プラクティス、ヒント、実用的なインサイトを入手します。ガイドを入手 > |
世界最高レベルのチームに参加
GitHub Actions を使用した CI/CD により、GitHub から直接ビルド、テスト、デプロイすることができます。ビルド時間を 80 分から 10 分に短縮できました。
エンジニアリング アーキテクト Pinterest
Tags