前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
小さなチームやスタートアップ、または外部のコンサルタントを雇って開発をする場合には、自前でサーバを用意するよりもサービスとして利用する方法が賢い選択になることがあります。EC2などの環境でJenkinsを自分で運用するのと比べて、サービスとして利用するには次のような利点があります。
- 導入が容易。ファイヤーウォールの設定やアクセス制御などを自分でする必要がありません。
- 管理の手間が楽。バックアップやバージョンアップなどはおまかせです。
一方、代表的な欠点としては、ビルドやテストの環境を細かく制御することができない点が挙げられます。
CloudBeesでは
Jenkinsをサービスとして提供していて、ユーザー登録を済ませると、すぐにJenkinsを利用できます(下図)。制約付きながら、無料で利用できるプランもあります。
CloudBeesのJenkinsサービスは現在EC2上にホストされており、クラウド環境を利用した色々な面白い機能があります。
例えば、ビルドに使われるスレーブは必要に応じて動的に割り当てられます。上の図では現在実行中のビルドがないのでスレーブは一つも割り当てられていませんが、ビルドがスケジュールされるな否や、スレーブが追加されて30秒程度でビルドが始まります。このように必要に応じてスレーブが割り当てられるので、テスト等、一時的に大量のスレーブが必要な場合に便利です。
また、この環境ではフォルダ機能やロールによる高度なアクセス制御など、オープンソース版には含まれていないプラグインが無償で利用できます。これによって、単一のJenkinsインスタンスを細分化して別々なチームが独立に利用できます。
もう一つ、ホスティングならではの機能を紹介すると、GitHubなどの他のサービスとの連携があります。例えば、「GitHubに変更がプッシュされたらビルドする」というトリガを選ぶと、ポーリングではなくGitHubにフックが自動的に設定され、変更をGitHubにプッシュしたら直後にビルドが始まるようになっています。
Jenkinsの導入の敷居を下げたい場合や、個人のホビープロジェクトなどにも便利だと思います。試してみてください。
◆関連記事
Jenkinsによる継続的インテグレーションのススメ(1)
Jenkinsによる継続的インテグレーションのススメ(2) ~Jenkinsを使い始める~
Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~