サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

ソフトウェア開発 改善 旧館より

Jenkinsさんと気軽に友達になってみませんか?

投稿日:2011年12月6日 更新日:


今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員・・・と言うほど、色々なことをしてもらっています。

使い始めるのは簡単だけど…

一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな!」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。

そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。

まずは軽く使い始める

そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは?」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

「構成管理からチェックアウトしてコンパイルエラーが出ないか?」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。

これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが・・・」なんて指摘はしなくて済みます。

静的チェックの次は…

JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど・・・」という状況も少なくなります。

そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

そして自動テストへ…

ここまで来ると「テストの結果も見えると良いよね?」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100%じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。

簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか?

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

-ソフトウェア開発, 改善, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

雛形やテンプレートは現場の役に立って「ナンボ」

ある程度の組織にはPMO(プロジェクト・マネジメント・オフィス)や「品質標準化グループ」のような部署があり「設計書のフォーマットはこういうのを使ってください~」「レビューではこのチェックリストに沿って …

マルチスレッド

仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 …

「モチベーションの源泉:何のために働くのか、転職か起業か」を読んでみて

@kuranukiさんの「モチベーションの源泉:何のために働くのか、転職か起業か」(「Social Change!」より)を読んで… 「サポータータイプ」:7「クラフトマンタイプ」:3かな、私は。RT …

ホワイトボードを使わない会議はあり得ない

色々な意味でカルチャーショックなプロジェクトの話です。 お客様との打合せ…議題は複雑で、図解をしたりして、何らかの「見える化」などの対策をしないとアッと言う間に「空中戦」になること必至のものでした。 …

社内研修で思うこと

社内研修における受講者、講師について思ったことです。 社内研修には(自分から手を挙げる以外に)「3年目だから」や「主任だから」というキャリアによって必須のもの、また部長などが推薦するものがります。 い …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。