読者です 読者をやめる 読者になる 読者になる

HIDARI日記(右)

そのときどき興味ある技術を中心にだらだら書いてます。内容は個人の見解であり、所属する企業を代表するものではありません。

Jenkins勉強会で学んだビアバッシュ

Etc

後から来る人達へ。

第7回大阪Jenkins勉強会の懇親会の代わりに行ったビアバッシュについて、次回開催するときのためにメモがてら書いておこうと思います。

人数と用意したもの

今回のビアバッシュには最終的に36人の方に参加頂きました。

ビール:

  • 2ケース(48本)
  • 一人2本弱の計算。
  • 注文時の申し込み人数の2倍弱で注文。
  • カクヤスで前日に注文。 www.kakuyasu.co.jp
  • オプションで冷えたものを配達してもらえる。
  • ビアバッシュ開始予定時刻直前に届いたけど、本編が早めに終わってたので、結果的に遅すぎた。
  • 2時間前目標で届けてもらうのが良さそう。

ピザ:

  • 12枚
  • 1枚で3人分の計算。
  • ドミノ・ピザの週末限定半額クーポンを(@kiy0takaさん](https://twitter.com/kiy0taka)が)当日手に入れて注文。
  • こちらもスケジュール通りに注文したけど結果的には遅すぎた。
  • 早めに注文しよう。

ソフトドリンク:

  • ペットボトル数本

雑感

  • ピザは気持ち少なかったけど必要量には足りていた。
  • ビールは微妙に少なくて、途中で買い足し。
  • 余るリスクを考えると少なくてよかったのかも。
  • 今回のをベースに参加者を考慮しがら色々手配するのがいいのではないかな。

第7回大阪Jenkins勉強会を開催してきました #jenkinsstudy

Dev CI Jenkins

だいぶ時間が経ってしまいましたが、去る2016年6月18日に、約2年半振りとなる大阪Jenkins勉強会の第7回を開催してきました。

connpass.com

connpass.com

今回はJenskins2のリリース記念ということでJenkins生みの親である川口さんと、現在開発中のJenkinsの新しいUI「Blue Ocean」の開発者であるJames Dumayさんをお迎えしました。

セッション

前半は実践系のセッション、後半はJenkins2を深く広い視点から解説するセッションという構成でした。

大畔 祐輝さん「初めての自動化、Jenkins」

  • Jenkins2の導入時に躓きそうなところを実体験をもとにまとめて話して下さいました。
  • 初めての発表とのことでしたが、丁寧な調査と落ち着いたしゃべりで素晴らしい発表でした。

@nobuokaさん「Jenkins Pipelines と Android アプリ開発 」

  • @nobuoka
  • Android開発でのJenkins活用事例を紹介して頂きました。
  • Pipelineのハマりどころ、使ってはじめて分かる超絶便利部分など、なかなか聞くことの出来ない贅沢な内容でした。

@kazuhito_mさん「実録!となりのJenkins2.0」

  • 安定の@kazuhito_m
  • 会場を巻き込むしゃべりは流石でした。ちょっとやかましかったけど。
  • デモ動画を流しながら解説するスタイルは非常に分かりやすかったです。ちょっとやかましかったけど。
  • やってることもトリッキーなのによく考えられてて聴き応えのあるセッションでした。ちょっとやかましかったけど。
  • ちょっとやかましかったけど。でもそれがいいw

川口耕介さん「Jenkins 2.0の紹介」

  • @kohsukekawa
  • Jenkinsの背景にある考え方、ビジョン、そしてJenkins2以降どうやって発展させて行くか、という内容を丁寧にお話して頂けました。
  • Jenkins2のLTSも近くリリースされるそうなので、2.0への以降も進むと思います。
  • 今後の発展がますます楽しみで、僕も少しでも貢献出来ればいいなって思います。

James Dumayさん「Blue Ocean 〜A new user experience for Jenkins〜」

  • @i386
  • 現在開発が進んでいるJenkinsの新しいUI「Blue Ocean」についてどこよりも早い解説セッションでした。
  • 開発車のJamesさんが英語で解説し、川口さんが逐次翻訳するスタイルでの発表でした。Jamesさんが日本語で挨拶したのを川口さんが英訳する場面もあり笑いを誘っていました。
  • まだ開発中のBlue Oceanですが、実際に触ってみることも出来るので、気になる方は Blue Ocean を見てみてください。
  • ちなみに、当日接続端子の都合で僕のPCを使って貰ったため、手元にはJamesさんのスライドがあったりします(役得)。
  • さっそく試した方も。

@Posauneさん「Travis, Circle, そしてJenkins 2.0」

  • こちらも安定の@Posaune
  • CIサーバとしてJenkinsが世界に与えた影響や問題点、昨今流行りのCIサービスについて、さらにそれらと比較したJenkinsの立ち位置などについて、独自の世界観と深い考察をお話くださいました。
  • Jenkinsの属人化問題は僕も頭を悩ませる問題で、Pipeline Scriptによるコード化が有効な手段になりうるかもと期待しています。

LT

  • 僕「Jenkins2.0で雑にLTタイマー作ります」
  • Vagrantを使った自動化デモ。
  • ArduinoでXFDデモ。
  • Jenkinsで彼女作ったら温もりが足りなかったり。
  • @kiy0takaさんのBlueOceanハックLTにテンション上がりまくりのJamesさん。
  • いろふさんはとんでもない速度でコミットフックでビルドするところまでジョブ作ってた。
  • 制限時間なんてなかった。

とにかくハイレベルで自由なLTでした(僕除く←)。

そのほか個人の感想など

  • 久しぶりに大阪でJenkins勉強会を開催することができました。
  • 初めてのJenkinsあり、Android開発での利用事例あり、企業内での縛りプレイ的な状況でのJenkins利用例ありでバラエティに富んだ内容を実現することができました。
  • 今回の勉強会で得られたこと、学んだことを現場でも実践して頂ければ、それ以上嬉しいことはありません。
  • あわよくば、次回の勉強会でその実践事例を発表してもらいたいです。
  • いつの間にか主催側になって、あれよあれよというまに川口さんとJamesさんに来てもらえる事になって、最終的には大盛況で終えることができました。遅くなりましたが本当にありがとうございました!

ブログ記事

勉強会の感想も書いてくださっています。

コマンドプロンプトの errorlevel を確認してエラーなら処理を終了する方法

Windows BAT

基本中の基本なんですが、最近はエラーが起こったら処理を終了することが重要になってくるとき、例えば「コマンドプロンプトしか使えない状況でCI回したい」みたいな縛りプレイしてるときに使ってます。具体的にはJenkinsのジョブを失敗させるためですが。

手順

まず、バッチファイルに以下の様なサブルーチンを用意しておきます。

:SuccessOrDie
if not %errorlevel% == 0 (
    echo [ERROR] :P
    exit 1
)
exit /b 0

これをerrorlevelに戻り値を返すコマンドのあとにcallで呼び出します。

xcopy src\hoge.dll dest\ /Y /F
call :SuccessOrDie

もしエラーが発生していたら(errorlevel0でなかったら)exit 1が実行されコマンドプロンプトが戻り値1、つまりエラーで終了します。Jenkinsだとこれだけでジョブを失敗させることができます。

一方、エラーがなかった場合(errorlevel0の場合)はexit /b 0が実行されます。/bオプションによってサブルーチンを終了し呼び出し元に戻ることができます。

バッチファイルではよくgoto使ってエラー処理をしているのを見かけますが、呼び出し元に戻りたいのに加えて、思わぬバグが生まれることがあるので使うのを避けて、callexitの組み合わせを使っています。

errorlevelを含む条件式での注意点

if not errorlevel 0 exit 1

って書いてしまうと「0以上ではないとき終了する」になるので、errorlevelが負のときにしかexitが実行されません。

if not %errorlevel% == 0 exit 1

というように展開した上で文字列での比較を行うことで「0ではないとき終了」するようになります。

手動で実行したい!

基本的にはCIサーバでコンソール出力を記録しながら使うことを前提としたバッチファイルですが、CIとかよくわからんから手動でもログを残して実行できるようにしておいてくれないと困るって言う人が稀によくいます。

そういうときは以下のような処理を書いた手動実行用のラッパーを用意しています。

@echo build.batを実行します。
@echo ログは build.bat.logに出力されます。
@pause

@echo 実行中...
@call build.bat > build.bat.log 2>&1

このバッチファイルをダブルクリックするだけでログ出力まで行います。

サンプル全文

ここまでで紹介したあれこれをまとめたサンプルの全文です。

@echo off
set SELF_PATH=%~dp0
cd /d %SELF_PATH%

xcopy src\hode.dll dest\ /Y /F
call :SuccessOrDie

goto end

:SuccessOrDie
if not %errorlevel% == 0 (
    echo [ERROR] :P
    cd /d %SELF_PATH%
    exit 1
)
exit /b 0

:end
echo [SUCCESS] :)
echo on
exit 0

第6回 PowerShell勉強会 に参加してきました #jpposh

Powershell Testing

第 6 回 PowerShell 勉強会 - Japan PowerShell User Group (JPPOSH) | Doorkeeper に参加して、LTでPesterについて少しだけ話をさせてもらって来ました。

LT資料はこちら。

せっかくなので、ちょっとLTの補足なんかをしておきたいと思います。

TestDrive

TestDriveにアクセスするときTestDrive:\$TestDriveが使えますが、微妙に異なる点があります。

前者は通常のPSDriveですが、後者にはTestDriveが指す場所のフルパスが入っています。

そんなに困ることは無い気がしますが、一応覚えておいた方がいいかと思います。

コードカバレッジ

二点ほど。

まず一点目。Pester自体はPowerShell2.0以上で動作するんですが、コードカバレッジ機能だけはPowerShell3.0が必要です。そんな環境でPester使うことあるんかって話は置いといてください(ニッコリ。

もう一点は計測結果に出てくる 「commands」 についてです。資料の中では

Code coverage report:
Covered 66.67 % of 3 analyzed commands in 1 file.

って出てるやつです。

Pesterのコードカバレッジの計測はPSBreakpointsで実行されたcommand(文)を記録することで実現されています。実行されたPSBreakpointsがcommandsとして報告されます。 そのためPowerShellの仕様としてPSBreakpointsが置けないelsetryfinallyなんかはcommandsにカウントされません。ifとかthrowとかreturnとかはカウントされます。

コードカバレッジの結果を見て数が合わないなって思ったときは、一度確認してみてください。

ほかの方々の資料

は、こちらから

Jenskinsでのsvnリポジトリのポーリングで発生するエラー

Jenkinsでsvnをポーリングするようにしていると、以下の様なエラーが発生することがあります(「Subversionのポーリングログ」から確認できます)。

ERROR: Failed to check repository revision for proto://host:port/path/to/repo
org.tmatesoft.svn.core.SVNCancelException: svn: E200015: E200015: ISVNAuthentication provider did not provide credentials; HTTP authorization cancelled.

数日前からこのエラーが起きてたのをようやく解決できたのでメモしておきます。

このエラーは svn:externals を使って別のリポジトリを参照する構成になっている場合で、メインのリポジトリと、参照先のリポジトリの認証情報が異なるときに起こるとのこと。

実際にエラーが発生した環境は、メインも参照先も同じサーバのリポジトリで同じ認証情報だったので、 あまり気にしたことなかったんですが、Jenkinsから外部リポジトリの更新を行う時には通常とは異なる動きでsvnクライアントが 起動するらしく、何らかのタイミングでメインのリポジトリと参照先のリポジトリの認証情報に齟齬が発生していたようです。

正しく動作させるにはジョブの設定で [Additional Credentials] を追加し、外部リポジトリのrealmというのと、それに紐付いたCredentialsを指定します。

realmの確認は以下のコマンドで出来ます。ダイアログが出てくるけどキャンセルでいいです。

svn --no-auth-cache --config-dir invalid info proto://host:port/path/to/repo

この問題は、今回みたいに同じsvnサーバ上のリポジトリでも起こりえるので svn:externals を使っているリポジトリをJenkins で触るときは必ず [Additional Credentials] を指定しておくのが正解っぽい。

tscとlite-serverで作るシンプルなTypeScript開発環境

TypeScript JavaScript Dev

最近MacでカジュアルにTypeScriptを書いてブラウザで確認したいなってときに使っている環境です。 ぶっちゃけAngular2の 5 Min Quickstart で使われている方法ですが。 (なお、前提としてnode.jsをインストールしてnpmを使えるようにしておく必要があります。)

使用するツールはTypeScript(tsc)の他には lite-serverという開発用のhttpサーバだけです。 上記二つを使って、[TypeScript書く] > [自動ビルド] > [ブラウザの自動リロード]を実現していきます。

まず、実験用のディレクトリを作ってTypeScriptをインストールしておきましょう。

mkdir my-proj
cd my-proj
npm install typescript

これでTypeScriptをコンパイルするコマンドtscが使えるようになります。 適当に以下のような sample.ts を作って node_modules/.bin/tsc sample.ts を実行すると sample.js が出来ますね。

class Person {
    public Name:string;
    constructor(name:string) {
        this.Name = name;
    }
}

var me = new Person("Hidari");
document.body.innerHTML = me.Name;

さて、tscには -w オプションがあり、tsファイルの変更を検知してコンパイルを自動で行うことが出来ます。 これを行うために、まず tsconfig.json というファイルを sample.ts と同じ場所に作成し、以下の内容を記述します。

{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "rootDir": ".",
        "outDir": ".",
        "noImplicitAny": false
    },
    "exclude": [
        "node_modules"
    ]
}

ファイルが作成できたら node_modules/.bin/tsc -w を実行してみましょう。 tsファイルの変更が監視されます。試しに sample.ts を変更してみてもいいと思います。

次にlite-server。これはnode.js上で動作する開発用のhttpサーバで、ファイルの変更を検知してブラウザで表示中のページを自動でリロードしてくれます。 npm install lite-server でインストール。

続いて適当に以下の様な index.html を作り、新しいターミナルでnode_modules/.bin/lite-server を実行します。 するとブラウザが開いてindex.htmlが表示され、同ファイルの変更監視が開始されます。

<!DOCTYPE html>
<html>
    <head>
        <title>sample</title>
    </head>
    <body>
        <script src="sample.js"></script>
    </body>
</html>

以上で終わりです。

これでTypeScriptを編集すると自動でコンパイルされ、ブラウザがリロードされ、結果が確認出来るようになりました。 ガッツリ開発するにはちょっと力不足ですが、雑に書くぶんには十分だと思います。

ではでは。

CI勉強会に参加してきました #vshtc

CI Powershell Book

びっくりするほどほったらかしになっててびっくりしました。

今日はVSハッカソン倶楽部主催のCI勉強会 - #vshtc - VSハッカソン倶楽部 | Doorkeeperに参加してきました。

会の構成としてはセッション4つと、今後計画されている「XFDハッカソン」のためのアイデアソンという形で、僕はセッションの一つで主催の森理 麟 (@moririring)さんと共に発表させてもらいました。

セッション部

一つ目のセッションは、Yu Nobuoka (@nobuoka)さんによる「CI のすすめ 〜はてなでの web サービス・モバイルアプリ開発と CI〜」。 はてなでのCIについてどんなふうに行っているのか、なぜCIが必要なのかといった話で、めっちゃ勉強になった!!

2つ目はLibreぽざうね (@Posaune)さんによる「ポストJenkins時代のCI戦略」。若干煽り気味のタイトルですが、内容は安定のPosauneさんクオリティ。毎回情報のカバレッジに驚かされ続けています。詳しくは公開されているスライドポストJenkins時代のCI戦略を見てみてください。

3つ目は我らが森理 麟 (@moririring)さんと、不肖わたくしによる「WindowsでbatとPowerShellでCI!」。前半が森理麟さんによるbatファイルとタスクスケジューラによるローカル環境CIについてデモをメインに紹介。後半で僕がPowershellを使ったWindows環境でのビルドについてデモを行いました。ほどんどスライドを使わないほぼ無刀セッションでしたが、なかなか興味を持ってもらえたようでありがたい限りです。

4つ目は三浦カズヒト(「らむだ」とか解らない人) (@kazuhito_m)さんによる「出来る!XFD!」。このセッションが次の「XFDハッカソン」につながる大きな布石となっています。こちらもスライドができるXFD - 2015/07/11 CI勉強会 - #vshtcで公開されているのでそちらを参照ください。パトランプパトランプ

イデアソン部

イデアソンとはハッカソンで作るもののアイデアをみんなで出し合っていく話し合いみたいなもの。数人でグループを作ってブレインストーミング的なことを行ってアイデアを出し合い、10分程度話し合ったらまた別のグループを作ってアイデア出し、という形式で計3回行われました。

XFDとしてどんな情報をFeedbackするのか、どんな方法でFeedbackするのかをわいわい出し合い、荒唐無稽なものからわりと現実味のあるものまでいろんなアイデアが出て楽しかったです。僕が参加したグループで出たのアイデアの一部としては

  • ビルドがコケるたびに連絡先を一個ずつ消していく
  • ビルドを壊した人をイニシャルで指摘
  • ビルドを壊した人のチャットなどのアイコンを「僕がやりました」を表すものに変える
  • ビルド成功などのたびにコーヒーの温度が5℃ずつあがり、一定の成果を出すとコーヒーが飲める
  • ビルド成功などのたびにキャラクターが褒めてくれる
  • プロダクトのモジュール図などで壊れている部分を赤くして他のチームに知らせてしまう
  • ビルド失敗などのたびにHPゲージが減って全損するとモニタの電源が落ち、復活させるにはチーム全員でKinectで変なポーズを認識させる

などでした。

おわりに

僕の発表はほぼ全部デモということもあり、いろいろ不安要素も多く中には実際に現実に上手くいかない部分もありましたが、予定していた内容は実行出来たので自己評価はなかなか(甘めですが)。反省としてはもう少しスムーズにデモをやると、時間を有効に使えるし、魅力ももっと伝えられるだろうなってところです。

イデアソンで出たアイデアは終盤にはかなり現実的なものに落とし込まれていて、参加者のレベルの高さを感じました。同時にハッカソン、ついていけるかなっていう不安も出てきました…。でもそれよりも早く動いてるところを観たいという気持ちが強く、とても楽しみです。

参加者の皆様、お疲れ様でした。

おまけ

懇親会でなぜか最近面白かった漫画を紹介する流れになったので、そこで出した本をご紹介。

ではでは。