はじめに
このモジュールでは、デプロイ パターンを紹介し、デプロイ サイクルの改善と、従来と最新のデプロイ パターンを調べるのに役立つマイクロサービス アーキテクチャについて説明します。
継続的デリバリーは、継続的インテグレーションの拡張です。 すべては、顧客に変更を迅速に提供し、維持可能な方法を使用するためのものです。
継続的デリバリーはさらに一歩進んで、運用パイプラインを通過した変更が顧客にリリースされます。
継続的デリバリーの機能は、リリース管理だけではありません。
継続的デリバリーとは、ソフトウェアをオンデマンドでデリバリーできるようにするために必要な、プロセス、人材、ツールのことです。
デプロイは継続的デリバリー プロセス内の 1 つのステップにすぎません。 オンデマンドで、または 1 日に何回もデプロイするには、すべての前提条件が満たされている必要があります。
次に例を示します。
テスト戦略
テスト戦略が整っている必要があります。 ソフトウェアを検証するために多くの手動テストを実行する必要がある場合は、オンデマンドでのデリバリーに対するボトルネックになります。
コーディングのプラクティス
ソフトウェアが安全で保守しやすい方法で書かれていない場合、変更を頻繁にリリースすることはできません。
技術的負債が大量にあるためにソフトウェアが複雑な場合は、コードを迅速かつ確実に変更することは困難です。
高品質のソフトウェアと高品質のテストを作成することは、継続的デリバリーに不可欠です。
アーキテクチャ
アプリケーションのアーキテクチャは常に重要です。 しかし、継続的デリバリーを実装する場合は、おそらくそれがいっそう重要になります。
まざまなコンポーネントの間に多くの密接な結合がある一枚岩のようなソフトウェアの場合、ソフトウェアを継続的にデリバリーすることは困難です。
変更されるすべての部分が、変更されなかった他の部分に影響を与える可能性があります。 これらの予期しない依存関係の多くは自動テストによって追跡できますが、それでも困難です。
また、異なるチームで作業するときは時間的な側面もあります。 チーム A がチーム B のサービスに依存している場合、チーム A はチーム B が完了するまでデリバリーできません。 デリバリーに別の制約が存在するようになります。
大規模なソフトウェア製品の継続的デリバリーは複雑です。
小さくなるほど、簡単になります。 そのため、ソフトウェアを小さな独立した部分に分割することは、多くの場合に適した解決策です。
これらの問題を解決する方法の 1 つは、マイクロサービスを実装することです。
継続的インテグレーションは、DevOps の主要な柱の 1 つです。
バージョン コントロール システムにコードを格納した後は、コードを継続的に統合するための自動化された方法が必要になります。
Azure Pipelines を使用すると、完全な機能を備えたクロスプラットフォームの CI および CD サービスを作成できます。
ユーザーの好みの Git プロバイダーで動作し、Azure を含むほとんどの主要なクラウド サービスにデプロイできます。
このモジュールでは、継続的インテグレーションの実践と、開発ライフサイクルに実装するための柱、その利点、およびプロパティについて詳しく説明します。
学習の目的
このモジュールを完了すると、受講者と担当者は次のことができるようになります。
- デプロイ パターンについて説明します。
- マイクロサービス アーキテクチャについて説明します。
- 従来と最新のデプロイ パターンについて理解します。
- アーキテクチャを計画して設計します。
前提条件
- DevOps とは何かとその概念についての理解。
- バージョン コントロールの原則に関する知識は役に立ちますが、必須ではありません。
- ソフトウェアを提供する組織での経験があると役立ちます。