UUUM攻殻機動隊(エンジニアブログ)

UUUMのエンジニアによる技術ブログです

wercker で Bitbucket のプライベートリポジトリをビルド!

新人エンジニアのハトネコエです。

UUUMでは毎週月曜日に社内勉強会をしていて、今週の担当は私なのですが、
昨日月曜日は台風のためお休みしましたので残念ながらおこなえず……

いえ、ごめんなさい!
実は土日かけて勉強会の準備してましたけどスライドはまだできてません!

土日は新幹線やホテルで、そして月曜は一日中、翌朝4時頃までがっつりやっていたのですが、
まだ発表できる段階まで至っていません。

これはテーマの決定をミスった気が……。

予定より軽めのテーマに変えることも考えつつ、
今日はその下準備の中で得たものを記事にしてみます。

個人開発はお金がない!

お金がないです。

でもソースは git で管理したい!

最近は GitHub の価格体系が変わり、
プライベートリポジトリをいくつ使用しても個人だと月800円程度、学生だと0円! と、とても安くなりました。
(以前はプライベートリポジトリの個数で月の料金が変わっていました)

とはいえ、Bitbucket のプライベートリポジトリは無料ですから、
個人開発やスタートアップ企業で使用しているところは多いことでしょう。

GitHub じゃないから Circle CI は使えないけど、カンタンなCIツールを使いたい!

そんなワガママを叶えてくれるのが、wercker です。

wercker のすごいところ

Bitbucket のプライベートリポジトリ対応

GitHub のリポジトリにも Bitbucket のリポジトリにも対応しています。
しかもプライベートリポジトリもOK。すごい。

Bitbucket のプライベートリポジトリに対応しているものは他に Magnum CI というものがありますが、
これは公式Twitterが2015年4月以降つぶやいておらず、使用には不安が残るところです。

フリープランでも並列ビルド

Circle CI は無料プランで 1ビルドまでですが、wercker は無料プランで 2ビルドまで同時に実行されます。

下の写真は、3つのビルドを要求したところです。
2つのビルドが同時に動いているのが確認できますね。

おおげさに言えば Circle CI より2倍速いです。すごい。

f:id:nekonenene:20160823154140p:plain

Docker イメージが使える

Docker Hub に豊富にある Docker イメージを使うことが出来ます。

wercker.yml 内に

box: user_name/repository_name

と記述します。

Official Repository に対しては user_name 部分は省略できます。
docker pull でリポジトリを指定するのと同じですね。

box: ubuntu:trusty

ubuntu:trusty のように書くと trusty タグのイメージが、
何も指定しないと latest タグのイメージが入ります。
(Docker を使ったことがなかったので、ここらへん最初は戸惑いました)

以下のようにプライベートリポジトリを使用することも可能です。

box:
    id: your_user_name/repository_name
    username: your_user_name
    password: $DOCKER_PASSWORD

ビルドに必要なパッケージをひととおりインストールした Docker イメージを作っておけば、
一度一度のビルドにかかる時間が短縮できていいですね。

非公開な環境変数の設定

上で書いた $DOCKER_PASSWORD の値はどこに書きましょう?
いくらプライベートリポジトリとは言え wercker.yml の中にそのまま書くわけにもいきません。

環境変数は、wercker のサイト内で設定することが出来ます。

f:id:nekonenene:20160823161839p:plain

protected のチェックをONにすると、以下のように、値が見えないようにして保存されます。
wercker をチームで使っている時もこれなら安心ですね。

f:id:nekonenene:20160823162004p:plain

気をつけるところ

pipeline 間で設定は持ち越されない

f:id:nekonenene:20160823164750p:plain

写真のように、wercker はタスクのまとまりである「パイプライン」同士をつなぐことが出来ます。
この場合は、build パイプラインが終了した後に、master ブランチへの push だったら deploy パイプラインを実行する。という作りになっています。

この「パイプライン」で気を付けるべきなのは、つながっているように見えて設定状況は引き継がれないことです。
例えば build パイプライン内で curl をインストールしたとしても deploy パイプライン内では curl コマンドは使えません。

deploy パイプラインの中で、改めてセットアップやビルドをおこなう必要があるわけです。

なお、パイプライン内であれば、steps だろうと after-steps(steps の成否に問わずおこなわれる。ビルド結果の通知などに利用) だろうと状態は引き継がれます。

wercker-box は非推奨

f:id:nekonenene:20160823171120p:plain

wercker.com には「Registry」というページが用意されていて、ここには wercker-box イメージが並んでいます。
ですが、wercker-box を使うのは現在非推奨で Docker の使用が推奨されています。

上部メニューに並んでいますがこれは今や使わないページということを、これから wercker を使い始める人は頭の片隅に置いておいてください。

使い方

こちらのページがスクリーンショット付きできれいに書いてくれていますのでご覧ください。

Dockerベースになったwercker v2でRailsアプリをCIしてSlackに通知、herokuにデプロイする手順 - Qiita

詳しい部分は公式のドキュメントを参照するといいでしょう。

GitHubアカウントさえあればカンタンに登録できます。


UUUM ではエンジニアを広く募集しています。

新しいツールが好きな人や、自由な社風でバリバリ仕事されたい方、
下のリンクからぜひ一度お話を聞きにいらしてください!