ThoughtWorks Go試した
知る人ぞ知るCIサーバ，ThoughtWorks Goを試してみたよ。その昔，Cruiseと呼ばれてたやつで，どうゆういきさつがあったか知らないけど，いつの間にか Go って，なんとも印象に残らない名前になったヤツ。たまたま「そんなのあったなー」とThoughtWorks覗いてみたら，フリーのCommunity Editionなんてのがあったので，ちょっと使ってみた。
→ http://www.thoughtworks-studios.com/go-agile-release-management
インストーラがあるので簡単に導入できるけど「あー，Jenkinsさんはすげー簡単なんだなー」と思えるほどには面倒ｗ。Go Serverだけでは何もできないので，Go Agentもインストールしないといけません（Jenkinsで言うところのExecutor）。このAgent，勝手にサーバ見つけてくれないので，いちいちサーバのアドレスを教えてあげないといけない。なので，インストールはGo Server → Go Agentの順でよろしく。
ちなみに，Community版ではGo Serverと同居するAgentのみタダで，リモートエージェントは有償とのこと。
GoがサポートしているVCSはsvn/git/hg/perfoce/team foundation serverなんだけど，それぞれのコマンドを必要とするらしく，Go Server/Go Agentの実行環境のPATHにそれらを登録しておかないといけない。svnならコマンド要らずで使えるJenkinsってスゴいね。:-)
PATHに通しておかないといけないのはVCSのコマンド群だけじゃなく，antやmavenといったビルドツールも(Go用語だとTaskと言う。
ちなみにサポートしているコマンドは，ant, nant, rake, custom commandの４つ（３つが正解？
Goのジョブはパイプライン（pipeline）っていう上位概念があって，その下にステージ（stage），ジョブ（job），タスク（task）と続く。図にするとこんな感じ。
+ pipeline | +-> stage : : +-> job : : : +-> task : : : +-> task : : +-> job : : : : +-> stage : + pipeline
パイプラインにはマテリアル（material）と呼ばれるリソースの取得先を複数設定できる。つまり，ここにどのVCSからソースを取ってくるかを登録するわけ。どうもJenkinsでいうトリガも兼ねているようで，他のパイプライン（のステージ）が終わったら起動するなんてのも，マテリアルに設定する。
トリガは手動かcronっぽい自動起動の２種類。手動しか試さなかったので，cronはよくわかんない。
ステージってのは，なんだろ？Jenkinsのワークスペースに相当するのかな？マテリアルからリソースを取得して定義したジョブを実行してく。
ステージは上から順に実行されているのだけど，自動で連携するか，手動で連携するかが選べる。それと，ステージにチェックアウトしたマテリアルは，（そのパイプラインの）すべてのステージで共有される。一応，ステージ事にマテリアルを更新しなおすか否かの設定ができるみたい。
んでジョブ。これはJenkinsのプロジェクト（ジョブ）に相当するのかな？タスクと呼ばれる手順に従ってビルドを実行していく。ジョブごとにアーティファクト（artifacts）が設定できて，それが成果物として保管される。アーティファクトは，他の（パイプラインの）ジョブが取得してくこともできるみたい。えーと，JenkinsのCopy Artifactプラグイン相当のことができる。
タスクはタスク。antやnantなどのコマンドを実行する。Go固有のタスクとして「Fetch Artifact」ってのがある（これがさっき言った，Copy Artifact相当の機能）。
そんなこんなでパイプラインを作ってみたのがこれ。パイプラインの枠内にある緑のバーがステージ。
元にしたプロジェクトはこちら。
→ https://github.com/masanobuimai/ant-sample-project
Jenkinsだったら，ひとつのプロジェクトで済ましちゃうようなやつをわざわざ３つのパイプラインに分割して試してみました。
sample-pipeline
gitからマテリアルを取得して，ビルド（defaultStage），テスト（testStage），リリース（releaseStage）と進む。それぞれステージにジョブは１つだし，ジョブの中のタスクも１つ（なんと大げさなｗ
ビルドした結果は，他のパイプラインで利用したかったのでアーティファクトに登録しとく。これがなにかと分かりづらい。
JUnit形式の結果ファイルを扱えるそうなので，テスト結果もアーティファクトに登録。せっかくだから，リリースでできたwarファイルも登録しといた。
inspection-pipeline
checkstyleとfindbugsを実行するだけの簡単なパイプライン。継続的デリバリーを立ち読みしてかぶれた「バイナリは１度だけ作る」を実践してみようと思い，sample-pipelineのアーティファクトをパクるようにした。なので，マテリアルはこんな感じ。
gitもマテリアルに登録してあるのは，アーティファクト以外のリソースを取得したいがため。
「どのパイプラインのどのステージが終わったら」という意味で登録するので，"sample-pipeline / defaultStage"となっている。でも，マテリアルに登録するパイプラインは，このパイプラインが実行するトリガとして機能している気がする。
なぜかというと，ジョブで「Fetch Artifact」タスクを登録するから。
わかるかしら？Fetch Artifactで「どのパイプラインの，どのステージの，どのジョブの」アーティファクトを取得するって設定してるわけ。個人的には，そんな面倒なことしないで，ステージまるごとコピーして欲しかったなと思う。
inspection-pipeline
パイプラインの連携が１つだけだとつまんないなと思って，無理に設定したやつ。単にJavadocを生成するだけなので，Fetch Artifactは無し。それ以外は，inspection-pipelineと同じ。
単に，こんなグラフを見たくて設定しただけ。ちなみに，inspection-pipelineとjavadoc-pipelineは並列で実行する。
当然ながら，inspection-pipelineやjavadoc-pipelineに連携する他のパイプラインを作る事もできるのだけど，このグラフ（pipeline dependencies）は，「今のパイプライン」の前後（upstream/downstream）しか見えないので，まあいいかと。
試しに，inspection-pipelineとjavadoc-pipelineの両方をマテリアルに登録したパイプラインを作ってみたら，両方のパイプラインの完了を待って実行を開始してましたね。こりゃ面白い，と。
所感
パイプライン中心の管理体系と，それを活かしたUIが面白いGoなんだけど，パイプラインを回すことに特化しすぎちゃって，それ以外がとっても使いづらい（分かりづらい）。たとえば，アーティファクトなんだけど，これを取りに行くには，「パイプラインの／ビルド番号の／ステージの／ジョブの」アーティファクトを参照しないとたどり着けない。この辺，Jenkinsになれていると，かなりあんまりな感じ。:-(
だからね何て言うか，CIを回すというより，デプロイまで含めたビルドパイプラインを回すのに特化してるって感じなのかね。パイプラインが終わったら，どこぞのサーバにデプロイされるみたいな。Enterprise版だとデプロイまでできるようだし。
Jenkinsと比べて優れている点は，パイプラインの作りやすさ（？）と，そのUIの見やすさ・使いやすさかねー。JenkinsのBuid Pipelineは「よくぞ，がんばった」感があるんで。JenkinsのBuild Pipelineビュー相当の画面はこれかね。
それに「ビルドパイプラインかっこええー」と思うけど，それを必要とするほど大げさなビルドシステム作る需要ないかなー。それに，なにをどう切り出してパイプラインを組むべきか，いろいろノウハウも要りそうなんで，語感にあこがれて手を出しても怪我しそうなのよね。
とか言ってみたものの，Goみたいなとんがったプロダクトは好きよ。機会があったら何かに使ってみたいなと。:-)
