クワイエット ピリオドとは、一体何？

クワイエット ピリオド (待機期間) とは、Bamboo と繋がっている各レポジトリ上のオプション設定です。レポジトリに対するコミットが行われたのを確認した後、クワイエット ピリオドは Bamboo に対して、実際にビルドを始めるまでどれだけ待機するかを伝えます (有効な場合)。これは、リンクされたレポジトリの設定画面の、Advanced options の下にあります。

設定は、次のようになっています。

ちょっとした小話！クワイエット ピリオドは、元々 CVS コミットが atomic では無いという現実に対応するため開発されたものでした。但し一般的には、ご利用のシステムのバージョンに関わらず、複数コミットを単一のビルドに合体させる際に使用できます。

なぜ、このような事をする必要があるのでしょうか？

クワイエット ピリオドが関係してくるのは、コミットが作成された際、 Bamboo に通知するようレポジトリが設定されている場合です。このように設定されておらず、また Bamboo が変更に関してレポジトリにポーリングしている場合、ポーリング・ピリオドは複数コミットを単一ビルドへ合体させる方法として機能するため、クワイエット・ピリエドを使う意味はありません (以下の図を参照)。注:この図は一定の縮尺ではありません (ビルド時間が、実際にはかなり大きいものと想像して下さい)。このような稀なケースにおいては、ポーリングが便利になり得ます。

クワイエット ピリオドの主なユースケースとなるのは、ビルドが長い場合で、あなたのコミットの直後にデベロッパーがコミットしたときに、いわゆる「同じ電車に乗車する権利」を奪いたくない場合です。一般的に長いビルドは避けたいものですが、必ずしもそうはいきません。ビルドに時間がかかり (仮に一時間として)、誰かがあなたの直後にコミットした場合、彼らはそのビルド結果を得るまで二時間近く待たなくてはいけなくなります。皆が「乗車」できるよう、電車があと少し待ってくれればいいのですが！

同じプランのパラレルビルドの場合は？

Bamboo のデフォルト設定では、一つのプランにつき同時発生のビルドを一つ許可するようになっています。一つのプランに関して複数の同時発生ビルドを許可するのは不可能ですが、そのような事をこのインスタンスで行っても、問題の先送りにしかなりません。例えば、ビルドの同時実行を二つに設定すると、三つ目のビルドは最初の二つのいずれかが終わるまで待たなくてはいけません。これより、三つ全てのコミットを同一のビルドで回収した方が得策です。

クワイエット ピリオドはいつ使用するのか？

クワイエット ピリオドの使用は、時間が長く (例えば一時間以上)、レポジトリのコールによって引き起こされるビルド (インターバルにおいてレポジトリをポーリングするビルドではなく) の際に検討すると良いでしょう。クワイエット ピリオドは、ビルド (電車) を少し待機させて、いくつかのコミットが（乗車）できるようにする事で、その後のコミットの応答時間を減少させる事が可能です。ビルドの時間がここでは最も大きな値となるため (図が一定の縮尺ではない点をお忘れなく)、一つめのコミットに少し遅れがでるものの、二つ目、三つ目のコミットに関しては大きな時間の節約となります。よって、全体として考えれば、これは良い事です。

ちなみに、ビルドキューを最小限に留めるためにサーバーを調整する試みと、クワイエット ピリオドの設定を混同しないよう注意して下さい。そのような目的には、グローバルレベルにおける並列ビルドの設定 (プランレベルでもオーバーライド可能) を利用して下さい。

クワイエット ピリオドは、Bamboo の新機能ですか？

いいえ。但し、これまで以上に重要な機能となっています。

先週リリースされた Bamboo 5.6より前は、コミットを受理してビルドを引き起こす際に Bamboo に対して積極的な呼び出しを行うレポジトリの設定は、正直な所かなり面倒でした。 そして、これがリポジトリ駆動型ビルドトリガーと最も親和性が高いため、クワイエット ピリオドは私たちの顧客にさほど利用される機会がありませんでした。

しかし現在、Bamboo を Stash に繋いだ際のレポジトリ駆動型ビルドトリガーは、非常にシンプルなものになっています。Bamboo 向け通知は、Stash でレポジトリを作成した後、即座に自動的に設定されます (既存の Stash レポジトリの場合は、バックエンドで Bamboo を Stash に繋いだ直後)。よって、これをビルドプランのトリガータイプとして選択するだけの事です。このようにしてビルドをトリガーした方が、毎分レポジトリのポーリングに Bamboo の CPU サイクルを支出するよりも遥かに効率的です。これは特に、レポジトリとビルドプランの数が多ければ多い程、当てはまります。クワイエット ピリオドがある意味話題になってきているのは、このような理由によるものです。

今回のブログで、実行時間の長いビルドにおいてはレポジトリ駆動型トリガー、およびクワイエット ピリオドを試してみる気になれたでしょうか。これは、デベロッパーのチームと作業をしている際、CI をより効果的にできるちょっとしたコツです。

本稿は、Atlassian Blogs 日本語版の転載です。本文中の日時などはAtlassian Blogs 英語版での投稿当時のものですのでご了承ください。