Jenkins CI-私が見逃したこと

こんにちは、％ユーザー名％。 少し前までは、Jenkins \ Hudsonを使用することを強く推奨する、継続的インテグレーションサーバーのセットアップを求められました。 これらの問題について無知な人物として、ネットワーク上でCIシステムをセットアップする際のヒントとレビューを検討することにしました。 この記事についてWolonterに感謝します 。 これは、一般的な概念を理解するのに役立ち、最も有用なプラグインを幅広く提供しました。 しかし、結局のところ、私が実装したかったものとはまったく異なり、インターネットで見つけることができることが判明しました。 小さな（そしてそうではない）いたずらに興味を持っている人と、どうやって彼らに来たのか-猫をお願いします。

問題ステートメントの段階

そのため、最初のタスクは、Webサーバーを起動し、リポジトリの変更を追跡し、jUnit、TestNG、およびSeleniumのテストを実行するようシステムに教えることでした。 時間が経つにつれて、このタスクはたくさんのささいなもので大きくなりました。これについては後で説明します。 難しいことではないようですが、結局のところ、最初の意見は間違っています。 明確な良心を持って、提供された仮想マシンにcentos 6 x64をインストールし、CIをいくつかの動きでインストールしました。

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key sudo yum install jenkins
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当然、jdkをインストールし、jenkinsがスタートアップに追加されているかどうかを確認する必要があります。 このようなことで、Jenkins CIの最初の起動に失敗しました-Jenkinsのajpポートは、以前にインストールされたWebサーバー（パートタイムの非リレーショナルデータベース）の1つと競合していました。 構成ファイルでajpを無効にすると、すべてが適切に配置され、最終的に自分の目ですべての不思議を見ることができました。

間違い

セットアップ中に多くの間違いを犯したので、時間を節約したい人のために短いリストを提供します。

1. プロジェクト階層：かなり複雑な階層依存関係がある場合は、怠けすぎて葉を取り、何が何に依存しているかを考えないでください。理想的にはそうあるべきです。
2. すべてのプロジェクトを一度に設定しようとしないでください。 各プロジェクトを機能する中間状態にし、次のプロジェクトに切り替えてください。 あなたはいつもマラフェットを作る時間を持っています。
3. すべての依存プロジェクトの中間構成が終了するまで、プロジェクトの構成をなめないでください。 実装することを決定した機能は、非常に時間がかかるか、この段階ではまったくタスクではない可能性があります。 プラグインを作成することは、常に正当なアクティビティとは限りません。
4. プロジェクトの名前。 状況によっては、プロジェクトの名前を変更すると費用がかかる場合があります。 また、名前に構造が含まれていない130のプロジェクトの名前を変更する必要があることが突然明らかになった場合はどうでしょうか。 そのため、ひざの上で脚本を書いて、手で名前を変更することはできません。ヒキガエルがつぶれます。 簡単なヒントから名前まで：長すぎてはならず、有用な情報を伝えるべきです。 たとえば、同じ製品の複数のバージョンが異なるポートで実行されている場合、9587がポート番号である「ProjectAbbr9587」の精神でそれらに名前を付けてください。 このネーミングポリシーにより、発言内容をすぐに理解し、混乱する可能性を減らすことができます。
5. Jenkins CIを実行する予定のOSを選択できる場合は、自信のある上級ユーザーの場合はUnixを選択してください。 Jenkinsやその他のアプリケーションを実行しているユーザーのアクセス権に関する問題のほとんどがあります。 これが難しくない場合は、1人のユーザーに代わってすべてを実行してみてください。
6. ジェンキンス、ハイデガーがエンティティを生産するのを好む以上に覚えておいてください。 したがって、事前に、ユーザーjenkinsに代わって、起動されるスレッドとプロセスの最大数を増やします。 特に、負荷の高いCIサーバーがある場合
7. 表示されるすべてのプラグインをインストールしないでください。 多くの場合、「1回限りの使用」にはプラグインが必要であり、そのようなプラグインは基本スクリプトに置き換えることができます。 役に立つことは何もしませんが、余分なリソースを使い果たします（これはChuckNorris Pluginには当てはまりません）。
8. 事前にリソースの強度を見積もります。 格納するのが理にかなっているアセンブリの数を考えてください。 実際に必要なアーティファクトの数。 サーバーのパフォーマンスが低い場合は、多くのリソースを消費するアセンブリが同時に起動しないようにアセンブリスケジュールを検討し、使用されるリソースの数を監視したくない場合は、開始されたアセンブリの最大数が少なくとも、またはそれ以上であることを確認してくださいプロジェクト。
9. jUnit、TestNGなどの情報提供 特にグループ化されていない5,000を超えるユニットテストを実行する場合、ジェンキンスのような美しい結論であっても、必ずしも有益ではありません。 たぶん、異なるレポートでテストを再配置して配布するのが理にかなっていますか？
10. 安全性 彼女のことを忘れないでください。 パスワードアクセスへの切り替えは、妨害行為に熱中する個人の熱意を和らげるだけでなく、「あなたが私たちのためにすべてを壊した」という頭の「到着」の場合にも、「私ではなかった」という議論に反論する証拠が文書化されます。
11. Jenkins CIは開発者にとって補助的なツールであることを忘れないでください。何かできない場合は、サイクルを繰り返してはいけません。 おそらく、1週間以内に素晴らしい決定が頭に浮かぶかもしれませんし、同じ週にこの機能がそれほど必要でないという認識が来るかもしれません。 時にはこの知恵をプロジェクトマネージャーに説明する必要があります。プロジェクトマネージャーは、すべてが美しいという願望が常に正当化されるとは限りません。

誰もがこのリストに追加するものがあると思います。 しかし、すべての最も重要なことのように思われます。 そして、この短いリストが多くの人の時間を節約することを本当に願っています。

最初の試み

当然のことながら、最初の打ち上げ後、青い円を見るのは私にとっては珍しいことでしたが、その色はすぐには変わりませんでした。 SVNとGitをセットアップし、プロジェクト階層を配布しましたが、すべてが機能しているように見えました。 翌日、1つのタスクで4つの予定されたアセンブリがあり、開始されたアセンブリは約9時間続きました。 「悪い」コミットが行われたのはこの日になっていたため、ユニットテストは無限の待機状態になりました。 Build-timeoutプラグインが助けになりました。 一方、「無限のアセンブリ」にすべきプロジェクトがありました。 Webサーバーを実行し、アクションログをアセンブリに出力するAntタスク。これは非常に便利でした。 当然、これらのサーバーは数日間実行状態になる可能性があり、それらを停止する不必要な必要なしでは意味がありません。 仕事をしたり、顧客に結果を見せたりできます。 1日の特定の時間にブランチの更新があるかどうかをチェックし、存在する場合は更新をダウンロードしてアセンブリを再起動するプロジェクトを作成することにしました。 何よりもまず質問を投げかけたマネージャーの反応は、「なぜプロジェクトアセンブリのストリップが赤いのですか？ 「おそらく、午前10時で、アセンブリは過去6時間ログに何も書き込まなかったためです。」 ストリップを再描画する解決策はまだ見つかりませんでした（11項を参照）が、これは難しくないと思います。 非完了アセンブリには他の問題もありました。別のサーバーで2つのプロジェクトを作成せずに単体テストを実行する方法ですか？ 実際、これを実装するには、2つのantタスク 'a：' start-server 'と' junit 'を実行する必要があります。最初のタスクは終了しません。 別のサーバーで尋ねる理由：テストでメインのWebサーバーをテストするのは良くないからです。 さらに、テスト用のWebサーバーは、余分なリソースを無駄にしないために、必要に応じて、単体テストの期間のみ起動する必要があります。 アリのすべての可能性を思い出して、次のようなことをすることにしました：

 <target name="start-server-with-units"> <parallel> <daemons> <antcall target="start-server"> </antcall> </daemons> <sequential> <waitfor maxwait="10" maxwaitunit="minute"> <socket server="localhost" port="${port}" /> </waitfor> <antcall target="junit"> </antcall> </sequential> </parallel> </target>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正式には、サーバーが起動するまで待機し、単体テストを実行し、テストが完了したらサーバーの電源を切ります。 実際に必要なもの。 Jenkinsのツールでは、このようなプロジェクトを行うことは不可能だと思います。

枝

私の意見では、かき鳴らしのサポートはジェンキンスでは不十分です。 「Svn：//svn.adress：port / $ {branchName}」（branchNameは環境変数）は、多くの場合、問題を解決しません。 まず、このようなアセンブリは手動またはデフォルトのオプションでのみ開始できますが、Pall SCMを使用したアセンブリの開始はすでに明らかに不可能です。 誰かがこの種の機能を必要とする場合（私はまだそれを必要としていないことが判明したため）、明確な良心をもって、彼は起動時にbranchNameのデフォルト値を起動時に設定された値に変更してからプロジェクトを開始するgroovyスクリプトを作成できます通常のスケジュール、および必要に応じて、バージョン管理システムで更新のチェックを追加します。 このアプローチの欠点は、一連の不要なアセンブリでは、有用なものを見つけることが難しいことです。 しかし、これも重要ではありません。同じpostBuild groovyスクリプトで、「アイドル」アセンブリを削除する「ペダル」を固定できます。 更新を確認する別のプロジェクトを作成できる場合、このグルーヴィーなスクリプトの奇跡を思い付く価値はありますか？

結論：時々、別の自転車を書くよりも1つのプロジェクトを作成する価値がある場合があります。

また、かき鳴らしの問題に、 Build Name Setter Pluginを含めます。 ビルド番号の代わりにブランド名が表示されているのはとてもいいことですが、ここでもそれほど簡単ではありません。 なぜなら すべての変数に、文字列の最大長をトリミングするために使用できる長さ属性（環境変数など）があるわけではありません。 同意して、この外観はあまり動機付けられていませんが、長さが30ではなく255文字の場合はどうでしょうか？



この問題は、preBuild groovyスクリプトで再び解決できます。 しかし、私の状況では、ブランド名を有益なものにすることを依頼する方が簡単で、それほど長くはありませんでした。 自転車ではなく常識で何らかの不便を解決するのは非常に便利です。

自転車

私たちは皆人であり、私たちは皆、何らかの快適さを求めています。 プラグインを書きたくありませんでした。妥協する人はいませんでしたが、結果を達成したかったのです。 この理由から、私はここで何らかの形で私にとって生活を楽にしてくれたすべての自転車について説明します。

 if(manager.build.result == hudson.model.Result.ABORTED){ manager.build.@result = hudson.model.Result.SUCCESS }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜなら クロスをクリックするだけで完了するプロジェクト（「アセンブリをキャンセルする」）があり、灰色のボールに非常に落ち込んでいたので、アセンブリを成功させたかった（統計が損なわれないように、すべてが正しいことを知っている） 。 プラグインを実装したプラグインは見つかりませんでしたが、 Groovy Postbuildプラグインを見つけました。 そのため、groovyのpostbuild API（それを呼び出しましょう）はbuildSuccess（）メソッドを提供して、成功したビルド状態などを他の状態に設定します。 問題は、このメソッドが何もしないことです。 家族全員がアセンブリの現在の状態を悪化させることができるだけです。 AbortedはSuccessよりもはるかに悪く、アセンブリの状態は変化しませんでした。 かつてJenkins'eで、アセンブリのステータスを変更するための本格的な機能を実装する要求に3つの問題が見つかりました。 上記のコードは非常に単純なので、頭に収まりません。 「groovyには反射の類似物があるのではないか」という質問を自問自答しました。 フリルの倒錯の愛好家が感謝することを願っています。



ビルドプロモーション 。 はい、 Promoted Builds Pluginの存在については知っていますが、私の場合は再び役に立ちませんでした。 手作業でのみ更新され、手動ブランドを選択したサーバーが1つあり、2時間ごとに実行され、ギターブランチの最初のブランチを認識し、ダウンロードして単体テストを実行したプロジェクトがありました。 プロジェクト内のアセンブリの数は異なっていました。 合意により、最新の単体テストが成功した場合にスターを与えることが決定されました。 さらに、スターは最初のサーバーの完了時にのみ割り当てられます。 同意します。プロモートされたプラグインのかなり珍しい実装は、個人的なニーズのためだけに強化されました。

 item = hudson.model.Hudson.instance.getItem("jUnitJobName") def build = item.getLastBuild() if(build.getResult() == null){ build = build.getPreviousCompletedBuild() } def result = build.getResult() if(result == hudson.model.Result.SUCCESS){ manager.addBadge("star-gold.gif", "Success Unit Tests") } else { manager.addBadge("warning.gif", "Unit Tests Failure") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

手動テストとの戦い

たまたまテスターが異なっていました。 そして、何かがうまく機能しない理由を彼らが知っている可能性が非常に高いのは非常に残念ですが、彼らは事前に責任を先送りにしようとして、「私はすべてをうまくやったが、それは壊れた、あなたは修理している」と主張する そのような場合、 AnsiColor Pluginは非常に役立ちます。 これが機能しない場合は、より攻撃的な手段を使用することを強くお勧めします： Build User Vars Plugin-個人的な扱いにより、アクションがより恥ずかしくなります（マシンはどのように私の名前を認識しましたか？） 主なことは無理をしないことです。スクリプトが正常に機能しない状況が発生する可能性があります。テスターはコンソールに次のように書いたため、3日間の質問を恐れました。 この場合、すべての石はあなたに飛びます。 誰も愚か者のように見えるのが好きではありません。 しかし、あなたがそれを台無しにした場合-このようなものを手に入れてください（ ！

したい

まあ、結論として、私は物事を書きます-私はそれが本当に好きですが、私はプラグインを書きません。 実装されているかもしれませんが、見つかりませんでした。 ヒントについて-感謝します。

起動時にビルドを自動開始します 。 たとえば、電力サージ/光不足により、サーバーが再起動されました。 JenkinsCIはそれを開始しましたが、常に実行する必要があるプロジェクトは開始しませんでしたか？ ペンを実行するたびに-それはばかげています。 したがって、チェックマークが本当に必要です。「再起動後にこのプロジェクトを開始する必要がありますか？」

SVN \ Gitカスタムブランチ+パッチは、上記のイメージで更新された場合、既存のローカル変更をすべて上書きします。 これにより、パッチが非常に不便になります。 パッチをキャンセルし、目的のブランチをデフレートし、パッチを適用し直すスクリプトは本当に好きではありません。

システムメッセージ 「jenkins \ configuration \ System Message」のパフォーマンスの結果が、ビューだけでなくすべてのページに表示されたこと。 一般に、外観を変更するためのプラグインを増やしたいと思います。 なぜなら まず第一に、それは管理者の作業を容易にし、運用に関する質問が少ないほど、開発のための時間が残ります。

プラグインを再構築します。 Rebuild Pluginに以前のビルドを停止する方法を学んでもらいたい場合は、リビルドボタンをクリックして、彼は別のビルドのみを計画しました。

PS私が欲しいものは必需品とはほど遠いことを知っていますが、これらはおそらく完全な幸福のために十分ではないものです。 この記事が誰かに役立つことを願っています。