継続的デリバリーチュートリアル–Jenkinsを使用した継続的デリバリーパイプラインの構築

継続的デリバリー：

継続的デリバリーは、コードの変更が自動的に構築、テストされ、本番環境へのリリースに向けて準備されるプロセスです。あなたが私のを楽しんだことを願っています ここでは、次のトピックについて説明します。

• 継続的デリバリーとは何ですか？
• ソフトウェアテストの種類
• 継続的インテグレーション、デリバリー、デプロイメントの違い
• 継続的デリバリーの必要性は何ですか？
• JenkinsとTomcatを実際に使用する

継続的デリバリーがどのように機能するかを簡単に理解しましょう。

継続的デリバリーとは何ですか？

これは、いつでも本番環境にリリースできるようにソフトウェアを構築するプロセスです。次の図を検討してください。

上の図を説明しましょう：

• 自動ビルドスクリプトは、Gitなどのソースコード管理（SCM）の変更を検出します。
• 変更が検出されると、ソースコードが専用のビルドサーバーにデプロイされ、ビルドが失敗せず、すべてのテストクラスと統合テストが正常に実行されていることを確認します。
• 次に、ビルドアプリケーションは、ユーザー受け入れテスト（UAT）用のテストサーバー（運用前サーバー）に展開されます。
• 最後に、アプリケーションはリリースのために本番サーバーに手動でデプロイされます。

先に進む前に、さまざまな種類のテストについて説明するのは公平です。

ソフトウェアテストの種類：

大まかに言えば、テストには2つのタイプがあります。

• ブラックボックステスト： これは、システムの内部メカニズムを無視し、システムの入力と実行に対して生成された出力に焦点を当てたテスト手法です。機能テストとも呼ばれます。これは基本的にソフトウェアの検証に使用されます。
• ホワイトボックステスト： は、システムの内部メカニズムを考慮に入れたテスト手法です。構造テストやガラスボックステストとも呼ばれます。基本的にソフトウェアの検証に使用されます。

ホワイトボックステスト：

このカテゴリに分類されるテストには2つのタイプがあります。

• ユニットテスト： これは、個々のユニットまたは関連するユニットのグループのテストです。プログラマーは、実装したユニットが特定の入力に対して期待される出力を生成していることをテストするためによく行われます。
• 統合テスト： これは、コンポーネントのグループが組み合わせて出力を生成します。また、ソフトウェアとハ​​ードウェアのコンポーネントに何らかの関係がある場合は、ソフトウェアとハ​​ードウェア間の相互作用がテストされます。ホワイトボックステストとブラックボックステストの両方に該当する可能性があります。

ブラックボックステスト：

このカテゴリに分類される複数のテストがあります。私は焦点を当てますいくつか、このブログを理解するために知っておくべき重要なこと：

• 機能/受け入れテスト： これにより、システム要件で必要とされる指定された機能が確実に機能します。納品された製品が要件を満たし、顧客の期待どおりに機能することを確認するために行われます。
• システムテスト： ソフトウェアをさまざまな環境（オペレーティングシステムなど）に配置することで、ソフトウェアが引き続き機能することを保証します。
• ストレステスト： これは、システムが不利な条件下でどのように動作するかを評価します。
• ベータテスト： これは、エンドユーザー、開発外のチーム、または製品の完全なプレバージョンを公開することによって行われます。ベータバージョン。ベータテストの目的は、予期しないエラーをカバーすることです。

継続的インテグレーション、デリバリー、デプロイメントの違いを説明するのに今が正しい時期です。

継続的インテグレーション、デリバリー、デプロイメントの違い：

視覚的なコンテンツは、テキスト情報よりも速く、より理解しやすい方法で個人の脳に到達します。そこで、違いを明確に説明する図から始めます。

継続的インテグレーションでは、すべてのコードコミットがビルドおよびテストされますが、リリースされる状態ではありません。つまり、ビルドアプリケーションは、ユーザー受け入れテスト（UAT）などのさまざまなタイプのブラックボックステストを使用して検証するために、テストサーバーに自動的にデプロイされません。

継続的デリバリーでは、アプリケーションはUATのテストサーバーに継続的にデプロイされます。または、アプリケーションをいつでも本番環境にリリースする準備ができていると言えます。したがって、継続的デリバリーには明らかに継続的インテグレーションが必要です。

継続的デプロイは継続的デリバリーの次のステップであり、デプロイ可能なパッケージを作成するだけでなく、実際には自動化された方法でデプロイします。

表を使用して違いを要約します。

簡単に言うと、継続的インテグレーションは継続的デリバリーと継続的デプロイの両方の一部です。また、継続的デプロイは継続的デリバリーに似ていますが、リリースが自動的に行われる点が異なります。

Jenkins OnCloudを使用してCI / CDパイプラインを作成する方法を学ぶ

しかし、問題は、継続的インテグレーションで十分かどうかです。

なぜ継続的デリバリーが必要なのですか？

例を挙げてこれを理解しましょう。

大規模なプロジェクトに取り組んでいる80人の開発者がいると想像してください。自動ビルドを容易にするために、継続的インテグレーションパイプラインを使用しています。ビルドにはユニットテストも含まれていることはわかっています。ある日、単体テストに合格した最新のビルドをテスト環境にデプロイすることにしました。

これは、環境スペシャリストが実行した、時間のかかる、しかし制御された展開アプローチである必要があります。ただし、システムは機能していないようです。

失敗の明らかな原因は何でしょうか？

さて、ほとんどの人が考える最初の理由は、構成に問題があるということです。ほとんどの人のように、彼らもそう思っていました。彼らは、環境の構成のどこが悪いのかを見つけるために多くの時間を費やしましたが、問題を見つけることができませんでした。

ある知覚開発者は賢いアプローチを取りました：

次に、上級開発者の1人が自分の開発マシンでアプリケーションを試しました。そこでも機能しませんでした。

JavaScriptの配列の長さ

彼は、システムが3週間前に動作を停止したことを発見するまで、以前のバージョンと以前のバージョンをステップバックしました。小さな、あいまいなバグにより、システムが正しく起動できませんでした。ただし、プロジェクトの単体テストカバレッジは良好でした。それにもかかわらず、通常はアプリケーション自体ではなくテストのみを実行した80人の開発者は、3週間問題を認識しませんでした。

問題文：

実稼働環境のような環境で受け入れテストを実行しないと、アプリケーションが顧客の仕様を満たしているかどうか、また、アプリケーションを実世界で展開して存続できるかどうかについては何もわかりません。これらのトピックに関するタイムリーなフィードバックが必要な場合は、継続的インテグレーションプロセスの範囲を拡大する必要があります。

上記の問題を見て学んだ教訓を要約しましょう。

• 単体テストは、問題の解決策に関する開発者の視点のみをテストします。アプリケーションがユーザーの観点から想定どおりに動作することを証明する能力は限られています。彼らは十分ではありません実際の機能上の問題を特定します。
• テスト環境へのアプリケーションのデプロイは、複雑で手動を多用するプロセスであり、エラーが発生しやすくなりました。これは、展開のすべての試みが新しい実験であり、手動でエラーが発生しやすいプロセスであることを意味しました。

ソリューション–継続的デリバリーパイプライン（自動受け入れテスト）：

彼らは継続的インテグレーション（継続的デリバリー）を次のステップに進め、アプリケーションが実行され、その最も基本的な機能を実行できることを証明する、いくつかの単純な自動受け入れテストを導入しました。受け入れテスト段階で実行されるテストの大部分は、機能的受け入れテストです。

基本的に、彼らは、アプリケーションが本番サーバーのレプリカであるテストサーバーにデプロイされたときに正常に動作することを確認することにより、アプリケーションが本番環境にシームレスにデプロイされることを保証するために、継続的デリバリーパイプラインを構築しました。

理論はこれで十分ですが、Jenkinsを使用して継続的デリバリーパイプラインを作成する方法を説明します。

Jenkinsを使用した継続的デリバリーパイプライン：

ここでは、Jenkinsを使用して継続的デリバリーパイプラインを作成します。これには、次のタスクが含まれます。

デモに含まれる手順：

• GitHubからコードを取得する
• ソースコードのコンパイル
• ユニットテストとJUnitテストレポートの生成
• アプリケーションをWARファイルにパッケージ化し、Tomcatサーバーにデプロイします

前提条件：

• CentOS7マシン
• Jenkins 2.121.1
• Docker
• Tomcat 7

ステップ– 1ソースコードのコンパイル：

まず、JenkinsでFreestyleプロジェクトを作成することから始めましょう。以下のスクリーンショットを検討してください。

プロジェクトに名前を付けて、[フリースタイルプロジェクト]を選択します。

下にスクロールすると、ソースコードリポジトリを追加するオプションがあり、gitを選択してリポジトリURLを追加します。そのリポジトリには、プロジェクトのビルドに使用するpom.xml罰金があります。以下のスクリーンショットを検討してください。

次に、ビルドトリガーを追加します。ポーリングSCMオプションを選択します。基本的に、コードの変更について5分ごとにGitHubリポジトリをポーリングするようにJenkinsを構成します。以下のスクリーンショットを検討してください。

先に進む前に、Mavenビルドサイクルについて簡単に紹介します。

各ビルドライフサイクルは、ビルドフェーズの異なるリストによって定義されます。ビルドフェーズは、ライフサイクルのステージを表します。

以下は、ビルドフェーズのリストです。

• 検証–プロジェクトが正しく、必要なすべての情報が利用可能であることを検証します
• コンパイル–プロジェクトのソースコードをコンパイルします
• test –適切な単体テストフレームワークを使用して、コンパイルされたソースコードをテストします。これらのテストでは、コードをパッケージ化またはデプロイする必要はありません。
• パッケージ–コンパイルされたコードを取得し、JARなどの配布可能な形式でパッケージ化します。
• 検証–統合テストの結果に対してチェックを実行して、品質基準が満たされていることを確認します
• install –ローカルの他のプロジェクトの依存関係として使用するために、パッケージをローカルリポジトリにインストールします
• デプロイ–ビルド環境で実行され、他の開発者やプロジェクトと共有するために最終パッケージをリモートリポジトリにコピーします。

以下のコマンドを実行して、ソースコードのコンパイル、単体テスト、さらにはアプリケーションをwarファイルにパッケージ化することもできます。

mvnクリーンパッケージ

ビルドジョブをいくつかのビルドステップに分割することもできます。これにより、ビルドをクリーンで個別のステージに簡単に整理できます。

そこで、ソースコードをコンパイルすることから始めます。 [ビルド]タブで、[トップレベルのMavenターゲットを呼び出す]をクリックし、次のコマンドを入力します。

コンパイル

以下のスクリーンショットを検討してください。

これにより、GitHubリポジトリからソースコードがプルされ、コンパイルされます（Mavenコンパイルフェーズ）。

[保存]をクリックして、プロジェクトを実行します。

次に、コンソール出力をクリックして結果を確認します。

ステップ– 2ユニットテスト：

次に、ユニットテスト用にもう1つのフリースタイルプロジェクトを作成します。

前のジョブで行ったように、ソースコード管理タブに同じリポジトリURLを追加します。

次に、[Buid Trigger]タブで、[他のプロジェクトがビルドされた後にビルドする]をクリックします。ソースコードをコンパイルしている前のプロジェクトの名前を入力し、以下のオプションのいずれかを選択できます。

• ビルドが安定している場合にのみトリガーします
• ビルドが不安定な場合でもトリガーします
• ビルドが失敗してもトリガーする

上記のオプションはかなり自明だと思うので、いずれかを選択してください。以下のスクリーンショットを検討してください。

[ビルド]タブで、[トップレベルのMavenターゲットを呼び出す]をクリックし、次のコマンドを使用します。

テスト

Jenkinsは、テスト結果とテスト結果の傾向を表示するのにも役立ちます。

Javaの世界でのテストレポートの事実上の標準は、JUnitで使用されるXML形式です。この形式は、TestNG、Spock、Easybなどの他の多くのJavaテストツールでも使用されます。 Jenkinsはこの形式を理解しているため、ビルドでJUnit XMLテスト結果が生成される場合、Jenkinsは、時間の経過に伴うテスト結果に関する優れたグラフィカルテストレポートと統計を生成し、テストの失敗の詳細を表示することもできます。 Jenkinsは、グローバルとテストごとの両方で、テストの実行にかかる時間を追跡します。これは、パフォーマンスの問題を追跡する必要がある場合に役立ちます。

したがって、次に行う必要があるのは、Jenkinsにユニットテストを監視させることです。

[ビルド後のアクション]セクションに移動し、[JUnitテスト結果レポートを公開する]チェックボックスをオンにします。 Mavenがプロジェクトで単体テストを実行すると、surefire-reportsというディレクトリにXMLテストレポートが自動的に生成されます。。したがって、「テストレポートXML」フィールドに「** / target / surefire-reports/*。xml」と入力します。パスの先頭にある2つのアスタリスク（「**」）は、構成をもう少し堅牢にするためのベストプラクティスです。これらのアスタリスクにより、Jenkinsがソースコードをチェックアウトするように構成した方法に関係なく、Jenkinsがターゲットディレクトリを見つけることができます。

** / target / surefire-reports/*。xml

もう一度保存して、[今すぐビルド]をクリックします。

これで、JUnitレポートは/ var / lib / jenkins / workspace / test / gameoflife-core / target / surefire-reports / TEST-behaviorに書き込まれます。

Jenkinsダッシュボードまた、テスト結果に気付くことができます。

ステップ– 3 WARファイルを作成してTomcatサーバーにデプロイする：

次のステップは、アプリケーションをWARファイルにパッケージ化し、ユーザー受け入れテストのためにそれをTomcatサーバーにデプロイすることです。

もう1つのフリースタイルプロジェクトを作成し、ソースコードリポジトリのURLを追加します。

次に、[ビルドトリガー]タブで、他のプロジェクトがビルドされたときにビルドを選択します。以下のスクリーンショットを検討してください。

基本的に、テストジョブの後、展開フェーズが自動的に開始されます。

[ビルド]タブで、シェルスクリプトを選択します。以下のコマンドを入力して、アプリケーションをWARファイルにパッケージ化します。

mvnパッケージ

次のステップは、このWARファイルをTomcatにデプロイすることです。サーバ。 「ビルド後のアクション」タブで、「war / earをコンテナーにデプロイする」を選択します。ここで、warファイルへのパスとコンテキストパスを指定します。以下のスクリーンショットを検討してください。

Tomcat資格情報を選択し、上のスクリーンショットに注目してください。また、TomcatサーバーのURLを指定する必要があります。

Jenkinsに資格情報を追加するには、Jenkinsダッシュボードの資格情報オプションをクリックします。

[システム]をクリックして、グローバル資格情報を選択します。

次に、資格情報を追加するオプションがあります。それをクリックして、資格情報を追加します。

Tomcat資格情報を追加します。以下のスクリーンショットを検討してください。

[OK]をクリックします。

プロジェクト構成で、前の手順で挿入したTomcat資格情報を追加します。

[保存]をクリックして、[今すぐビルド]を選択します。

コンテキストパスを使用してTomcatURLに移動します。私の場合はhttp：// localhost：8081です。最後にコンテキストパスを追加します。以下のスクリーンショットを検討してください。

リンク-http：// localhost：8081 / gof

コンテキストパスの意味を理解していただければ幸いです。

次に、パイプラインビューを作成します。以下のスクリーンショットを検討してください。

プラスアイコンをクリックして、新しいビューを作成します。

パイプラインを希望どおりに構成します。以下のスクリーンショットを検討してください。

最初の仕事を選ぶ以外は何も変えませんでした。だから私のパイプラインはコンパイルから始まります。他のジョブを構成した方法に基づいて、コンパイル後にテストとデプロイメントが行われます。

最後に、[実行]をクリックしてパイプラインをテストできます。 5分ごとに、ソースコードに変更があった場合、パイプライン全体が実行されます。

そのため、ユーザー受け入れテスト（UAT）のために、アプリケーションをテストサーバーに継続的にデプロイできます。

継続的デリバリーに関するこの投稿をお楽しみいただけたでしょうか。ご不明な点がございましたら、下のコメント欄にご記入ください。早急に回答させていただきます。

CI / CDパイプラインを構築するには、さまざまなスキルを習得する必要があります 必要なDevOpsスキルを今すぐマスターする