secretbase.log

.NET/C#/Pythonなど

継続的デリバリー読書会に参加してきました #CDstudy

4/21(土) に、当日名古屋入りして、継続的デリバリーの読書会(1章、2章)に参加してきました。

  1. "こくちーず"
  2. "Togetter"
  3. "座席表"

全員で節をパラグラフ毎に輪読するスタイルで行いました。輪読後、各テーブルで、テーマをとりあげて議論を行った。私のテーブルは、@ さん, @ さん の3名のテーブルです。

f:id:cointoss1973:20120425113117p:image



継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

1章(ソフトウェアデリバリーの問題)から取り上げたテーマ

  • 何を自動化すべきか?(どこから自動化すべきか)
  • バージョン管理に入れるべきものは?

2章(構成管理)から取り上げたテーマ

  • コミットメッセージの記述すべき内容とは?
何を自動化すべきか

本書では、「可能なかぎりほとんどすべてを自動化する」 とある。
では、どこから着手すべきだろうか。もしなにか新しい環境でプロジェクトを始める場合、どこから手をつけるべきであろうか。ここも意見が別れた。

  • ビルドから自動化に手をつけたらいいのでは?
  • ユニットテストから自動化に手を付けたらいいのでは?

他のテーブルの参加者からは、「面倒なところからやればいいのでは?」 という適切な意見もあった。

Jenkins関連の勉強会でも、同じような話題があり、ユニットテストからやるのは大変だから、ビルド+静的検査からやるといいのではという考えは良かった。
大変なところからやる。少しずつ導入できるところからやる。どちらも正しいと思う。

バージョン管理に入れるべきものは

「すべてバージョン管理に入れよ」 を、そのまま受け止めると、OSのバイナリ自体も入れるのだろうか?
現実的ではないのではという感想があった。OS自体を入れることは現実的ではないが、それを再現できる情報(バージョンやパッチファイル、構成ファイル)は管理すべきであるという結論に達した(当日は読み落としていたが、"2.5 環境を管理する"にしっかりと書いてあった...)

コミットメッセージの記述すべき内容とは?

 まず前提条件として、タスクとコミットの粒度は同じであるか、そうでないか、というところで議論が別れた。(ここでいうタスクはストーリーを分割したあとのひとつの作業単位)
このあたりは思うことがあるので別のエントリとしてまとめておきたいところ。

最後に

 主催の @ さん、いつもありがとう。きしめんも美味しかったです。意識して自分の意見を発する機会を多くしたが、まとまってない感じになってしまうことが多かった。もっとちゃんと読み込んで事前準備が必要ですね。次回は新宿で開催される 継続的デリバリー座談会 in 新宿#2 に参加することになりますが、対象の章を読んでいままで実践してきた内容を振り返っておきたいと思います。