まず最初に自動化するということ

新しいプロジェクトが始まったので、色々と自動化を進めています。

現時点での自動化できたこと

・Gradle でビルド・テストを自動化（受け入れテスト自動化は不十分）
・Jenkins で自動化したものを継続的に実行

まだまだ、自動化する領域は広げていきたいと思っています。

受け入れテストを初めに作ってわかったこと

なにから手を着けていいのか、わからなかったです。

クライアントの Java モジュールからサーバの Tomcat で動いている Web アプリケーションに Web サービス経由で、ファイルを送信する。

というストーリーの受け入れテストを自動化しようとしています。
ストーリー視点でみたテストの記述は簡単なものです。

「Web サービスで接続できない場合、エラーとする」
「Web サービスで接続できた場合、OK のステータスが返る」

ところが、実際に作るとなると、
・Java モジュールを jar ファイルにして実行する
・Web サービスの送受信方法を確定させる
・Web サービス受信側の Web アプリケーションをつくる
・作ったアプリを Tomcat にデプロイするのを自動化する

一気に課題があらわになりました。
ちょいちょいと作って、Jenkins で自動的に動くのを見える化できてハッピーみたいな気でいましたが、一気に地獄に突き落とされました。

そういうのをひとつひとつ潰していく。しかも、テストコードを書いて、手順も自動化する。
テストをするために、もしくは自動化するためにと考えると、アーキテクチャもそれらを考慮したものにしなければなりません。単に手間が増えるというレベルではないです。

臭いものにふたをしていた自分

でも従来だと、この辺は後回しにしてたところです。いつかはやらないといけないことです。

サブシステム間連携、Webサービス連携なんて、とりあえずTODOですよね。とりあえず目の前の機能開発を終わらせる、完了数を増やす。

結局、機能単体のことしか考えていなくて、価値の流れやユーザ要求といったことからかけ離れてものづくりしてしまっていたのです。

リスクに目をつぶる、臭いものにふたをする、とりあえず後回し。
いかにそういったことをやってきていたのかを身にしみて感じました。

大変さと効果を再認識

最初に自動化、継続的インテグレーションを整備するのは本当に大変です。やることが山積みになります。
ただしそれは、リスクや作業の山を前に持ってきているということであり、後になればなるほど余計なことを考えなくてよくなります。ひとつひとつに集中できますね。

本にも書いてある

『実践テスト駆動開発』(GOOS)の第４章序論に次のような記述があります。

一番最初に作るフィーチャについてはどうだろう。システムを育てるための基盤ができる前は？受け入れテストは、エンドツーエンドに実行してシステムの外部インターフェースから必要なフィードバックを与えてくれるものでなければならない。これはつまり、ビルドやデプロイ、テストサイクルをすべて自動化しておかなければならないということだ。最初のテストの失敗を確認するだけでも、その前に済ませておかなければならないことがたくさんあるのだ。

ほんと、そのとおりだと思います。痛感しました。

初物だからのしんどさ

今回こんなことをしたのは初めてということで、膨大な時間がかかりました。まだまだ、やることは多いのでもっと時間はかかりそうです。

ただ、やっている中で期待される効果を感じることができていますし、次のプロジェクトからはそれこそ再利用することができます。そういう意味でまだまだ腕まくりして挑戦したいと思います。