continuous delivery devops
DevOpsでの継続的デリバリーとは何ですか?
継続的インテグレーション 前回のチュートリアルで詳しく説明しました。ここでは、DevOpsでの継続的デリバリーについて説明します。
継続的デリバリーは、ソフトウェア/アップデートを少しずつ本番環境に配信する重要なプロセスであり、ソフトウェアをいつでもリリースできるようにします。このDevOpsのアプローチにより、チームはいつでも本番環境に「いつでも配信」できるようになります。
また読む=> 完全なDevOpsガイド
したがって、継続的デリバリーはコードのパイプラインまたはライフサイクルであり、ソフトウェアチームによって新しく開発または更新されたコードは、手動テストと自動テストの両方を通じてさまざまな段階でテストされ、手動と自動の両方のステージゲートに合格して入ります。製造。
継続的デリバリーの主な焦点と目的は、構築、テスト、および顧客へのリリースを非常に迅速かつ頻繁に、短いサイクルで行うことです。
以下に、CDの利点を示します。
-
- 配達数を増やします。
- 生産の失敗のリスクを最小限に抑えます。
- 手作業を削減します。
- チームへの信頼を高めます。
- チームがすべてを自動化できるようにします。
- より高速なフィードバックを可能にします。
ビデオパート3ブロック2:継続的デリバリー–10分28秒
トランスクリプト:
この講義シリーズのパート1とパート2を完了し、現在パート3-ブロック2にあります。
ブロック1では、継続的インテグレーションについて学習しました。これは、DevOpsプラクティスの重要な自動化プロセスであり、継続的インテグレーションは、すべての開発者コードを中央リポジトリにマージし、ビルドと自動化された単体テストが成功することで各開発者のマージを検証する継続的プロセスであることを理解しました。 。
また、CIのメリットについても調査しました。
time()関数c ++
ここで、DevOpsプラクティスのもう1つの重要なプロセスである継続的デリバリーについて理解しましょう。
DevOpsの主な目的は、お客様に少しずつ価値を提供し続けることです。
したがって、この目標に沿って、継続的デリバリー、CDは、要するに、チームが常に「 いつでもお届けします」 特定のコミットされた納期にのみ納品し、その日だけに固執するという私たちの古くからのモデルの代わりに、プロダクションに。
したがって、継続的デリバリーはコードのパイプラインまたはライフサイクルであり、ソフトウェアチームによって新しく開発または更新されたコードは、手動テストと自動テストの両方でさまざまな段階でテストされ、手動と自動の両方のステージゲートに合格して入ります。製造。
継続的デリバリーの主な焦点と目的は、構築、テスト、および顧客へのリリースを非常に迅速かつ頻繁に行うことです。あなたはより速く、頻繁にDevOpsでほんの数時間を参照することを知っています。
要するに、継続的デリバリーは、ソフトウェアを短いサイクルでデリバリーするアプローチです。
内部結合左結合右結合
したがって、明らかに、CDは、コストを削減し、配信速度を上げ、信頼性を高め、コードの重いチャンクを配信するリスクを減らすことによって、より頻繁に顧客に価値を提供することを意図しています。
したがって、継続的デリバリーは、ソフトウェア/アップデートを少しずつ本番環境に配信するプロセスであり、ソフトウェアをいつでもリリースできるようにします。
これは、継続的デリバリーの図式表現です。
それについてもう少し詳しく理解します。
明らかに、コスト、時間、品質、信頼性に重点を置いたより迅速な配信が継続的配信の目的である場合、「全体の自動化」が必須です。
CDは、コードのチェックイン、コンパイルとビルド、自動化された単体テストの実行、受け入れテストの実行から始まり、コードが本番環境に移行するまでの完全なサイクルの完全な自動化を採用しています。このパイプラインは「自動展開パイプライン」と呼ばれます。
そのため、DevOpsでは、継続的デリバリーは「自動展開パイプライン」とも呼ばれます。
これには、コードが実稼働環境に近づくため、一般にエンドユーザーによって実行される「ユーザー受け入れテスト」のような手動テストと手動承認ゲートがいくつか含まれます。
さて、CDパイプラインの定義と、さまざまなテストフェーズの包含、テストフェーズと承認ゲートのいずれも、手動または自動のいずれかは、プログラム要件に基づいて組織によって異なります。
したがって、この図を見ると、継続的デリバリーには2つのパイプラインが含まれ、1つは自動ビルドトリガー、コンパイル、ビルド、およびデプロイで構成されるCIを含むパイプラインが構築されていると明確に言えます。
もう1つは、次のブロックで説明する「継続的テスト」を基本的に含むテストパイプラインです。
継続的デリバリーのアプローチを理解した後、継続的デリバリーの利点を照合しましょう。
継続的デリバリーは自動展開パイプラインであるため、明らかに、
#1。 配達数を増やす
#二。 CDは、数時間で実行されるのと同じくらい小さいサイクルです。そのため、CDは小さく、頻繁に展開されるため、本番環境で障害が発生するリスクが高くなります。
#3。 人間の介入が義務付けられている要件がない限り、パイプラインの最初から最後まですべてが自動化されます。そのため、多くの手作業が削減されます。
#4。 継続的デリバリーはチームへの信頼を高め、チームは「本番環境へのデリバリー」に備えることができ、彼らの心は常に本番環境で期待される品質とスピードに結び付けられます。
#5。 継続的デリバリーにより、開発と運用の両方が可能になり、パイプラインのすべてを自動化できます。これには、開発と運用のアクティビティ、トリガー、構築、単体テスト、展開、インフラストラクチャと環境の構成のコードとしての定義、より高いレベルのテスト(機能、セキュリティ、パフォーマンス、UIなど、)
#6 。大事なことを言い忘れましたが、継続的デリバリーは展開サイクルが短いため、チームは、開発環境だけでなく本番環境からも、デリバリーに関するフィードバックを迅速に得ることができ、ソフトウェアのデリバリーを低く抑えることができます。ストレス活動またはBAU、チームにとってはいつものようにビジネス。
これで、継続的デリバリーのアプローチとその利点について学び、完了しました。
今後のビデオでは、継続的デプロイとは何か、継続的デリバリーとはどのように違うのかについても理解しましょう。また、継続的テストのパイプラインについても学びます。
推奨読書
- DevOpsでの継続的デプロイ
- DevOpsでの継続的インテグレーション
- DevOpsでの継続的テスト
- DevOpsチュートリアル:DevOpsの究極のガイド(25以上のチュートリアル)
- DevOpsビデオチュートリアルの要約
- 継続的デリバリーチュートリアル:信頼性の高いソフトウェアリリースから本番環境へ
- DevOpsテストチュートリアル:DevOpsはQAテストにどのように影響しますか?
- Hudson継続的インテグレーションツールチュートリアル-Seleniumチュートリアル#25