継続的な統合とジェンキンスCIサーバーへの主要なガイドライン

キーポイント

• 継続的な統合（CI）とJenkins CIサーバーは、最新のソフトウェア開発に不可欠なツールであり、チームが高品質のソフトウェアをリリースし、繰り返しプロセスを自動化することで時間を節約できます。
• CIはテストの自動化を強調し、テストエンジニアが探索テストとエッジケースに集中できるようにしながら、開発者が提出してから数分以内に特定のブランチでの各コミットの品質を確保できるようにします。
• Jenkins CI Serverは、既存のプラグインまたは新しいプラグインを作成してカスタマイズできるオープンソースCIツールです。複数のマシンでタスクを割り当て、Pythonを含むさまざまな言語でのプロジェクトの継続的な統合を処理することにより、並行構築をサポートします。
• Jenkinsにはより多くのセットアップとメンテナンスが必要ですが、その柔軟性と制御性、およびその無料のオープンソース機能により、他のCIサーバーよりも強力な選択肢があります。また、さまざまなバージョン制御システムとうまく統合されており、さまざまなプロジェクトの普遍的なツールになります。

この記事はもともとTestProject -Test Automation Blog

で公開されました。

以下では、ソフトウェア開発における本質的な実践である連続統合（CI）と、業界標準のオープンソース連続統合ツールであるJenkinsを詳細に紹介します。継続的な統合とJenkins CIサーバーを実装することにより、Jenkinsの展開が開発チームがより高品質のソフトウェアをリリースし、貴重な時間を節約するのに役立つ方法を学びます。

---

ジェンキンスと継続的な統合についてもっと知りたいですか？次のリンクを確認してください：

• 画面録画：どの連続統合ツールがBitBucketをサポートしていますか？
• ジェンキンスでPHPプロジェクトを準備して構築します
Jenkinsとの継続的な統合
• 再導入ジェンキンス：パイプラインを使用した自動テスト
• インストールと保護jenkins

---

最新のソフトウェア開発慣行では、生産環境でできるだけ早く、または頻繁に完全に機能するソフトウェアを展開する必要があります。たとえば、アジャイルアプローチは、チームを少しずつ作業させ、各スプリントの後に生産環境に展開することにより、この動作を直接実施します（アジャイルプロジェクトのテスト自動化戦略）。

開発チームは、ソフトウェアの開発を数ヶ月費やしてから、QA、UAT、およびすべての生産ラインに渡すことはもう存在しませんでした。今日、完全に機能的なソフトウェアを持つことに焦点が当てられており、リリースサイクルの終わりに重要なソフトウェアの変更を導入するなど、ソフトウェアの品質を危険にさらす状況を許可することはありません。これは、継続的な統合が機能する場所です。

CIとは何ですか？

CIは、テストされたコードを頻繁にプロジェクトの安定した分岐に頻繁に統合するための戦略を強制するプラクティスです。特に「テストされたコード」を強調したいと思います。これは、別々のブランチで開発された機能がテストされ、したがって安定した分岐に統合されていることを意味するためです。

誰がCIをしていますか？

通常、DevOpsエンジニアは通常、CIパイプラインのセットアップを担当します。今日、DevOpsエンジニアの役割は、プロセスとソフトウェアの品質を確保するため、テストエンジニアの役割と非常に似ています。私は通常、QAと生産が顧客に最も近い交差点であると言います。この意味で、CIは、テストエンジニアに、次の領域に積極的に参加することで、全体的なプロセスとソフトウェアの品質を改善するための非常に強力なツールを提供します。

テスト自動化：数年前、人々は手動テストと自動テストについて議論しました。 CIを使用すると、テスト自動化が不可欠になり、最終的には他のテストタスクに焦点を当てた貴重な時間を大幅に節約できます。また、手動テストと自動テストは相互に排他的ではないことに言及する価値があります。
テストレポート：CIでのテストレポートについては、既存のレポートソリューションを使用したり、独自のレポートモジュールを構築したりできます。どちらの場合も、これはすべてのビルド実行におけるアプリケーションコードがどれだけうまくいくかを明確に示しています。すべての開発チームメンバーがこの情報にアクセスできることが重要であり、コードの品質を向上させるために引き続き機能します。
展開プロセス：テストエンジニアは、アプリケーションの展開プロセスにより深く関与しており、使用されるテスト自動化ツールまたはフレームワークの内部アーキテクチャに関する追加情報を提供します。この知識は、特に「隠された」アプリケーションの問題を特定する場合に非常に重要です。

ci

の利点

CIは、テストの自動化を強調し、テストエンジニアが探索的テスト、エッジケーステスト、さらには新しいテスト方法を見つけることさえできるようにします。
特定のブランチでの特定のコミットの品質は、開発者の提出から数分以内に表示されます。
ブランチでコードがテストされた後、安定したブランチに統合することは非常に慎重です（CIプロセスはこの操作を実行する必要があります）。アプリケーションの展開は、繰り返しコマンドなしで正しくセットアップされると自動的に実行されます。
これらの利点はすべて、チームの観点から指数関数的に増加します。

典型的なCIシナリオ

開発チームには、プロジェクトを含む独自のソースコードバージョンコントロールリポジトリがあります（通常はGitHub）。安定した枝（メインブランチ）は、多くの場合、作業枝と見なされ、メインブランチで直接新しい機能を開発することはめったにありません。代わりに、開発者は独自のブランチを作成して、新しい機能（機能AのブランチA）を開発します。その特定のブランチのリポジトリに変更がプッシュされ、開発者がプルリクエストを行う場合、そのブランチに対していくつかの基本的なテストセット（煙検査）を実行する必要があります。 CIの観点から、これは通常、次のことを意味します。

CIプロセスが完了すると、テストエンジニアと開発者の観点からいくつかの要件があります。

• テスター：Branch Aの関数を再度再テストします
• 開発者：別の開発者がピアコードレビューを実施して、コードが十分な品質であることを確認してください
• 開発者：コードをメインブランチに手動でマージし、マージ競合を解決します（発生した場合）。

煙検査は、コードレビューを受けている開発者と、プルリクエストブランチで機能を再テストする必要があるテストエンジニアにとって多くの時間を節約します。プルリクエストの煙検査が失敗した場合、機能Aの責任のある開発者が煙検査機能を修正し、新しいプルリクエストを発行する責任があります（問題が修正されるまで、問題のあるコードはメインブランチに統合されません）。

これが行われ、関数Aの新しいコードがCIの観点からメインブランチにマージされた場合、次のことが発生します。

これは、マージが成功し、煙検査機能が依然として有効であることを示しています。今では、メインブランチに再び機能を再テストすることはテストエンジニアの責任です（マージに副作用がないことを確認するために機能a）。もちろん、ほとんどの機能をカバーするために、時間の経過とともにテスト自動化スイートを強化することは良い習慣です。

これは、テストエンジニアにはより多くのタスクがあるため、プロジェクトの遅い繰り返しでますます重要になります（現在の機能と以前のすべての機能をテストします）。これは、回帰テストが役立つ場所です。CIの観点から、回帰テストの実行は通常、テストエンジニアが回帰テストを明示的に実行するとき、またはスケジューラを使用したときに発生します（たとえば：毎晩回帰テストの実行）。このジョブをカスタマイズするのは良い習慣であり、このジョブが実行されるブランチを指定できることを指定できます（ここでは、回帰テスト自動化を実行する理由とタイミングについて詳しく読むことができます）。プロセスは次のとおりです

Jenkinsツールの紹介

Jenkins CI Server Terminology

宿題：ジェンキンスの用語で最も重要な「ユニット」は宿題です。ジョブは、Jenkins CIサーバーの単一の実行ユニットであり、特定の結果（合格/失敗）が必要です。たとえば、ジョブは展開ジョブ、煙検査の仕事、回帰テストジョブなどです。ジョブは、順番に実行された複数の領域で構成されており、次の段落で説明されます。ジェンキンスの仕事の構造です。

プラグイン：Jenkins Test Automationの主な機能の1つは、既存のプラグインを使用するか、独自のプラグインを作成してカスタマイズできることです。ジョブ構成セクションからジェンキンス構成セクションまで、Jenkinsツールのすべては、実際にはプラグインです。 Jenkinsのコミュニティの大きさが大きいため、最も要求の厳しいCIワークフロータスクのニーズを満たすために、さまざまなJenkinsプラグインがすでに存在しています。これは、カスタムソリューションを作成する代わりに、おそらく便利なプラグインに出くわす可能性が高いことを意味します。

ノード：最も単純なセットアップでは、Jenkinsインスタンスはすべてのジョブが実行されるマシンで実行されます。小規模なテストと少量の割り当ての場合、これは理にかなっています。ただし、実際には、複数のチームが同じJenkinsインスタンスを使用する場合がよくあります。彼らは多数の仕事を持っているので、次の理由でインスタンスで実行するのは悪いと考えられています：セキュリティ、災害復旧、パフォーマンス、スケーラビリティなど。

ジェンキンスにマスター/スレーブを入力：ジェンキンスマスターノードは、ジェンキンススレーブで実行されるジョブをスケジュールするためにのみ使用されます。このようにして、ジェンキンスのホストは頻繁に使用されておらず、チームにはテスト自動化プロジェクトに最適な独自の奴隷マシンがあります。さらに、スレーブノードは、実行されるいくつかの並列ジョブを処理するように構成されています（ノードあたりのエグゼキューターの数）。 AWSからオンデマンドノードを構成することもできます。これは、ジョブを実行する必要がある場合にのみノードが存在することを意味します。これは非常に便利です。これは、回帰テストを実行するときにのみ完全に使用される大型マシンが必要なためです。この場合、ジョブが実行されるAWSでより大きなEC2インスタンスが起動し、完了時に（構成のアイドル時間に基づいて）、インスタンスは一定期間アクティブのままになります。その後、AWSサービスなど、1時間ごとの有料サービスを使用する場合、どのアプローチがより有利であるかを決定します。

Jenkins Jobの構造

Jenkins CIサーバーでは、各Jenkinsのジョブに複数の部品が含まれています。

• 一般：ここでは、プロジェクト/ジョブ名/説明を指定し、必要に応じてジョブパラメーターを追加し、ジョブログローテーション戦略を定義します。次の画面は、ログ回転の構成方法を示しています（ビルドログを維持する日数または保持する最後のビルドログの数を指定できます）、ジョブをパラメーター化する方法（文字列build_idをデフォルト値に追加することにより0.0.1ただし、この値はジョブを開始するときに指定できます）と、このジョブが実行される場所を構成する方法（スレーブノード名）：

  

  

• ジェンキンスのソースコード管理：名前が示すように、これはジェンキンスCIサーバーのソースコードリポジトリ（GitHubやSubversionなど）を定義する場所です：

  

• Jenkins Build Trigger：ジョブの実行時間をスケジュールします（定期的に、他のジョブの後、GitHub Pullリクエストが発生したとき、変更がGithubにプッシュされるなど）。

  

• ジェンキンスビルド環境：ここでは、ビルドが実行される環境に関連するオプションを定義します（ジョブが実行されるたびにワークスペースを削除し、一定期間停止されている場合はジョブを中止します...など）。

  

• Jenkins Build：Jenkins CIサーバーでは、これが各ジョブにとって最も重要なステップです。このステップの結果は、実行の終了時のジョブのステータスに影響します。インストールされているプラ​​グインに応じて、多くのオプションが利用可能です。最も一般的に使用されるプラグインは、シェルの実行、グルーヴィーなスクリプトの実行、ANT/Maven/Gradleスクリプトの呼び出し、Windowsバッチコマンドの実行などです。

  

  これは、独自のシェルスクリプトをインラインにしたり、既存のシェルスクリプトを実行できる頻繁に使用される「Execute Shell」プラグインの例です。

• Jenkins後の操作：ジョブのこの部分は、ジョブの結果を報告するために、またはJenkinsパイプラインの他のジョブに電話するために使用されます。一般的に、ジョブの実行ステータスを含む電子メールを送信し、HTMLレポートを公開、Junitの結果、ビルドステージに組み込まれたアーティファクトをS3に公開できます。

  

  メールの件名で$ build_idがどのように指定されているかに注意してください。このジョブはパラメーター化されているため、この値はジョブの開始時に指定されます。このパラメーターは、ジョブのJenkinsビルドおよびビルド後のオペレーションセクションで使用できます。

結論

これまでのところ、Jenkins CIサーバーの主な利点と、CI自体がソフトウェア開発プロセスとテストエンジニアにどのように追加されるかを学びました。他のテクノロジーと同様に、基本を習得し、利点を体験するには時間がかかります。 CIに時間を費やすことを強くお勧めします。これは、長期的には間違いなく価値があります。特に、Jenkins CIサーバーが適用されると、多くの痛みを伴う繰り返しのプロセスが自動化され、突然製品の改善に集中する時間があります。

あなたのチームは、継続的な統合とJenkins CIサーバーも実装しましたか？チームの経験を自由に共有し、コメントで質問をしてください！

---

この記事はもともとTestProject -Test Automation Blog

で公開されました。Jenkins CIサーバーとの継続的な統合に関するFAQ

ジェンキンスとトラビスCIの主な違いは何ですか？

JenkinsとTravis CIはどちらも人気のある連続統合ツールですが、いくつかの重要な違いがあります。 Jenkinsは、独自のサーバーを管理および維持する必要がある自己ホストのソリューションです。高度にカスタマイズ可能で、ほぼすべてのCI/CDワークフローに対応するように構成できます。一方、Travis CIは、セットアップと使用が簡単なクラウドベースのサービスです。 GitHubとうまく統合され、箱から出して多くの言語をサポートしています。ただし、複雑なワークフローでは、ジェンキンスほど柔軟ではない場合があります。

ジェンキンスはgitlab ci/cdとどのように比較されますか？

JenkinsとGitlab CI/CDはどちらも強力な連続統合ソリューションを提供します。 Jenkinsは柔軟性と大規模なプラグインエコシステムで知られていますが、Gitlab CI/CDはGitLabエコシステムとのシームレスな統合を称賛しています。 Gitlab CI/CDは、組み込みのDockerサポートも提供しています。これは、Dockerを使用するチームにとって大きな利点になる可能性があります。

他のCIサーバーの代わりにJenkinsを使用することの利点は何ですか？

ジェンキンスは、他のCIサーバーよりもいくつかの利点を提供します。オープンソースであり、大規模でアクティブなコミュニティがあります。つまり、常に改善され、更新されています。また、特定のニーズに合わせて機能を拡張できるようにするプラグインの巨大なエコシステムもあります。さらに、Jenkinsはさまざまな言語とツールをサポートしており、さまざまなプロジェクトで一般的な選択肢となっています。

JenkinsはPythonプロジェクトの継続的な統合をどのように処理しますか？

ジェンキンスは、Pythonプロジェクトの継続的な統合を処理する普遍的なツールです。 Pythonアプリケーションの構造、テスト、展開を自動化し、多くの一般的なPythonテストフレームワークをサポートします。 Jenkinsは、GITなどのバージョン制御システムともうまく統合されており、既存のワークフローに簡単に統合できます。

ジェンキンスとトラビスCIの間で選択する際の重要な考慮事項は何ですか？

JenkinsとTravis CIのどちらかを選択する場合は、チームの技術的専門知識、CI/CDワークフローの複雑さ、予算などの要因を考慮する必要があります。 Jenkinsはより多くのセットアップとメンテナンスを必要としますが、より柔軟性と制御を提供します。 Travis CIはセットアップと使用が簡単ですが、複雑なワークフローには柔軟性がない場合があります。また、有料のサービスであり、ジェンキンスは無料でオープンソースです。

ジェンキンスはCI/CDパイプラインをどのようにサポートしていますか？

Jenkinsは、コード配信のすべてのフェーズを自動化することにより、統合とテストからテストから展開までのCI/CDパイプラインをサポートしています。開発者はコードの問題を迅速に特定して修正できるため、継続的なフィードバックが可能になります。 Jenkinsはまた、CI/CDエコシステムのさまざまなツールと統合されており、CI/CDパイプラインを実装するための一般的な選択肢となっています。

ジェンキンスは、GitHubでホストされていないプロジェクトに使用できますか？

はい、ジェンキンスはGitHubでホストされていないプロジェクトに使用できます。 Subversion、Mercurial、Perforceなど、さまざまなバージョン制御システムをサポートしています。これにより、ジェンキンスは、異なるバージョン制御システムを使用してチームにとって普遍的な選択になります。

ジェンキンスは並行ビルドをどのように処理しますか？

ジェンキンスは、複数のマシンまたはエグゼキューター間でタスクを割り当てることにより、並列ビルドを処理します。これにより、ビルド時間を速くし、より効率的なリソース利用が可能になります。 Jenkinsを構成して、ビルドインフラストラクチャを自動的に管理するか、どのマシンで実行するかを手動で指定できます。

ジェンキンスをセットアップする際に遭遇する一般的な課題は何ですか？

Jenkinsのセットアップの場合、いくつかの一般的な課題には、依存関係の管理、ビルドトリガーの構成、安全なアクセスのセットアップが含まれます。ただし、ジェンキンスには大規模でアクティブなコミュニティがあるため、これらの課題を克服するのに役立つ多くのリソースがあります。

ジェンキンスの機能を拡張する方法は？

プラグインをインストールして、Jenkinsの機能を拡張できます。 Jenkinsには、さまざまなバージョン制御システムとの統合からユーザーインターフェイスの改善まで、さまざまな機能のプラグインを含むプラグインの巨大なエコシステムがあります。既存のプラグインによって提供されていない機能が必要な場合は、独自のプラグインを作成することもできます。

以上が継続的な統合とジェンキンスCIサーバーへの主要なガイドラインの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。