2018/12/05
Bambooの良い点と使いづらい点（2018年個人調べ）
Author
奥村 和彦Kazuhiko Okumura
このエントリーは、 Atlassian（JIRA , Confluence, Trello, Bitbucket）のTips Advent Calendar 2018 – Qiitaの6日目です
「アジャイル」「DevOps」「生産性向上」「技術的負債の削減」といったキーワードの実現にCI/CDの導入は欠かせません。この1年間にお客様からのご要望や導入相談で、AtlassianのCI/CDツールBambooについて色々な使い方を検討し提案しました。
そこでBambooに触れた中で、「良いなと感じた機能」と、「ここがちょっと使いづらいな」と思う部分を振り返ります。
気に入っている点
ビルドパイプラインが設定しやすい
Bambooのビルドのワークフローは【プラン】 > 【ステージ】 > 【ジョブ】 > 【タスク】で構成されます。
- タスク・・・”コマンドの実行”や”スクリプトの実行”といった一つ一つの作業を定義します。特定のソフトウェアや実行環境専用のタスクなども用意されています。
- ジョブ・・・１つ以上のタスクの実行と実行順を定義します。ジョブは1台のエージェント(ビルドサーバー)内で実行します。
- ステージ・・・1つ以上のジョブを管理します。同一ステージ内のジョブは複数台のエージェントで並列実行します。またビルド結果はステージ単位で集計されます。
- プラン・・・1つ以上のステージとステージの実行順を定義します。Bambooの一連のビルド実行はプラン単位で制御します。
- ビルドのプラン内で必要な作業(タスク)をジョブとステージでグルーピングすることで、柔軟な作業工程管理が行えます。
図1: ビルド | プラン設定 | ステージ・ジョブ設定
図2: ジョブ設定 | タスク設定
ビルドの成果物が管理しやすい
ビルドでは様々な成果物（Artifacts）を作成します。(ex.実行可能ファイル、ライブラリ、自動テストのレポートファイル）
Bambooはジョブごとに成果物に別名を定義して保存・管理でき、ビルドの実行結果からダウンロードすることができます。
更に成果物を共有(Share)しておけば、プランの後続ステージで再利用したり、デプロイ作業でダウンロードしてリリースすることなどができます。
図3: ジョブ設定で成果物のパスと別名を管理する
図4: ビルド結果から成果物がダウンロードできる
リリースが管理しやすい
Bambooにはリリースを管理するためのデプロイ専用の管理機能があります。デプロイ画面ではリリース先となる複数の環境設定を作成し個々に定義できるので、
環境ごとに異なるタスクを用意したり、権限を設定できます。
またリリース実行時には、リリース番号を割り振り管理ができますので、トレーサビリティも可能です。
図5: デプロイ管理で、リリース環境ごとの設定が可能
ビルドの実行がVCSとリンクしたブランチで管理できる
ビルドのプランはVCS(Bitbucketなどのバージョン管理システム)と同じようにブランチを使った実行管理ができます。
一般的にはVCSのブランチへのコミットをトリガーにして、Bambooのビルドプランを実行するときにVCSと同じブランチ名でプランブランチが作成されます。
プランブランチとVSCのブランチを関連付けることで、VCSのブランチにビルドのトレーサビリティが実現できます。
またリリース先の環境が複数ある場合、どのプランブランチと環境をリンクさせてリリースすることができ、例えば成功したビルドブランチが、Devlopブランチなら開発環境のデプロイ、ReleaseブランチならUAT環境、Masterブランチなら本番環境のようにリリース先の指定できます。
図6: Bambooのプランブランチが、Bitbucketのブランチのコミットから自動作成している
ビルドの実行環境にDockerコンテナが使える
これはBambooのDocker Runnerと言う機能で、ビルドパイプラインの説明の中で「ジョブは1台のエージェント(ビルドサーバー)内で実行する」とお話しましたが、実行環境にエージェントではなくDockerコンテナ(Dockerイメージ)を使うことができます。
この場合エージェントのケイパビリティ(*1)にはDockerをインストールしておけば、実際に必要な実行環境は予め用意しておいたDockerイメージを指定しておくことで、Dockerコンテナ上でジョブのタスクを実行できるようになります。
バージョンアップが頻繁に行われるSDKを利用するジョブの場合に、SDKバージョンごとのDockerイメージを用意することでエージェントに複数バージョンのSDKをエージェントに直接インストールする必要が無くなるので、エージェントのケイパビリティが複雑化することが無くなったり、ビルドの環境とリリースの環境を同等に保つことができます。
更にジョブごとに実行環境が違っても、Dockerコンテナでビルドができれば特定のエージェントを占有する必要が無くなり、リソースを有効に活用できるといったメリットがあります。
(*1)エージェントのケイパビリティ：エージェント(ビルドサーバー)が実行できる能力のこと。例えばJDK・XcodeSDKなどの実行環境、Maven・MSBuildなどのビルドツール、またはGit・Dockerなどのツールなどを指定します。
図7: ジョブ設定のDockerタブで利用するDockerイメージを指定できる
AWS EC2でエージェントの自動スケーリング設定が出来る
BambooのエージェントサーバーにAWSのEC2を利用する場合にElastic Bambooを使うと、インスタンスのスケール管理ができるようになります。
通常は1台のEC2インスタンスを起動しておいてビルドを実行しますが、並列実行が必要になると自動的にインスタンスを追加起動します。
またビルドが終了したらインスタンスを自動で停止するといったり、自動で起動するインスタンス数の上限を設定できるので、スケーラビリティやランニングコストを必要最小限に抑えることができます。
尚、これを利用するためには予めBambooエージェントをインストールしたり必要なケイパビリティをインストールしたAMIが必要です。Atlassianが提供しているAMIもありますがリージョンが限定されていたり、インスタンスタイプが若干高めだったりします。
図8: Elastic Bambooはシステム設定で行う
ココがちょっと。。。という点
実際にお客様からの相談であった「使い方が分からない点」や「改善してほしい点」も挙げ、このようなご相談に対して私たちがどのような提案をしたかもご紹介します。
専用タスクの種類を増やしてほしい
「コマンドタスク」と「スクリプトタスク」を使えば、ほとんどのビルドは実行できると思いますが、そのコマンドやスクリプト自体のテストやメンテナンスも必要になります。
様々な実行環境やツール専用のタスクがあれば設定も簡単になると思います。またテスト結果の分析・レポーティングできるタスクも少ないので品質管理を行う場合にはSonarQubeのような専用の製品を構築して、Bambooと連携するなどの検討が必要です。
アドオンを追加することでタスクを増やすこともできますが、他のAtlassian製品と比較するとBamboo用のアドオンの数は少ないのも正直なところです。
このため、ご要望の処理を出来るだけ簡単に実現するための手段をご相談頂くこともあり、目的に応じて最適な方法をご提案することもありました。
外部のツールへWebhookで通知したい
Bambooには他システムが公開しているWebhookを利用して通知できる機能が無く、通知先として選択できるコミュニケーションツール・チャットツールが限定されてしまいます。
Slackへの通知機能はアドオンを導入したり、XMPPが利用できるインスタンスメッセンジャーへなら通知できるのですが、Hipchatが販売終了となりましたし、他の様々なコミュニケーションツールに通知するためにもWebhookが設定できると便利だと思いますので、メーカーへ要望を出していきたいと思います。
日本語でローカライズしてほしい
言語の設定変更ができず英語表記しか無いというのは、日本の企業とエンジニアでBambooが利用されない原因としては決して少なくないと考えています。
実際に使ってみればそれほど難しくはありませんが、日本語のドキュメントがあればツールの学習コストも下がりますので、私たちもドキュメントの日本語化をメーカーに要望すると共に、みなさんがBambooを使いやすくなるようにサポートをしたいと思います。
ドキュメントの体系をもっとわかりやすくしてほしい
他のAtlassian製品のドキュメントと比較したときに体系が整っていないように感じます。同じ機能の仕様について、複数のドキュメントで異なる書き方で説明しており、どのように使うのが正しいのかがわかりづらかったり、どんな機能でどんな制約があるのかが分かりづらかったりします。
これはツールと同じくドキュメントのほとんどが日本語に翻訳されていないことも理由として大きいとは思います。
また、ビルドやデプロイのユースケースはアーキテクチャや要件によって全く異なるので事例も多く必要になりますが、そのようなナレッジ的な情報が少ないので「利用したくても参考になる情報が無くて….」というご意見を頂くこともありました。そのような場合に私たちが持っている事例を紹介したり、実際に試してみたことをデモで見せて実現性のイメージを持って頂いたりもしました。
必要なエージェント数がわかりにくい
Bambooのライセンスは他のAtlassian製品と違ってユーザー数では無く、ローカルエージェント(Bamboo本体以外のビルドエージェントサーバー)の数で定義しています。
このため見積もりの時には、ビルドで必要なサーバー数などを予め把握する必要があります。
CI/CDを既に実践している場合は必要なエージェント数を判断するのも難しくないかもしれませんが、始めて導入する場合などは判断も難しく「ライセンス数はどの位が良いか？」というご質問も頂くことがあります。そのような場合に私たちも一緒に考えてアドバイスをしたりしています。
2018年 Bambooふりかえり
正直に言うと「ココがちょっと。。。」という点が、日本企業のエンジニアから見てBambooの敷居が高く感じてしまう所になっているのではないでしょうか。
だけどここを乗り越えると、思っていた以上に使いやすく便利なツールですので、最初の難しさで諦めずに試行錯誤しながら使いつづけてみることをお薦めします。
Bamboo本体の敷居を低くすることは難しいですが、私たちのサポートやアドバイスを通してお客様が敷居を乗り越えるお手伝いをしていきますので、ぜひBambooを試してみてください。
またお困りのことがありましたら、ぜひリックソフトまでご相談ください。
製品について詳しくはこちらをご覧ください。
