DoorKeeper
http://devlove.doorkeeper.jp/events/3438
以下の書籍をターゲットとした読書会なのです。
 | 実践 反復型ソフトウェア開発 (2012/12/01) 津田 義史 商品詳細を見る |
場所は秋葉原のクラスメソッド株式会社さんです。
参加者は10人くらいかな？ディスカッションするにはちょうど良い人数です。
今回は以下が対象範囲でした。
・第4章 構成管理とブランチの戦略
・第5章 再現可能なビルドの実現
以下、読書会でのメモ。
■前回ディスカッションのとある一節について
今回、著者の津田さんが参加してくださいました。感謝！ちなみに前回は残念ながらご欠席。
んで私はというと前回の第１回も参加しまして、ブログにもそん時のメモ書きました。
「実践反復型ソフトウェア開発読書会 -反復1-」に参加しました
http://makopi23.blog.fc2.com/blog-entry-58.html
この前回ブログ、著者の津田さんが読んでくださってたようでした。
拙い殴り書きメモでお恥ずかしい。。。
んでブログの中に書いた、前回のディスカッションで出た以下のフレーズに意義あり！とのこと。
「チャンピオンやドライバに相当する人が自発的に出てこないとマズイ」
前回ブログの、下の方に書いてあるやつですね。
これは前回のディスカッションで結論として挙がったものではありません。
あくまでディスカッションの中で出た話の１つとして私がメモに残してた一節です。
この中の、「自発的に」という表現が書籍の意図と異なるようでした。大体、以下のような趣旨です。
---
「自発的に」という言葉に対しアジャイルでも「自己組織化」という言葉があるが、この意味を誤解している人が多い。
ソフトウェア開発において、
・「ドライバ」は、プロジェクトを前を動かし、チームメンバを勇気づける役割を持ち、
・「チャンピオン」はソフトウェアの品質のある側面を守る人であり、
・「コップ」はツールの運用などについて、ルールをチームに周知して守らせる人、
という位置づけである。
ここで彼らが「自発的に」なんでも個人ベースで行動に移せば良いか、というとそうではなく、チームとして役割を全うする必要がある。
行動する上では、当然チームのリーダーが期待するタスクをこなさなければならないし、やりたくないタスクが上から降ってきたからモチベーションが上がらない、やらない、というのはありえない。
そーいった間違った方向の自己実現を、「自己組織化」として誤解してほしくない。
大事なのは、例えばプロジェクトの初期にリードとエンジニアが１対１で会話して、リードが各エンジニアにアカウンタビリティを与えることも１つ。
チームが期待する役割を果たして成果を出すことが重要であり、そこには当然、統制も求められる。
---
といったような内容について、津田さんが説明してくださいました。（資料が手元にないのでうろ覚えな面あり orz）
このときに使った資料、あとで公開されるかな。。。？
■ディスカッション
以下、ディスカッションの中で出た話の個人的メモ。
■ネタ出し
最初に参加者さん全員で、今日ディスカッションしたいことを書き出しました。
大体、以下のようなネタが挙がりました。
1. 理想と現実のGap
2. CIビルドやってる現場どんなん？
3. ブランチした後メインに戻るコツ
4. バイナリファイルをコミットするかどうか
5. P.98のポートやってます？
6. 4.12節の、ブランチを上手く使うためのプラクティスやってる？
7. 構成管理をやっているロールってチームでは誰？
8. サンドボックスをどういう運用しているか
9. P.73の4.5節の、コミットの手順を唱和する
10. P.128のビルドの手順を唱和する
11. 津田さんコーナー
12. P.108で、みなさんの現場でどんなブランチの切り方をしているか
13. コミットベルやってるか
14. コミットの頻度
15. ルールの運用をどうやっているか。
こっから、１つずつ取り上げて話し合っていくことになりました。
---
■現場で使ってる構成管理ツールについて
参加者さんの自己紹介タイムで、現場で使ってる構成管理ツールも合わせて紹介することになりました。
その中で私が知らなかったものとして、以下が挙がりました。
(1) Perforce
・http://www.toyo.co.jp/ss/perforce/
・東洋テクニカさんがサポートしている有償の構成管理ツールらしい。
・Tortoise系のようなエクスプローラ融合型ではなく、クライアントアプリケーションらしい。
・安定している。
・スケールしやすい
(2) Stash
・http://www.atlassian.com/ja/software/stash/overview
・JIRAなど、アジャイル開発系のツールベンダとして有名なAtlassian社の製品。Gitベース。
(3) SourceRepo
・http://sourcerepo.com/
■今の構成管理ツールをなぜえらんだのか？
・構成管理ツールはインフラ。一度入れると、乗り換えるのが難しい。
・会社の他の部署やプロジェクトで使ってたりすると、リポジトリごと貰えたりとかもできるし。
・GitとかMarcurialは比較的新しいので、SVNとか使ってる人は乗り換える理由がないのでは。
・無理に新しい構成管理ツールを入れる必要はないのでは。それでコストかかってしまえば意味ないし。
■Perfoceをどういう理由で選んだか？
・C/Sで使える。
・VSSよりは安定している。
・変なことも起きない。
・ブランチも簡単にできる。
・PerfoceとRational ClearCaseが候補にあがって、値段の面でPerfoceを選択した。
・Perfoceは1995年に発売された古参の構成管理ツール。当時、ブランチ開発はPerfoceしかできなかった。
・書籍のP.94の3行目にPerfoceが出てくる。エンジニア4人が有名なWeb記事を書いている。
・そのうちの2人が構成管理の話を書いている。
■コミットの頻度について
(1) 書籍ベースのお話
・「頻繁にコミットしましょう」というプラクティスを書籍で紹介しているが、誤解を招くと思っている。
・大事なのは頻度じゃなくて一貫性のあるコミット。
・例えば、コミットは１週間に１回でもいい。バグが入らなければ。
・コミットしてからCIでバグを出すんだ、という思想は間違い。
・そうじゃなく、「頻繁な更新」が大事。衝突を減らすことができる。
・「更新」に精神的負担を感じるのは、「更新」が悪いのではなく、「コミット」が悪い。
・更新は頻繁に、コミットは丁寧に。
・意味のある単位でコミットすべき。
・書籍の4章の手続きに沿って、丁寧にやっていただければ、と思っている。
・テストを通したからコミット、ではなく、タスクが終わった時にコミットする感じ。
(2) TDDの観点
・TDDだと、テストが通ったらコミット、次にりファクタリングして、またコミットとなる。
・そのループが細かく回る。なので、コミット回数が多くなる。
・ユニットテストで、自分の環境で緑になることを確認してからコミットをする。
(3) コミットの履歴
・コミットが多いと、コミットの履歴を辿るのが大変では？
・いや、そんなことはない。
・というのは、コミットが頻繁な方が、前回の成功コミットから今回の失敗コミットまでの間の変更が少ないので。
(4) その他
・自分のローカル環境なら、頻繁にコミットして構わない。
・作業履歴を残したいからコミットしたい、という考えは良くない。
・バグがない、ちゃんとしたものをリポジトリに入れるべき。履歴を残すためでは無い。
・頻繁にコミットせよ、という言葉は初心者向けな面がある。大事なのは(1)。
・バグ管理票がないとコミットしちゃいけないと徹底されていた、という経験談あり。
■リリース管理をどうやっているか？
・リリースでミスることが多い。手動でやる人はどうやっているか？
・ソースを直した人がコミットまでする、というプロジェクト経験談あり。
→ それって、怖いよね。。。という感想多数。
・チェックアウト時にロックをかける構成管理の仕組みを用いれば、基本的に競合は起きない。
→ この書籍ではブランチフリーズと呼んでいるが、推奨していない。
■構成管理をやってるロールって、チームでは誰？
・大きいプロジェクトだと、専任で構成管理担当チームがいた。
→ 24時間体制でコミット申請を受け付け、確認や複数環境への反映などを行う。
■コミットベル使ってる？
・参加者は誰も使ってない。
・コミットベルで知らせると、コンフリクトは基本的に無くせる。
・ベルじゃなくて、コミットをトリガーにメールを飛ばすくらいなら、やろうと思えばCIサーバでですぐできる。
■サンドボックスってどんなの？
・ここでいうサンドボックスとは、ブランチと対応する作業場所としてのフォルダのこと。
・仮想環境とは限らない。
■理想と現実のGap
・新しい人がプロジェクトに入ってきた人のために、構成管理の用語辞書だけでなくサンドボックスの構築手順とかをWikiに書くのが良いのでは？
・構成管理のルールはリードやマネージャが都度、メールで共有したりするのが良いのでは。
・CIでテストがこける部分を赤で放っておくよりは、そこをコメントアウトして緑にしたほうが良い。
・コメントアウトしたら、そのテストを直すチケットを別に切る。
・コミットをして、結果を確認せずに帰宅して、ビルドがコケて大変になったことがあった。
→ そのようなやり逃げの混乱を防ぐのに、バディビルドがお勧め。
★感想：
今回、予習で4章と5章を読んできたのですが、構成管理の手順とブランチの運用方法がとてもよく纏まっていて、しかも私が欲していた情報にピンポイントでマッチしてて、ちょとビビった。
というのも今ちょうど、構成管理の運用でチーム共々ちょとハマっていて、コミットは長期間されないわ、コンフクリクトを無視してむりやりコミットするわ、ゴミファイルやゴミディレクトリが大量にあるわの状態で。。。。
んで、お手本となる良い手順がどこかにないかなぁ、と悩んでいたところなのでした。
この4章、チームに配布して唱和したいくらいだわ。
あと、私はこれまで受託開発のプロジェクトがメインだったので、ブランチをバリバリ使っているところを見たことがありませんでした。
そーゆう意味でも、今回のブランチ戦略の章は大変勉強になった。
ちょと今日のために最後の方、急ぎ読みしたところもあるので、読み返してみようと思います。
最後に主催のpapanndaさん、uejunさん、著者の津田さん、参加者のみなさんありがとうございました。
