すずけんメモ

技術メモです

アプリケーションポータビリティとJenkinsの有り方に関する所感

Jenkins

弊社ではJenkinsおじいちゃんに日々お世話になっております。隣のチームの @_zoo さんもJenkinsおじいちゃんについての記事を書いておりました。

ということで僕的最近のJenkins運用について書きたいと思います。去年の運用と今年の運用を比較していきます。

去年のJenkinsのタスク

以下のことをやっていました。何でも屋ですね。

  • デプロイ
  • テスト
  • 通知: メール
  • 高度なcrontab

去年ad:tech TokyoでMapReduceジョブのdispatchとmonitoringをしているという発表もさせていただきました。

このころからずっと、開発は github.com で行っていました。基本的にはビルドパイプラインプラグインを利用していて、リポジトリ更新のタイミングでfetch、masterブランチであれば開発機へビルド。topicブランチについては逐一テストが周るようになっていました。

ただこの発表以降、あまりJenkinsについて書いたり話したりしてきませんでした。なんだろう、自分の中でこういろんなことが当たり前になってきているので、今更Jenkinsについて書かなくても・・・と思ったりもしました。ところが実際に1年間振り返ってみると、Jenkinsの使い方にもそれなりに変化がありました。というところをまとめつつ紹介します。

Jenkinsでやっている仕事2013

  • デプロイ
  • テスト
  • 通知: メール, idobata, GitHub status api
  • ソフトウェアメトリクス生成

少し変わりましたね。

通知系統

最近はテストがこけるとPull Requestのステータスをupdateするようにしました。これで大分テストのチェックが楽になりました。また、 idobata.io にも試験的に各種通知を流すようにしていて、JenkinsでのJobのdispatch状況については逐一流れるようになっています。api連携という点においてidobataは大変容易です。通知系統に関しては非常に開発に利する面が大きかったです。Jenkins自体が何をしているのかということが時系列で手に取るように分かりますし、誰がどういうコードを書いていて、その結果どこの部分のコードが落ちていて、何が原因で、どう修正して、いつテストが通って、いつデプロイをしたか、ということがスムーズに把握できるようになりました。これは想定していたよりも大きな変化でした。

ソフトウェアメトリクス

ソフトウェアメトリクスについては最近取り組み始めました。僕の担当領域ではPHPで管理系アプリが書かれている機会がほとんどなので、PMDやClover PHPなどを利用してソフトウェアメトリクスを出すようにしています。

僕自身のタスクのメイン領域はログを如何に解析しやすくするか、如何に解析結果を有効に利用するか、如何に成果に結びつけるかというところにあります。しかし管理系のアプリケーションについてもコードレビューについては継続的にするようにしています。ただし、やはりレビューできる時間というのは限られています。とりあえずモニタリングしている程度ですが、Pull Requestが長くなってくるとなかなか見るポイントを掴むのも大変だったり、集中力をどこで使うかを見極めづらかったりするので、ある種のアラートとして利用しています。

デプロイ ~ fabricとmakeがあればよい ~

デプロイについては相変わらずfabricを利用しています。

これは去年から変わりません。Jenkinsが落ちていても、fabricを利用してproduction / pre / developmentの各環境にデプロイすることができるようになっています。fabricは基本的にsshで各サーバに入ってmakeをつかうために使っています。敢えてssh hoge.server "make -C /path/to/app install"などではなくfabricを利用しているのは、botoとの組み合わせにより、特定条件によって複数サーバの名前を引いてくるのに便利だからです。

便利になるところにJenkinsを使い、必須であるところにJenkinsを使わない

運用してきた上での所感ですが、やはりどうもJenkinsに色々な処理をやらせようというのはよくないのではないかと思ったわけです。

変化としてはアプリケーションポータビリティを強く意識し始めたというのがあります。僕のところのアプリケーションラインはいくつかありますが、どの環境であっても、全てmake installでセットアップが完了しますし、make testでテストが走るようになっています。当然これはその先のデプロイしやすさというところにもつながっており、この1年でかなり改善された部分です。

結局のところ、Jenkinsが落ちてもデプロイもできるし、テストもできるし、バッチも正常に動く環境が整いました。Jenkinsは確かに便利です。ビルドパイプラインでフローがわかりやすくなります。crontabのようなジョブ設定も簡単です。パラメータを付けてビルドすることも柔軟にできます。rbenvをいれて様々なバージョンで柔軟にビルドを行うこともできます。でも果たしてJenkinsがないとできないことでしょうか？そして本当に必要でしょうか。そうではなく、便利になるから、よりベターになるから、そういう点において活躍できるのがJenkinsであるべきだと思っています。

本当に我々に必要だったのはJenkinsだったのだろうかという考え

最近では少し、Jenkinsが提供してくれているものは僕らにとってリッチすぎるのではないかと感じるのです。最小のツールを組み合わせてレバを効かせていくエンジニアリングとは少し離れているものを感じます。なので本当に必要な物は何なのだろうかと最近考えていました。なんというか、もっとJenkinsはカジュアルで良いのではないかと思っています。

アプリケーションがポータブルになる昨今の環境において求められるのは以下のものなのではないでしょうか。

  • アプリケーションのビルドは簡単にできるのだから、任意のビルドコマンドが簡単に設定できれば良い
    • デプロイした成果物が任意の場所に配置できれば良い
  • ジョブの設定はシンプルにCLIでできると良い。
    • そもそも任意のシェルを実行するだけの設定が多いので、単純にそれをジョブに設定出来るだけで大分スムーズに運用できるのではないか
    • シンプルにジョブについて記述できる書式が必要なのではないか
  • ジョブのシーケンスについても画面からではなく、CLIからスムーズに設定できれば良い
  • テストは通常通り回せると良い
    • アプリケーションは環境に依存しないテストを組み立てられている

CircleCIやTravisCIもそうですが、デプロイメントとテストというのは異なるタスクですし、やはりそこを混ぜてしまうと複雑になってしまうのではないかと思います。今、Dockerをアプリケーションのテストする際に利用できないかと考えていて、そうすると当然デプロイメントもDockerコンテナごと行なうことも見越すわけですが、それらの背景には当然アプリケーションがポータブルになっていることというのが前提になっています。そういう環境下では、テストとデプロイメントが別々のサービスで行われていても、全く問題ない状態になっているというのがそもそもの前提になります。なので、今もう一度、Jenkinsのあり方、Jenkinsに何を任せるべきかということを考えているところです。

Jenkinsは多様なことに対応できるプロダクトではありますが、サービスやアプリケーションの設計が移り変わることによって、またCIのレイヤーというのも再設計が必要なのではないかと感じています。

まとめ

  • Jenkinsには相変わらず幅広く任せているが、Jenkins本体でしかできないことをほとんど無くしました
  • アプリケーションのポータビリティが上がることによって、Jenkinsですべきこととすべきでないことを今一度区別する時期に来ていると感じています

この記事はJenkins CI Advent Calendar 2013 - Qiita [キータ]の17日目の記事でした。

明日はmorodomi - Qiita [キータ]さんです。