Pulseは、ソースリポジトリを監視して、だれかがコミットを行うたびにビルドおよびテストのサイクルを開始するビルドサーバだ。Pulseを使えば、バージョン管理システム内にある最新のソースのコンパイル状況や、単体テストおよびシステムテストの経過をたえず把握できる。さらに、パーソナルビルド（Personal Build）という機能により、チェックアウトしたソースの作業用コピーのビルドやテストが行えるので、セントラルリポジトリに対して変更をコミットする前に、コードに問題がないか確認することができる。
Pulseのようなサービスを好まない開発者もいる。コードをチェックインした場合にリグレッション（回帰）テストの中断やほかのメンバとのやりとりが必要になったりするからだ。だが、プロジェクトの回帰テストを実行したうえでソースのコミットができれば、開発者はメインのソースツリーに対するコミットを行う前にコード変更の影響を把握できる。
Pulseのインストール手順については、PulseのWebサイトに詳しい説明があるので、ここでは触れない。今回、Pulseのバージョン2.0.xとバージョン1.2.59の両方を64ビット版Fedoraマシンで試したが、2.0.xのほうはインストール中のデータベース作成が行えなかった。また、Pulseの起動によって現れるWebインタフェースでは、パーソナルビルドの実行を除くすべてのタスクで8080番ポートが使用される。
少人数のチームやオープンソースのプロジェクトには、フリーのライセンスでPulseが提供されている。しかも、オープンソースコミュニティ向けのライセンスでは、プロジェクトあたりのユーザ数に制限がない。なお、個人的にはautotoolsによるビルドやDejaGnuによるテストがデフォルトでサポートされていることを期待していたのだが、Pulseはそのいずれも明示的にはサポートしていない。
ビルドに関しては、Ant、Boost Jam、GNU make、Maven, Xcode、それにカスタムのビルド設定がサポートされている。テストについては、boostリグレッション、CppUnit、OCUnit、CUnit、JUnit、UnitTest++、Mavenがサポートされている。
Pulseを使ってCVSにあるautotoolsのプロジェクトをビルドするには、ちょっとした工夫が必要だった。具体的には、GNU makeによるビルドを参考にして設定を行い、「projects」→「ferrisloki」→「configuration」で開くウィンドウ上でカスタムのビルドタイプへと変換した。このとき、「projects」は最上位のメニューから、libferrislokiは既知のプロジェクトの1つとして選択し、「configuration」はそのサブメニューから選択する。動作確認にlibferrislokiを選んだ理由としては、なじみのあるコードベースであること、短時間でビルドできること、すでの私のローカルCVSリポジトリに入っていること、標準的なautotoolsの慣例に従っていることが挙げられる。