このエントリーは、Atlassian User Group Tokyo Advent Calendar 2016 - Qiitaの23日目エントリーです。
2016年10月に開催されたアトラシアンサミットでソースコードホスティングサービスBitbucket Cloudと継続的インテグレーション(CI)によるビルド・デプロイを統合した新サービス、Bitbucket pipelinesのサービスインが発表されました。
Bitbucket Pipelinesは、Bitbucket上で管理されているソースコードにビルド設定を記述したbitbucket-pipelines.yml(例)をコミットすると、Bitbucketへのソースコードのpushをトリガーとしてビルド及びデプロイを実行するというサービスで、Travis CIを始めとするGitHubに統合されたCIホスティングサービスと同様のサービス形態になっています。また、本年12月一杯までは無料で使用できます(2017年1月以降は1セント/1分の予定)。
Bitbucket Pipelinesの特徴としては、以下の四点が挙げられます
- Bitbucket Cloudとの統合
- DSL(bitbucket-pipelines.yml)でのビルド記述
- Dockerベースでのビルド環境
- プルリクエストベースでのビルドフロー
このエントリーでは、同じくアトラシアン社のオンプレミスでのCIパッケージであるBambooと比較した場合に大きな特徴となる、プルリクエストベースでのビルドフローについて、Bambooとの比較をしながら、述べていきます。このエントリーで試用したサンプルはBitbucket上で公開しています。
プルリクエストベースでのビルドフロー
Bitbucket Pipelinesでは、bitbucket-pipelines.yml上での記述により、ブランチごとにビルドの設定をカスタマイズすることができます。
Bitbucket Pipelinsでデプロイを行うには、デプロイの対象となるブランチに対して、プルリクエストを作成します。例えばbitbucket-piplelines.yml上で、masterブランチをビルドした際に本番環境へデプロイを行うように記述されている場合、本番環境へのデプロイを行う場合には、masterブランチに対して、プルリクエストを作成します。
これは、GitHubに統合するかたちでのCIサービスで広く採用されているワークフローと同様なっています。これに対してBambooのデプロイは、それぞれのブランチのビルドを起点としてリリースを作成し、そのリリース内の成果物(artifafct)を各環境にデプロイするワークフローとなっています。
プルリクエストでのデプロイの特徴
プルリクエストを中心としたワークフローベースのデプロイの特徴としては、やはりワークフローが簡潔となることが挙げられます。どのような手順を踏めばデプロイされるかということが、「masterブランチにブランチをマージすれば本番環境にデプロイ」されるというように明快になります。また、ワークフローが単純になることのメリットとして、チャットを運用のワークフローに組み込む、ChatOpsへの親和性も高くなります。
これに対するデメリットは、ブランチのビルド設定とデプロイのワークフローを結びつけたことにより、一つの環境にデプロイされるのは特定のブランチの最新ビルドとなることがあげられます。これに対し、BambooのようにCIのビルドからリリースを作成するデプロイの場合は、任意ブランチの任意ビルドがデプロイ可能です。
今のプロジェクトで、releaseのブランチがリリース準備の作業中の時に、本番環境で緊急に修正を要する障害が発生した場合のデリバリーのワークフローの検討を行ったりもしたのですが、こういう場合はやはりBambooのようなリリースとブランチが疎結合になっているモデルのほうが都合が良い、と考えます。
また、リリース時に問題が発生し、一個前のバージョンに戻す、いわゆる「切り戻し」を行う場合は、プルリクエストベースのデプロイの場合は、
- リリース内容をrevertするコミットを作成して再度プルリクエストを作成する
- リリースブランチをリリース前のリビジョンでハードリセットする
- immutable infrastructureにして一個前のインフラ構成に戻す
のいずれかの手順を踏むことになります。
これに対して、Bambooのようなリリース内の成果物をデプロイする場合は、CIサーバー上で一個前のバージョンのリリースをデプロイすることによって、切り戻しを行う事ができます。
また、複数モジュールからなるシステムを構築する際、モジュールが親モジュール(いわゆる「共通モジュール」)と子モジュールに別れている場合に、Bambooではブランチごとに独立してビルドの依存関係を持たせてビルドチェーンを構築することができますが、Bitbucket Pipelinesではそのような機能を有していません。
まとめ
このようにBitbucket PipeliesのようなプルリクエストベースのワークフローとBambooのようなリリースベースのワークフローを比較した場合に、プルリクエストベースでのデプロイの特徴としてあげられるのは、パイプラインがバージョン管理システム(VCS)のブランチと密結合になるかわりに、身軽さを得たワークフローだということです。このようにデプロイのワークフローについての設計思想がBambooと根幹から違うため、Bitbucket PipelinesはBambooの代替にそのままでなるものではなく、実際Bambooにも新機能の追加は活発に行われていますので、ワークフローに対して求められる厳格さに応じて、しばらくはBitbucket PipelinesとBambooの棲み分けが続くと考えられます。
