Challenge Engineer Life !

エンジニア人生を楽しみたい!仕事や趣味で学んだ技術的なことを書いていくブログです。

JenkinsとJava EE6で取り組んだ初めてのCI

前の開発では、それなりに大規模な開発だったにもかかわらず、構成管理や試験が全て人間ベースで行われていました。

従って当然のようにミスは起きるし、終いには

「あの人がいないとビルドできない!」

とか

「ここの試験はあの人にお願いしないと」

みたいな状況が続きました(実は今も…)

運用が安定すると人も減らさなければならなくなり「引継ぎ」というマジカルワードの嵐が起き、メタメタなコードもドンドンと任されます。

でも自動テストもないので、引き継いだ立場の人間は改造で苦労の連続…自分自身、デグレスパイラルを何度も経験しました(-_-;

で問題が発生すれば、当然、担当した自分がお客様から色々言われるわけです。
過去に設計した人や開発した人達はどこへやら…。

そんなプロジェクトが自分自身の初参加プロジェクトだったのですが、この経験から運用系システムにおける品質の重要性を身を持って学んだ気がします。

運用システムは開発自体も大変ですが、いかんせん動いてからが始まりで、安定するのもつかの間、多々発生する改造への迅速な適応が求められます。

なので心の底から

全てを手でやるのは本当にありえない!

というわけで、去年Java EE6を始めて触るのを機に+自分がアーキテクチャを任せて頂ける機会を得て、世間一般で行われている自動化の取り組みを少しずつ入れていき、現状は以下のようになりました。

  • Jenkinsを中心にビルドやモジュール管理を自動化
  • Jenkinsでリグレッション的に自動試験を日々実行
    • 単体試験は主にJUnit(+Mockito)
    • 単体では難しい試験はArquillian
    • DBも伴った試験はArquillian Persistence Extension
  • 自動ビルドで生成されたモジュールを自動で試験環境へデプロイ
  • 自動ビルド結果は関係者へ自動メールでリターン

f:id:kikutaro777:20130426220741j:plain

今のプロジェクトがこの状態なのですが、やはり安心感が違う気がします。

なんで前の大規模プロジェクトでこういうことを最初に考える人がいなかったのか…今思うと不思議です。

こういう取り組みをしたことがどこで伝わったかわかりませんが、社内の全く関係のない部署の方からJenkinsについて教えて欲しい、などの問い合わせがきたりもして、少しずつ社内に浸透すれば嬉しいなぁと思う今日この頃。

でも世間ではもっともっとすごいことをやっている人だらけなので、勉強を続けていかねば。
まずは第一歩進めたかなぁ、という感じです。

そんなこんなでJenkinsとJavaには、色々とありがとうございます、という気持ちが大きいです。

にほんブログ村 IT技術ブログへ
にほんブログ村 にほんブログ村 IT技術ブログ Javaへ
にほんブログ村