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

Snap CIはJenkinsの後継者になり得るか?

みなさま、年の瀬をいかがお過ごしでしょうか。

さて、今日はSnap CIというCIサービスを紹介してみます。

f:id:a-yamada:20141224233438p:plain

Snap CI | Hosted Continuous Integration and Continuous Delivery | ThoughtWorks

Snap CIとは?

Snap CIはThoughtWorksが提供するCIサービスで、公式では「Simple deployment pipelines to monitor your every change. From running tests to deployments.」と謳われています。

簡単にいえばGitHubリポジトリに紐付いたビルドパイプライン型のCIサービスってことですね。JenkinsとCircleCIの中間に位置すると思えば、イメージしやすいかもしれません。

プラン

プランは4種類用意されています。どのプランも公開リポジトリビルド回数チームメンバー数に制限はありません。違いは以下のような感じ。

Cost worker Private Repos
Free tier $0 / month 1 0 repos
Individual $30 / month 1 5 repos
Small team $80 / month 2 unlimited
Small business $180 / month 4 unlimited

workerとは同時並行ビルド数のことです。あとはプライベートリポジトリ数に違いがあります。まあどのCIサービスも課金ポイントはこの点ですね。個人利用でプライベートリポジトリをCIしたいケースだと、多少割高感があります(CircleCIはprivate無料になりましたし)。

Snap CIの特徴

現状のSnap Ciの特徴について確認しておきましょう。

ビルド環境

CentOS 6.6, 64-bit のようです。

言語、プラットフォーム

Ruby/Java/JavaScript/Rails/Node.js/Python/C/C++/PHP/Android等をサポートしています。未サポートの言語やプラットフォームを利用するには、ビルド時に独自で設定する必要があります。GoLangあたりは早いところサポートしてほしいですよね。

iOSはサポートしていませんiOSサポートしてるのはTravis CIとCircleCIくらい)。

データストア

Sqlite3/PostgreSQL/MySQL/Redis/CouchDB/MongoDBをサポートしています。Dockerは残念ながら未サポートです(CircleCIやwerckerでは対応されている)。

WebDrivers

Capybara/Chromium/Firefox/Selenium/PhantomJS/xvfbをサポートしています。この辺りが使えるのでフロントエンドのEnd-to-Endなテストには困らないでしょう。

ディプロイ

AWS/Herokuをサポートしています。リファレンス見ると、地味にTerraformに対応してるようです。

他サービス連携

HipChat/Slack/Campfireをサポートしています。まあこの辺は最近は普通ですね・・・

はじめてみる

Snap CIはGitHubでのOAuth認証で利用することが出来ます。サインインすると「Setup your first build!」という画面になります。右上の「+Repository」からリポジトリ選択画面に行きます。

f:id:a-yamada:20141225002506p:plain

任意のリポジトリを選択します。試しに個人アカウントにforkしてみたaeromockを選択してみます。

f:id:a-yamada:20141225002845p:plain

Snap CIの中でClone中・・・

f:id:a-yamada:20141225004017p:plain

ビルドとパイプラインの設定

何やらBuild Pipelineの画面が出てきました。Snap CIでは、ジョブをステージによって適度に分割し、パイプラインで繋ぐことができます。

f:id:a-yamada:20141225025451p:plain

まず、ビルドに必要なランタイムを設定します。現状対応してるのは、Ruby/Java/Python/Node/PHPですが、それほど多くのバージョンには対応してないです。GoLangも標準ランタイムとしては未対応ですね。

黒いコマンドの部分で、該当ステージで実行したいコマンドをシーケンシャルに指定します。

その他、worker数や環境変数、credentials等を設定することができます。

パイプラインを繋いでみる

試しにビルドパイプラインを繋いでみましょう。ジョブを以下の3つに分けて繋いでみます。

  • DSLライブラリのビルド(Gradle)
  • フロントエンドのビルド(Grunt、bower)
  • サーバサイドのビルド(sbt)
DSLライブラリのビルド(Gradle)

Gradle(実行はGradle Wrapper)を使うので、ランタイムにJavaを設定します。コマンドラインでgradlewを実行します(signArchivesタスクは除外)。 ここではgradlewを使いましたが、Gradleは標準でインストールされてるようです。

f:id:a-yamada:20141225024418p:plain

フロントエンドのビルド(Grunt、bower)

次はフロントエンドです。ランタイムにNode.jsを設定します(対応しているバージョンがちょっと少ない)。 Node.jsが設定されれば、grunt-cliやbowerは既にインストールされてるようなので、npmとbowerモジュールのローカルインストール→GruntでビルドでOkです。

f:id:a-yamada:20141225024433p:plain

サーバサイドのビルド(sbt)

最後にサーバサイドをsbtでビルドします。ここではsbt-extrasのスクリプトを叩いて実行します(sbtは標準でサポートしているようですが)。

f:id:a-yamada:20141225024449p:plain

これでパイプラインの設定は完了なので、保存するとパイプラインの上位ジョブから実行されます。

ビルドの進捗

ビルドが開始されると、パイプライン表示の画面になります。JenkinsのBuild Pipeline Pluginみたいですね。

f:id:a-yamada:20141225024507p:plain

ビルドのログ

もちろん実行中のビルドのログも見ることが出来ます。横幅フルに使ってるので、CircleCIのログより見やすい印象を受けますね。

f:id:a-yamada:20141225024639p:plain

次のステージへ

ステージが正常終了すると、次のステージが実行されます。

f:id:a-yamada:20141225024652p:plain

ビルド完了

f:id:a-yamada:20141225024724p:plain

ビルドのトリガー

ステージ毎にビルドトリガーをAutomatic(自動実行)かManual(手動実行)に設定できます。

Automaticであれば、最初のステージはリポジトリの更新がトリガーに、それ以降のステージは前のステージがSUCCESSならば自動で実行されます。Manualにすれば、画面からポチッと実行できるようになりますが・・・、どうやら最初のステージだけはManualにはできないようなのです。

f:id:a-yamada:20141226004004p:plain

この仕様、正直どうなんだろう。Manualがあるってことはタスクランナー的利用ができるのかと思ってましたが・・・。2ステージ目以降はManual実行できて、ビルドを通るように修正したら、最初からやりなおさなくても良いっていうパイプライン型の利点はありますが、それだけが目的であるならば別にAutomaticとManualを選択させる必要は無いんじゃないかなと。リポジトリとジョブが紐づく仕様だとこうなっちゃうのか。。。

Pull RequestをCI

Snap CIでwatchしているリポジトリに対してPull Requestをすると、そのPull RequestのブランチでCIが行われます。GitHub上からその結果もわかるので、マージの判断の材料にもなります。

f:id:a-yamada:20141226004539p:plain

Branch Tracking

自動でCIするブランチはデフォルトではmasterだけですが、Branch Trackingを設定すれば他のブランチもトリガーの対象とすることができます。

f:id:a-yamada:20141226010547p:plain

feature/で登録すれば、featureブランチをトラッキングできるようになりました。

f:id:a-yamada:20141226011347p:plain

総評

パイプラインをサポートしていることで、ジョブがモノリシックにはなりにくく、途中から再開できるというメリットはあります。

ただ、ジョブのトリガーがリポジトリの更新なので、Jenkinsのような汎用的なタスクランナーをイメージしてしまうと機動力では劣ります。Snap CIをタスクランナー的に使いたいのであれば、HipChatやSlackでChatOptsな運用体制を用意する必要があるでしょう。

痒いところで、色々と惜しいというのが触ってみた感想です。

とはいえ、Snap CIは4月に始まったばかりのようなのでまだまだこれからのサービスなので、どんどん変化していくと思われます。個人的にはトリガー周りを改善してもらって、汎用的な使い方がしやすいツール、いわばJenkinsの後継の位置を狙ってほしいところです。うまくやれば、その可能性は秘めてると思ってます。

しかしCIツールはCircleCIが今飛ぶ鳥を落とす勢いですからね・・・。iOS対応したり、Docker1.4リリースからわずか1週間足らずで投入してきたり・・・

何にせよ開発支援系サービスは今年も活発でした。来年はこのSnap CIの成長をこっそりと見守ることにしましょう。