Bitbucket Pipelinesファーストインプレッション Ansible * PostgresをCIしてみた。

Bitbucketに新しく導入されたPipelines (β版) をつかってAnsibleでPostgreSQLをインストールするビルドタスクを走らせてみます。

Pipelinesを使うのが初めてなので、ファーストインプレッションの感想が多めです。
※細かな設定はBitbucketリポジトリ i05 / ansible-postgres から確認できます。

Bitbucketリポジトリで Pipelines を有効にする

リポジトリを作成後、サイドバーから Pipelines を選択します。ここで、1つ小さな注意点があります。

ポイント: bitbucket-pipelines.yml はチェックインしない

私は bitbucket-pipelines.yml の設定 を前もって読んで bitbucket-pipelines.yml を git commit した状態でレポジトリへプッシュしたのですが bitbucket-pipelines.yml はBitbucketのページから作成する必要があるようで "A file with this name already exists" なるエラーが出てしまいました¹。

ということで気を取り直し bitbucket-pipelines.yml を取り除いた状態で再プッシュ。

プルリクエスト作成でビルド開始

Bitbucket上で bitbucket-pipelines.yml を編集します。

bitbucket-pipelines.yml

image: python:2.7.12

pipelines:
  default:
    - step:
        script:
          - pip install --upgrade pip && pip install --requirement requirements.txt
          - echo localhost > inventory
          - ansible-galaxy install --role-file=role_packages.yml
          - ansible-playbook --inventory-file inventory site.yml --connection=local

特段トリッキーな印象はなく、書式に従えば期待通り動きました。
実行する処理はDockerfileに記述する内容と同等だと考えればよさそうです。
ここでは以前使用したことのある travis.yml のコマンドを大部分流用しました。

次のうちどちらにするか聞かれるのでお好みの動作を選択。ここでは健全にプルリクエストを作成します。

• そのまま master ブランチにコミット
• プルリクエストを作成

実際に作成したプルリクエストは i05 / ansible-postgres / Pull request #1: bitbucket-pipelines.yml created online with Bitbucket になります。

プルリクエストを作成すると、自動的にビルドタスクが開始されます。
このあたり、外部サービスで新規レポジトリのビルドを走らせる場合は設定が必要（サービスに遷移→アカウント下のレポジトリを読み込み→プロジェクトでスイッチをONにする、など）なので嬉しいところです。

空いているからかすぐにビルドが始まりました。
待ち時間がないのは快適ですね。

標準出力をよしなに抜粋して折りたたみ表示をしてくれます。

ビルド失敗の様子。色がついていて直感的に理解できます。

プルリクエスト一覧ページでもビルドステータスが表示されています。

ビルド失敗のメール通知も届きました。

ビルドがこけた箇所を修正

お行儀が悪いですが今回は master ブランチ側を修正したので "Sync now" で修正を反映します。

Pipelinesとは関係ないですが、明示的に sync しなければならないのは好き嫌いが分かれるところかもしれません（gitの push.default 設定に通ずるところがある気がします）。

そして sync にともなって自動でビルドタスクが走ります。賢い。

ビルドが走りきったのでマージします

何度かの修正後、Ansibleのタスクが走りきりました。

公式ドキュメントの Debug your pipelines locally with Docker では、今回のように失敗ビルドを量産して恥ずかしい目にあわないように手元のマシンで試す方法が紹介されています。

といっても、特別なことは何もなく通常通りDockerイメージを走らせるだけなのですが、ドキュメントではPipelinesの環境を再現できるよう memory のオプションなどが紹介されています。

プルリクエスト一覧ページからもビルドステータスが確認できます。

個別のプルリクエストページでも "N of N passed" と表示されています。

ステータスはOverviewで表示される

地味に便利なのが Overview ページに "master has passed" と表示されているところ。
外部サービスを利用すると手動でREADMEにバッチを貼り付けなくちゃいけませんが、その手間が省けます。

所感

あくまで個人プロジェクトで軽くつかってみての感想です。

Pros

• 外部サービスではないので、複数のタブを行ったり来たりせずに済むのが気楽。
• ビルド開始の待ち時間が短い（これは今後の普及度合いによって変わってきそうです）。

Cons

• 任意のDocker imageが使えるのでほとんどのLinux環境などは使えるが、例えば類似のCIサービスではMacOS環境をサポートしてiOSアプリをビルドできたりするので、そういう用途ではまだ使えない。
• REST API が未サポートなので外部ツールとの連携が難しい。オープンなチケットは #13116 - Add pipelines endpoint to REST API にあるので用意されそうではあります。 2016-12-01追記: Bitbucket APIにてPipelinesエンドポイントが提供開始されました。ビルドの一覧取得やエンキュー、状態取得および停止操作などが可能です。
• 複雑なデプロイタスクにまで発展させられるようなJenkins的な「なんでもあり」感はない²。

まとめると、統合サービスならではの導入の手軽さが魅力。CIサービスとして、ビルドやテストが主用途となりそう。

1. 2016-11-01現在。改善が入りそうな予感はあります。 ↩

2. 具体的には複数リポジトリや静的ファイルホストサービス (S3など) と協調するようなデプロイタスクとフェイルオーバーの仕組み。あと鍵管理・ネットワーク制限を用いてデプロイをセキュアに実行する仕組みも気になるところです。簡易的な鍵管理の方法は How do I set up ssh public-key authentication にて紹介されています。 ↩