ラベル Jenkins の投稿を表示しています。 すべての投稿を表示
ラベル Jenkins の投稿を表示しています。 すべての投稿を表示

2012年7月30日月曜日

Jenkinsハッカソンに参加してきました。

私がヴィムである。

そろそろこのネタ飽きてきましたね。

ビーサンとボロボロのジーンズで…


熱いオッサンのできるビジネスマンの溢れる街

溜池山王で開催された

Jenkinsハッカソンに行ってきました。


内容はプラグインを作ってみること


川口さんやJenkinsのコミッターの皆さんと一緒の部屋で、

Jenkinsプラグインを作成するという

非常に濃ゆいハッカソンでした。


具体的な手順などは


ここを参照して下さい。

僕は二度三度と同じ事をやらないと覚えられないくらい

残念な頭の持ち主なので、

Hello World的なプラグインを2回ほどつくりました。

プラグインのUI(jellyファイル)とhudson.tasks.Builder

あたりはなんとか理解できた気がします。


作りたいもの


本当はFxJsJUnit用のプラグインを作りたいと思っています。

で、そんな話をしたら、参加していたインド出身のエンジニアの方に

興味を持っていただきました。

嬉しいですね!

8月のオレオレタスク早めに終わらせて、

FxJsJUnit作りを早めようかな!







2012年7月29日日曜日

Jenkinsカンファレンス2012に行ってきたよ

私がヴィムである。

あじ~、だりぃと言う猛暑の中、

Jenkinsカンファレンス2012を聴講しに行って来ましたよ。

え、おい!


会場に到着して、前の方の席に言った途端、

いんだれさんに声かけられました。

「みけ、手伝って!」

というわけで、そのまま拉致られて

即席スタッフになりました。


その結果


JenkinsのTシャツもらいました。


ありがとうございます。


印象


参加申込みは1,000人を超えているようでした。

実際は少ないと思いますが…。

凄いですね。

というわけで、Jenkinsに対する関心が高いことがよくわかりました。


セッション?


まあ、スポンサーセッション担当ということで、

スポンサーセッションをずっと聞いていました。

とはいえ、スタッフなので全体がうまく流れることのほうが

気がかりで、とても話を聞いているような状態ではなかったのですが…


内容としてはプロジェクトやチームに

Jenkinsをどのように適用していくか?

という話題が多かったと思います。


懇親会


行きませんでした(´・ω・`)


結論


JenkinsはContinuous Integration/Delivery の

デファクトスタンダードツールとしての地位を

獲得していますね。


というわけで、明日はもう少し詳細を知るべく、

ハッカソンに参加してきます(`・ω・´)





2011年10月16日日曜日

第4回Jenkins勉強会に行って来ました

第4回Jenkins勉強会に行って来ました。



さて、内容の詳細ですが、
ブログまとめ職人の@shinyaa31さんが素晴らしいものを書いていますので、
そっち読んでください。

あと、トゥギャッターもまとめられているので、読んでみてください。

togetter - 10月15日 第4回Jenkins勉強会(東京都)
2011/10/15_第4回Jenkins勉強会( #jenkinsstudy )

当日のUST録画もありますので、興味のある方は御覧ください。

以上、報告終わり!


(´・ω・`)

2011年9月11日日曜日

Gradleでスローテスト問題を解決するAgain

前回、こんな記事書きました。
見事に効果がわからないという結果が出てきて、どうやればいいのか考えていましたが、
さすがGroovyクラスタに素晴らしい先輩がいらっしゃいました。

@bluepapa32 先輩です。
単純に、スリープするコード


    for (int i = 0; i < 100; i++ ) {
        Thread.sleep(10);
    }


を埋め込めばよかったわけですね。

というわけで、こんなテスト生成スクリプトでテストを大量に作ってみることにしました。


CreateTest.groovy

import static groovyx.gpars.GParsPool.*;
def packagePath = 'C:/Users/mike/IDEA_Project/GradleSample/src/test/java/orz/mikeneck/gradle/sample/boxunbox/test'

def head = $/
package orz.mikeneck.gradle.sample.boxunbox.test;
import org.junit.Before;
import org.junit.Test;
import java.util.Arrays;
import java.util.List;
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
/$

def body = $/
    public static final int SIZE = 100;
    private List<Integer> intList;
    private List<Long> longList;
    @Test
    public void testInteger()   throws InterruptedException {
        int[] array = new int[SIZE];
        int position = 0;
        for(Integer item : intList) {
            array[position++] = item;
            Thread.sleep(10);
        }
        for (int i : array)
            assertThat(i, is(intList.get(i)));
    }
    @Test
    public void testLong()  throws InterruptedException {
        long[] array = new long[SIZE];
        int position = 0;
        for (Long item : longList) {
            array[position++] = item;
            Thread.sleep(10);
        }
        position = 0;
        for(long item : array)
            assertThat(item, is(longList.get(position++)));
    }
    @Before
    public void setUp() throws Exception {
        Integer[] integers = new Integer[SIZE];
        Long[] longs = new Long[SIZE];
        for(int i = 0; i < SIZE; i++)
            integers[i] = new Integer(i);
        intList = Arrays.asList(integers);
        for (int i = 0; i < SIZE; i++)
            longs[i] = new Long(i + Integer.MAX_VALUE);
        longList = Arrays.asList(longs);
    }
}
/$

def numbers = []
(1..300).each {
    numbers << it
}

withPool {
    numbers.collectParallel { number ->
        def className = "BoxUnboxTest${number}"
        def name = "${className}.java"
        def fileName = "${packagePath}/${name}"
        def define = "public class ${className} {"
        def content = new StringWriter()
        content << head
        content << define
        content << body
        println ' ---- '
        println "now processing : $fileName"
        println ' ---- '
        new File(fileName).write(content.toString(), 'UTF-8')
        assert new File(fileName).exists() == true
    }
}


10msecを100回Sleepするテストメソッドが二つで、ひとつのテストの実行にかかる時間は2sec。
これが300個あるので、必要な時間は600sec = 10min かかるテストです。

実際に一つテストを実施してみました。


2secかかっていますね。
これが300個用意されるので、10minかかることが想定されます。

では、次のGradleスクリプトで実行してみましょう。


build.gradle

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.8.2'
}



なお、マシンの環境は次のような感じです。
OS : Windows 7
CPU : Intel Xeon X3460 (8Core) (64bit)
RAM : 8.00GB




では、実行、というかその間に色々と他のことで負荷がかからないように、
IntelliJ IDEAが起動していて、このブログだけがChrome上で起動しているという状態にしておきます。
で、IntelliJのRunツールで実行するのではなく、ふつうにコマンドから起動します。

さて、オレはその間、『JOJOの奇妙な冒険』を読むこととします。

では、いざ実行…




c:\Users\mike\IdeaProjects\TestingGradle>gradle build
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build

BUILD SUCCESSFUL

Total time: 15 mins 42.983 secs


15分43秒、マジ遅え。
しかも、最初の数個目までのテストは結構サクサク進んでいたけど、200を越えたあたりからテストの実行速度が落ちてきた感じがする。
こういう時はJVMの再起動などが必要なのかもしれん。

というわけで、さっそく、並列処理を試してみようと思う。

build.gradle

apply plugin: 'java'

repositories {
    mavenCentral()
}

dependencies {
    testCompile 'junit:junit:4.8.2'
}

test {
    maxParallelForks = 6
    forkEvery = 30
}



前回にも書きましたが、
  • maxParallelForksは並列するスレッド数。
  • forkEveryは指定した回数テストを実行するとJVMを再起動して、OutOfMemoryExceptionを回避する仕組みです。

では、実行開始です。


c:\Users\mike\IdeaProjects\TestingGradle>gradle build
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build

BUILD SUCCESSFUL

Total time: 2 mins 42.544 secs




えっ、2分Σ(゚д゚lll



めちゃくちゃ早くなっていません?
元々15分43秒かかっていたのがたったの2分43秒。

単純に計算すると

15min43sec / 6(core) = 2min37sec


となるから、妥当な値ですね。

では、テストのサマリーを比較してみましょう。



並列化前



並列化後



これを見るとCPU時間は変わっていません。
つまり、CPU時間をすべて複数コアで実行したために早くすることが出来たという事になります。

というわけで、結論

GradlemaxParallelForksを使うともれなくスローテスト問題が解決できる。



2011年5月22日日曜日

じ、実はJenkins勉強会にも参加してきたんですっ

実は金曜日にも勉強会に参加してきました。
『第三回Jenkins勉強会』です。

土曜日の朝にこの記事を書き始めたのですが、
DevLoveに参加するために家を出る時に、
保存するのを見事に忘れて、
今、書きなおしています。

で、結構目の前で起こることにはすぐ反応できるのですが、
過去のことを思い出すのはなかなか厳しいので、印象だけ記録しておきます。



Jenkins現状報告 by 川口さん
川口さんからのJenkins開発の現状報告です。

○racle社との離婚騒動の後における、
ダウンロード数やコミット数による比較を行っていました。

全般的にはJenkinsの方が活動が活発であるという事だそうです。

この発表を聞いていた時から感じていたのですが、
川口さんは「○racleとの離婚」という比喩を用いていたりと、
結構お話をするのが上手な方だなと思いました。

RubyによるJenkinsプラグイン開発 by 川口さん
世の中すべてがJavaプログラマーという訳ではなく、
Rubyを使っている人、Pythonを使っている人など、
他の言語を使う方もいます。

それらLL言語を使用している人を潜在的ユーザーと定義し、
Jenkinsを広めようということで、
特に今回はRubyに特化したお話でした。

Jenkins超初心者な私はJenkinsはJavaオンリーでは?などと
思っていましたが、
そういえばテスト部部長が、
コマンドラインでできるものはなんでもJenkinsで走らせられる
と言っていたのを思い出して、
RubyとかPythonでもできるだろうな~なんてレベルで聞いいていました。

余談ですが、川口さんはIntelliJ IDEAユーザーで、

@masanobuimai IntelliJ使えば川口さんみたいになれるよッ!!ってオレが言っても説得力ないけど。|qω・`)チラッ RT @ikeike443: 川口さんIntellijユーザー #jenkinsstudy

というツイートがあり、私のIntelliJ IDEA熱がアップしました。

Jenkinsと一緒にTracプラグイン開発 -UT/IT自動化のコツ- by @wadatka
普段はPythonのプログラマーの@wadatkaさんによるPythonでのJenkins使用例の発表です。

ND社に所属ということで、開発プロセスはWFでお話をされていましたが、
最終的に品質向上などの目的でJenkinsを利用しているとのことでした。

今後ND社さんからは
Trac + svn + jenkins
のパッケージを配布しますという宣伝があって、
みんな爆笑しました。

また、10末にJenkins本を出版するとのことで、
ND社さんって、同じN系列の会社だけど、
比較的自由になんでもやれるのでいいな~と思いました。

ただ、これはとなりの芝生は青く見える的な何かだと思いますけどね…

「これで君のインテグレーションは――始まりも、終わりもなくなった」~RailsプロジェクトでふつうにJenkins ~ by 永和さん
永和さんの始めたサービス、価値創造サービスにおけるJenkins活用例です。

永和さんといえば、RoRでアジャイルですが、
スローテスト問題でお困りとのことです。

設定か何かの関係からか、
Jenkinsで処理を分散することができないために、
テストに時間がかかってしまうとのことです。

それでも、1日に2~20回はテストをしているというので、
弊社のような2週間かけて1回テストするよりも強固なテストを行っているな~
などと思いました。

なお、解決方法として、
リポジトリへのpush駆動テストなどが提案されていました。

PHP開発でのJenkins by @yamashiroさん
Python、Rubyときて次は潜在的ユーザーがかなり多いと思われるPHPでのJenkins活用例の紹介でした。

発表前の不手際もあって、
ネタがバレてしまうなどというハプニングもありましたが、
いわゆる女子力ネタを書いている人がどんな人なのかわかって、
中の世界を垣間見た感じがしましたw

内容は準備不足だった感が否めませんが、
元々の課題を聞くとなるほどと思いました。

というのもプログラムコードが2万行もあるPHPファイルを
どうすれば減らせて、テストが出来て、CIできるかという課題があったようです。

まだ、Jenkins管理下にやっとおいたという感じらしいですが、
課題を解決できてリファクタリングも可能になれば、
より効果を確認できてうしし~みたいになるかなと思いました。

全体的な印象ですが、
発表者たちもまだまだ勉強中という感じで、
時折川口さんからアドバイスを頂いたり、
これはこうしたほうがいいといった活発なアイデアが出てきたりして、
レベルの高い勉強会であると思いました。

おそらく、毎回川口さんは参加されているようですので、
私もこの勉強会で何か発表できるといいなと思いました。

あと、実はこの日からGroovyに取り組み始めて、
kimukou_26さんから紹介されたGroovistきょんさんや、
Twitterでフォローさせていただいているいろふさんとお会いすることが出来ました。

Twitterは有名人などを気軽にフォローできますが、
やっぱり実際にお会いするとより親近感を持つことができますね。

この記事を読んでいる皆さんは普段から勉強会に参加されている方が
多いと思いますが、
勉強会というのは人間関係を広められるのでとてもいいですね。