IT現場における「新3種の神器」とも呼ばれるようになった「Jenkins」を、私も使いこなしてみたいと思っていました。
私の身近なところで、Jenkinsを使って効率化したいと思うシステムは、少々古くなったWebアプリケーションで、手動での独自運用手順が確立されているようなシステムです。デプロイも手動で行います。
このようなシステムは、運用者が長年かけて工夫し、頑張っていて、それなりに安定稼働の実績を積み上げていたりします。
苦労して積み上げてきた実績があるので、運用を変えることは難しかったりします。
もし、既存の運用を変えずに、運用者が頑張らなくても、誰でも、簡単に自動デプロイできたら、いいな～なんて思い、実現方法を考えてみました。
対象とするシステム
次のようなWebアプリケーション、環境、運用方法のシステムに対して、自動デプロイを検討します。
Webアプリケーション
- Java 1.4（JSP/Servlet）
- 画像ファイルあり（環境に依存するファイル、依存しないファイルあり）
- 設定ファイルあり（環境に依存するファイル、依存しないファイルあり）
環境
- 開発環境：Windows、Eclipse
- テスト環境：Linux/Unix、Tomcat4.1
- ソース管理：Subversion
デプロイに関する特殊運用
- Eclipseでビルドする。build.xmlなし。既存ソース管理に、build.xmlなどのビルド用のファイルは含めたくない。
- WAR/EARを使わず、JSPやclassファイルを変更のあったファイルだけ、FTPで配布する。
- Webアプリケーションの設定ファイルについて、テスト環境用の設定値は、テスト環境で直接編集する。バージョン管理されていない。
自動デプロイの課題
上記システムを自動デプロイするうえで、難しいのは、「特殊運用」の扱いで、次のような課題があると思いました。
- ビルド用ファイルの管理方法を検討する。
- JSP/classファイル単位で配布するため、JenkinsのDeploy war/ear Pluginがつかえない。このプラグインを使えれば、ファイルの配布と、Tomcat再起動を簡単に行えるのに、別途方法を考えなければならない。
- テスト環境で直接編集している設定ファイルは、デプロイ元の環境に存在しないので、どうしたら良い？
解決案
上記課題について、自分なりに解決案を考えてみました。（ただし、この解決案は、正しくないとこととして理解しています。正しくは、自動デプロイしやすいように運用を見直すことだと思います。）
- ビルド用ファイルは、開発環境のローカルディスクに、Subversionリポジトリを作成して管理することにする。
- ファイルの配布は、AntのFTPタスクを使用する。FTPはJenkinsのプラグインでも可能で便利ですが、今回は、試行錯誤ビルド・デプロイを繰り返すことになるため、コマンドラインからも実行できたほうが便利だと思い、Antを使うことにします。
- 変更のあったファイルのみを配布するには、独自スクリプトを作成して対応する。
- Tomcatの再起動は、TomcatのAntタスクを使う。
- テスト環境で直接編集している設定ファイルは、自動デプロイをあきらめる。（本当は、運用を変えて、テスト環境で直接編集することは止めるべきだと思います。）
上記解決案について、サンプルWebアプリケーションを用意して、実現可能であることを確認済みです。
今後、気が向けば、解決案を実践してみた内容を具体的に、記述したいと思います。