今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員･･･と言うほど、色々なことをしてもらっています。
使い始めるのは簡単だけど…
一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな！」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。
そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。
まずは軽く使い始める
そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは？」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。
「構成管理からチェックアウトしてコンパイルエラーが出ないか？」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。
次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。
これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが･･･」なんて指摘はしなくて済みます。
静的チェックの次は…
JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。
これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど･･･」という状況も少なくなります。
そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。
そして自動テストへ…
ここまで来ると「テストの結果も見えると良いよね？」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100％じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。
使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。
簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。
ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか？
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
コメント