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

勉強会 継続的デリバリー


(写真：先日の上場を受け、各所から届いた花々。)


Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))

先日、洋書『Continuous Delivery』の和訳本に当たる『継続的デリバリー』が発売されましたが、この書籍は昨今のアジャイル・スクラム関連の書籍同様各地で反響を呼び、Amazonに於いても人気の状態となっておるようです。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

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

発売を記念して、国内でも幾つか読書会が立ち上がり開催を行うという事なので、この日参加して来ました！



今回参加した会場はAteam｜株式会社エイチーム＠名古屋。


…名古屋？



そうです。今回は初の関東以外での勉強会初参戦と言うのも兼ねていました。

当初この名古屋での読書会が立ち上がった際に『参加しようぜ！』と登録に名乗りを上げた参加者の中の関東勢メンバー数人で誘い合い、4/20(金)夜に来るまで都内を出発→朝方名古屋に到着→軽く仮眠を取りこの日の勉強会に合流、というツアーを組み、名古屋入りしてきた、という訳です。参加メンバーは以下のメンバー3人＋私を含めた計4人。

夜1時前に東名高速東京I.Cを出発→途中休憩を数回挟み朝方8時前に名古屋駅周辺に到着。走行時間的には4〜5時間と言った所でしょうか。仮眠後、昼飯を主催者のきょん＠うさみみモード(TwitterID:@kyon_mm)＆九州佐賀の地から深夜バスで参戦の這い寄れ！なかやん・ゆーき(TwitterID:@pocketberserker)両名と合流し、きしめんを食った後に会場入り。



開催前に一度ビル内のコンビニに立ち寄った所、強烈に目を引くオブジェクトを発見したので写真に収めておきました。:-)
[:W400]

読書会本編


主催者@kyon_mmくんの自己紹介＆会場説明、アイスブレイクの後に参加者全員による輪読形式で読書会スタート。ちなみに今回の読書対象範囲は第1部の以下の2章。

第1章　ソフトウェアデリバリーの問題
第2章　構成管理

そして、同じテーブルに座りディスカッションを共に行った方々は以下の御三方でした。ありがとうございました！


※参加者全員座席表は以下参照。

この座席表、参加にあたり事前にネタは用意しておいたのですが何かと情報を用意しておくのは面倒だったりします。この辺りをこの形式の座席表シートの発案者であるおれんじクローバー (TwitterID:@orange_clover)さんとお話していたところ、以下のような素晴らしいスクリプトを作成してくださいました。人数が増えると何気に時間を取られてしまう作業なので、これは助かります。ありがとごうございました！皆さんも是非、参加された勉強会の座席表を作成し、参加者の交流に役立ててみてはいかがでしょうか。その際には是非ご利用頂ければと思います。


本編の進行は輪読→テーブルでディスカッション→議論内容まとめを発表、を2章分実施。以下はその際のメモです。(※前日移動での不眠もあり若干メモが曖昧かも知れませんが御容赦ください^^;)

  • 書籍『継続的デリバリー』発刊にあたり
    • 書籍冒頭のレビュアー陣などによる賛辞：
      • "きょん"の名前記述：和智さん『本名を出した所で誰だか分からないだろう』
      • 本人による本人賛辞コメントの朗読


第1章：ソフトウェアデリバリーの問題
  • 今あるリリースしているものをより良くしていくにはどうするか？
    • 今やれる範囲で出来る事をやる
      • デプロイの自動化はまだ簡単
      • テスト…ここは難しい？ある程度手動でやらなければならない所はある
      • ボトルネックを探し出す事が大事。
    • チェックリストを洗い出す
      • リスト項目を洗い出した後はスクリプトなどで自動化し、消化して行く
    • 問題を洗い出して見ないと、発見出来ない。
      • 何が問題なのかを洗い出すために学ばなければ...
    • プレッシャーを感じるのは嫌である。
      • 数ヶ月に1度のタスクでも、自働化したい。
    • やって楽しそうなところだけでも潰していく。
    • (ビルド職人が居ないと)進められない、という事態は避けたい。
      • 自動化する事で何を得られるのか、という事が大事。
  • ディスカッション内容の発表：第1章
    • 対抗勢力が出て来たときにどうするか？という所について質問。
      • リリース回数が少ない時（が分かっている場合）はコスト見合いとする？継続的デリバリーをやるのか？
      • リリースの回数が少ない＝コストが高い？コストを低くすればリリース回数も増え、改善されるのでは？
    • コンパイラはバージョン管理しない？
      • 設定ファイル系を管理対象に含める／含めない分岐点はどこ？境界を何処に持って行く？
      • 自分達が生産しないコードは管理しない。※コンパイラは管理しない。コンパイラが対象とするコードを管理する。
    • ビルド職人の話
      • ビルド職人の仕事を奪う？
      • 共通的な知識なら共有すべき？
      • 針の穴を通す作業なら、それを研ぎ澄ますようにサポートしていくのも
      • チーム毎に平準化すべき点と、特化した仕事をやれるように集中しよう。
    • 何を自動化すべきか
      • 何をまっさきに自動化しますか？
      • (質問)まっさらな環境だったらどうする？1から作れるのなら。
        • めんどくさいな〜と思う所からで良いんじゃ無いか？
        • スクリプトで環境一式を自動作成。
        • まっさらからなら、単体テストを自動化したい。
    • バージョン管理に入れるものは何か？
      • 連携可能な状況にしておいて、実行時はローカルのものを利用
      • 全てをバージョン管理：前提条件によって話しが変わってくる？
        • テスト実行時：MSが遂行
        • 初期状態を管理：chefが遂行
      • 実行環境の再現、どこまでバージョン管理に入れるべきか？
    • アンチパターンについて
      • WF的なスケジューリング
      • リリースリハーサルについて…実施することでリソースが足りなくなる。
      • そもそもスキルが不足している現状がある。
      • 直前にならないとやる気が出ない･･など。
        • アジャイルvsWF：スプリントが絡む問題では。WFだと後回しになりがち。
        • 人材流動性に乗っかるか、1〜2年掛けて改善して行くか。
    • WFで継続的デリバリーを遂行：ドキュメントベースになってしまう。動くドキュメントを書かざるを得なくなる（＝無理）
      • 継続的デリバリーにならない
      • →TDDやれば良いんだよ。
    • リリースに関するアンチパターン
      • 関係性を上手く作るには…360度に対して信頼貯金を作る。
    • まともなシステム程、長期間利用されていく。
      • その点を考慮すると、デプロイ回数＝物凄い回数になる。自動化しないという選択肢は有り得ない。
      • デプロイ・テストはリリース後も永遠に続くという事を理解して欲しい。
      • ビルド職人なりがそのスキルを評価して貰えるような組織のサポートも必要。



休憩：スイーツタイム

都内横浜からの参戦時に購入していったお土産お菓子を含めたスイーツ各種でおもてなし。

第2章：構成管理
  • ディスカッション内容の発表：第2章
    • バージョン管理、何を使っているか？業務／趣味
      • 環境依存ファイルの管理、どうしているの？スクリプト管理などなど…
      • 来てる方、開発者が多い。
      • ※インフラ側の人、ファイルをどうしている？
      • 集計内訳…svn:4、tfs:1、git:6、vss:2、hg:2。
    • "OLさん的"テストエンジニアへのDVCS的教育について
    • 意味のあるコミットメッセージとは？
      • チケット内容を書く：DRYじゃ無くなる
      • →DRYじゃなきゃ行けない必要性は？きょん君：『話すと5時間位になるので…』
      • コミット粒度は開発と依存する/タスクとは関連しなくても、ユーザストーリーと結び付くとか、意味のある単位で結び付ければ良いのでは？
    • 残すべきコミットメッセ−ジとは何か？
    • コミットの粒度は予め方針を決めておく
    • 参加者への問い掛け『構成管理を考えた上で、コミットの粒度はどうされますか？』
    • 完全なるレプリカ：OSのバージョン会ってればいいのか、メモリの状態まで、アプリケーションの内容まで見るのか？
      • ユーザ不在の過剰な構成管理（分析麻痺）
        • マージの話し：テストのマージは？
    • 構成管理
      • トランザクションデータ以外のデータ（初期データ、テストデータ）
      • 依存関係、特定のバージョンの外部ファイルを取得するコードを管理



本編終了間際には、同じく名古屋で開催されていた『TAPL-nagoya 勉強会』の方々が会場に合流。

そして早くも第2回開催決定！開催予定日は2012/05/20(日)。

各種こくち業が成された後は、速やかに撤収。一同懇親会へと移動。


懇親会

名古屋駅(こちらでは『名駅(めいえき)』と言うんですね。)に程近い居酒屋『なにがし』にて懇親会実施。

懇親会では所謂『なごやこわい』と称されているな方々の"華麗なる空中戦"を目の当たりに出来、非常に貴重な体験となりました。高度な技術論議、突如放り込まれる無茶振り、それを受けて立つ人…。

ハイライトとなった場面については、『受けて立った』人が自らブログに起こしております。間近で見てたけど、どっちもすごかったです。いや、どっちもと言うより、参加された皆様方全員かな。話しの内容を伺い、何とかしてついて行くのが精一杯。向上心・探求心等、見習うべき所は本当に多いなぁ〜とレベルの高さに驚きながら思うのでした。


読書会本編及び懇親会に参加された皆様方、どうもありがとうございました！


翌日(4/22)に開催されるSCMBC in Nagoyaのスケジュールの都合もあり、懇親会は9時を過ぎた辺りでお開きに。我々都内遠征組も一同名古屋駅から徒歩でホテルに向かい、SCMBC(遠征組みは4人全員参加)に向けてしばしの休息を取ったのでした…。


その他関連：