計算能力を使い尽くすためにJenkinsができること
継続的デリバリにおいて、潤沢な計算能力を十分に活用するため、処理の並列化や高度な自動化の重要性について改めて強調した上で、川口氏はそれらをJenkinsで具体的にどのように実装しているかについて紹介した。
アプローチのひとつは「コミットの検証済みマージ」だ。継続的デリバリを推進することで、本来ローカルでやっていた仕事をサーバ側に移行できているかという点で「まだ不十分なケースがある」とする。
その理由のひとつは、Jenkins側のテスト時にソースコードをコミットする際、「そのコミットに問題があると他のメンバーに迷惑がかかる」という懸念があるためだという。この場合、結局のところ迷惑をかけることを恐れて、本来サーバ上で行えるテストをローカルで行ってしまうというケースもある。
また、大規模プロジェクトにおいて、開発者が問題のあるコミットをする確率が一定なら、チームが大きくなるほど、何かの問題が生じる確率は限りなく100％に近づくというジレンマも存在しているとする。
検証済みマージは、こうした問題の解決に役立つという。これは、開発者がブランチにコミットをした場合に、Jenkinsが自動的にブランチのテストを行い、テストの結果が問題なければ、トランクにマージしていくというもの。この仕組みを組み込むことにより、コードの間違いを恐れずにコミットし、テストはサーバ側に任せながら、テストの待ち時間を考慮せずに次の作業へ着手できるという利点がある。
大規模なプロジェクトになると、この検証済みマージを階層化する手法を用いることになるが、Java SEやNetBeansなどの開発は、そうした手法に近いやり方で運用されており、「実際に試されて、価値が認められた手法だ」（川口氏）とする。なお、この検証済みマージの詳細な実施方法については、最新号（vol.67）の「WEB+DB PRESS」において、川口氏自身が解説記事を執筆している。
昇進モデルによるデプロイの自動化
「ビルド」と「テスト」に次いで、Jenkinsで自動化を図ろうとしている分野は「デプロイメント」だ。「発想としては、ビルドができたら、検査の一環として、それをどこかで常に動かしておこうというシンプルなもの。開発者にとってのメリットもさることながら、プログラムが動いているということによって、さまざまな副次的な効果がある」と、川口氏は言う。
実際のシステム開発にあたっては、コンパイルが通ったコードをすべてデプロイして良いわけではなく、ユニットテスト、結合テストなどの順に、徐々に規模の大きなテストを行い、検証していくという手法が用いられる。従来のウォーターフォールモデルの開発においては、「パイプライン」を設定することで上流と下流をプロジェクトでつなぎ、各段階での検証をパスした実行可能なプログラムをコピーしながらデプロイまでのプロセスを流していくという方法がとられている。
一方、こうした伝統的なパイプラインよりも効率的な手法として、Jenkinsではビルドの「昇進モデル」を取り入れたデプロイにも、プラグインによって対応できるという。この手法は、デプロイまでのプロセスフローではなく、ビルドの状態遷移に着目するものである。例えば「コンパイルが成功」し「ユニットテストを通過」したものが「ビルド合格」の状態、「カバレッジ60％」「結合テスト通過」という条件をパスすれば「品質検査合格」の状態、「UAT環境で3日以上動作」すれば「試験運用済み」の状態といったように、コードの状態を「昇進」させて、次のステップへと進めていく。川口氏は「SNSでいう、バッジをつけるようなもの」と昇進モデルのイメージを説明した。
このモデルの利点としては、厳密にプロセスが決まっている従来のワークフローに比べて、枝分かれなど柔軟な過程を取ることができ、非同期処理が可能な点だ。さらに、昇進条件の詳細な調整が簡単に行え、チーム間の引き渡しがより自然に行える点、昇進の契機となるイベントは何でもよく「トリガの呪縛」から解放される点などを挙げた。総じて「開発作業を行う人間が、自然と感じられ、ストレスの少ない状態」でデプロイを進められる点がメリットになるという。
