f:id:timers-tech:20170524211352p:plain

こんにちは。Androidエンジニアの斎藤です。先日業務でFammのAndroidのCI移行を担当しました。そこで移行するに至った背景や、選定基準、移行ハマったところについて書くことにしました。Bitriseの具体的な登録方法やビルドステップ設定方法については割愛させていただきますのでご了承ください。

なぜ移行するのか

CircleCIのビルドコンテナのメモリ上限の4Gに引っかかるようになってきました。たまに発生していた現象が頻繁に起こるようになってきました。その度にcircleci.ymlのパラメータを修正していましたが、いよいよ限界を感じ移行するに至りました。

新CIサービスの選定基準

選定基準は大きくあげると下記2点ありました。

使用メモリに上限を設けていないこと。
今までと同様のCIフローを再現できること。

メモリ上限についてはいうまでもありません。もう1つの現在のCIフローの再現ですが、特殊なフローでないのでおそらくどのCIサービスでも再現できるだろうと楽観していました。

そこで候補に上がったのがwerckerとbitriseです。

これらの他にもメモリ上限を設けていないCIサービスはあると思いますが、ドキュメンテーションの充実さや他社の導入事例の多さからこの２つを選びました。

BitriseとWerckerの比較

bitriseとwerckerのどちらを導入するかを検討材料として料金・機能・性能について比較しました。また性能については実際に既存CIフローの一部を導入して動かしてみました。

料金

	同時実行数(無料)	同時実行数(有料)	料金形態
bitrise	x1	x2〜x18	$50/month〜
wercker	x2	x3〜	$350/month

どのプランを選択するかによりますが、同時実行数が少ないならbitriseの方が安いです。

機能

	CI設定方法	PR自動ビルド	PR自動配布
bitrise	Web(YAML*1)	○	○
wercker	YAML	○	○

*1.このYAMLはCircleCIのような使い方はできません。後述で補足します。

性能

	ビルド時間制限(分)
bitrise	8分程度
wercker	6分程度

werckerの方が早いですね。

なぜbitriseにしたのか

弊社iOSの開発ではbitriseを導入済みで、社内で知見を共有しやすいというのメリットがありました。一方、werckerも弊社サーバーの開発で使用しているのですが、AndroidでWerckerを導入するにはbitriseに比べて少々手間がかかります。

AndroidSDK入りのDockerイメージをDockerHubで公開することはAndroidSDKのライセンス違反になるようで。 privateなら問題ないのでs3に鍵を置いてそれをビルド時にダウンロードして...というような手順が必要になります。というメンテナンスコストを考慮してbitriseを導入するに至りました。

プラン選択

まず無料プランでお試ししてましたが、すぐに有料プランに変更しました。というのも無料プランでは1回のBuildにつき10分までという制限があり、ビルド時間が10分を超えた場合そのビルドはabortします。他にも「チームメンバーは2人まで」「ビルド回数はひと月に200回まで」などの制限があるので注意が必要です。

f:id:timers-tech:20170524214235p:plain

abort時には^のようなチャット(?)がきます。これに気づかずしばらくビルドがabortされた原因をログを見ながら調査をしていました...。

変更した有料プランは下図の左から2番目のTEAMプランにしました。まずは並列実行数1xからはじめてみようという理由です。右から2番目ののプランも料金は同じように見えるのですが、このプランは並列実行数2xからなので実際の料金は$50x2とTEAMプランより高くつきます。

f:id:timers-tech:20170524214727p:plain

Bitriseでハマったところ

bitrise.ymlの扱いについて

これまでFammは新しいビルドステップを追加するときにcircleci.ymlを修正してそれ自体を版数管理の対象としていました。アプリのroot直下にこれを置けばcircleciがこのファイルをみてビルドを実行してくれたのです。

bitrise.ymlというファイルを見つけたときに「ああ、circleciと同じ感じだな」とroot直下に置きましたがpushしても記載したフローをしてくれず...。調べてみるとBitriseはGUIでworkflowを編集して、自動生成されたbitrise.ymlをダウンロードしておけばこれを再現できるというものでした。これについては私の調査が甘くチームに迷惑をかけてしまいました。

そこでGUIでビルドステップを変更した場合はbitrise.ymlをダウンロードしてアプリのrootに置き、Gitバージョン下で管理するというルールにしました。

triggerについて

triggerはcircle.ymlと違って正規表現は使えません。完全一致か「*」を用いた部分一致でのマッチングのみです。

そして一番早くマッチしたworkflowのみを実行する仕組みになっています。Fammの場合、「master」「develop」「その他のブランチ」の3つのworkflowを用意してます。この順で評価したいため「master」「develop」「*」の順でTriggerを設定しています。

最後に

またこのCI移行が完了したくらいのタイミングでOracleがwerckerを買収されました。この選択がよかったのか悪かったかはわかりませんが、CI環境の移行は意外と骨の折れる作業でしたが無事完了してホッとしています。

積極採用中!!

子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中！急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！採用HP : http://timers-inc.com/engineerings