CloudBeesのDEV@Clouldを使ってAndroidをビルドしてみた

Travis CI/Werckerと試用して、他にモバイルに特化したものは無いかなと思い、こちらを使ってみることに。

はじめから結論なのですが、これはJenkinsをホストして、いくつか拡張された形で使えるものです。つまり、Jenkinsを実際に運用している人であれば、学習コストもかかりませんし、使っているPluginも自由に組み合わせることができます。さらには、有用プランだと、いくつか外部サービスとの連携もサービスとして使うことができるのは良かったです。

一方、Travis CIやWercketが環境構築をtravis.ymlやwercker.ymlの管理で固定して実施できていたのに対して、こちらはこういうコードで環境をコントロールすることが難しそう。また、Android/iOSも結局はSlaveにビルドを任せるので、そのSlaveの環境をソフトウェアで管理できないぶん、個人的にはTravisやWerckerのほうが良かった。

では、内容。

Getting start

CloudBeesのドキュメントはかなり整っていて、例えばGetting Startには以下のように典型的なパイプラインなどが表示されていました。

ふむふむ。
全体のDeployment Pipelineへの理解として、良い感じですね。

使ってみる

サービス全体のUIはこんな感じ。

設定する

基本的には、こちらのページに沿って作業を進めると、例えばGitHubからCheckoutしてきたコードをビルド自体はできるようになります。

その設定の詳細はすべてJenkinsと同様です。Antを使っている人はAntの設定を、Gradle使っている人はGradleの設定をすればビルド実施まで進めることができます。
JenkinsにおけるAndroidビルドの設定などは多くの情報がWebに出回っていると思うので、ここでは割愛。

ビルドする時の設定でここだけは忘れずに

Master-Slave構成でJenkinsを運用したことがある方はわかると思いますが、このサービスではビルドをSlaveに渡して実施します。そして、Slaveがラベル管理されているので、androidというラベルでSlaveを指定する必要があります。なので、ビルド設定の所で”Configuring Android Builds”と記載している箇所にLabel指定で”android”と入力する必要がある。

最後に

今からカジュアルにAndroidをビルドしたいとか、そういう要望があるならば、ここよりもTravisやWerckerを使うほうが良さげです。ただし、Jenkinsを既に使っていて、その環境を外に出したい、という要望であればここはありかも。
良い点としては、JeninsやそのSlaveのメンテナンスから解放されそうなこと。一方、先にも書きましたがビルド環境のバージョン指定がコードで指定できる訳ではないので、どこまでコントロールできるのか、などは定かではありません。

個人的には、今から始める人はWerckerが良さげ。
次はiOSに焦点あてて調べてみよう。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中