-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinsapporo20120522
irasally edited this page May 22, 2012
·
12 revisions
- http://atnd.org/events/28899
- 2012年05月22日 19:30-21:00
- エスプランニング開発室
- 参加者 7人
- 第15章 15.1 - 15.7
- シナリオ1って、継続的インテグレーション以前の問題じゃぁ？
- コミット頻度の問題も含まれているね
- 今、毎月のようにリリースのあるチームにいる
- 機能開発には数ヶ月かかる場合もある => 複数のブランチができる
- ブランチのバリエーションが山のようになってきて大変だった
- そういう場合の管理はブランチ運用だと大変だなあと思った（ブランチが枝ではなくなってくる）
- メインブランチで動いたものがリリースブランチで動かないなんてことが起きた
- 継続的インテグレーションのあるプロジェクトにいた事のある人 -> 少数
- どこまでを（何を）継続的インテグレーションというのかな？
- テスト、コンパイル、ビルド、デプロイかなぁ
- 定義は明示されてはいないね
- Jenkinsだけではなく、コミットをフックするスクリプトで同じ事をしていたこともあったよね
- Mavenの独自プラグインとかでも実現していた事があったよ
- どこまでを（何を）継続的インテグレーションというのかな？
- Jenkinsは導入や利用が難しそう
- 導入は今はそこまで難しくないないよ
- 利用もWebから設定できるから敷居は高くない
- 言語によっては対応があまりされていなかったりする
- チームで継続的インテグレーションを導入することになったきっかけって？
- プロジェクトの途中で必要になって作った
- だんだんモジュールが増えていって、工夫するうちに導入されていくことになった
- リリース頻度が高くなって、必要に迫られて
- 本番環境へのリリース時に人為的なミスがあったことをきっかけとして
- 仕組みでなんとかしよう ⇔ 手順書を強化しましょう（どちらに転ぶかは分かれ道だよね）
- 初めから環境が用意されていたという（幸せな）状況もあったよ
- プロジェクトの途中で必要になって作った
- 「CI入れよう」という人がいて、CIを導入する技術を持つ人がいれば意外と導入の敷居は低いのかも
- 事後報告しやすいところ
- テストなどに比べて開発者の時間を奪わない
- 人間（開発者）のタスク、プロセスは変わらない、その先にCI環境ができるだけ
- 全員に目に見える結果が出る
- 実際に導入した人もCIから導入するのが一番良いと話をしていた
- 本などを通して「製品じゃないところでコードを書くこと、良い環境にするため工夫する事が大事」だという文化に気がつけたのがよかった
- 実際に周りに仲間がいるともっといいよね
- 上司などに新しいプラクティスの導入を説明して納得してもらう方法
- 「テスト」というキーワードを入れてしまうと「単体テストを書きたい」という希望をなかなか理解してもらえなかった
- 「コードの質を高めたい」という同じ目的のはずなのに...
- 説明を続けたら、最後は「コードの質を高めるために単体テストを書く」ということを理解してもらえた（メールをn時間やりとり！）
- 数字で説明出来れば説得しやすそう
- それが出来ればよいのだけどねぇ....
- メトリクスとかカバレッジとかで数字を示すことができる
- 長期的な傾向を見るのも大事だよね、相対的に数字を使うのはよいかも
- 数字がひとり歩きするのは危険（特にカバレッジ）だよね
- 最終的に「良いコードだったのかどうか」という指針は必要だよね
- お客さんにとっても価値を提供する「良いコード」ではなければいけないね
- 「テスト」というキーワードを入れてしまうと「単体テストを書きたい」という希望をなかなか理解してもらえなかった
- この本に書いてあるように無駄を省いてシンプルにプロジェクトを進める事も大切だけど、無駄だよねと思っている中にお客さんが大事だと思っていることがあるんだよね
- プロジェクトの文化によって重要度が違うということは覚えておかないといけない
- 「これって無駄じゃない？」という判断は開発者がしてはいけないよね、お客さんに聞くところからはじまると思う
- やり方を理解しあわないで押し付ける事が奨励されているわけではないよね
- ビルド時間
- 例えばレポートは1日1回にする、内容によってテスト頻度を変える（毎コミット時にテストするものは絞る）
- CookpadさんがRuby札幌の勉強会に来た時にCIのビルド時間短縮についても話をしていた記憶があるよ（質疑応答だったかなあ） -> http://www.slideshare.net/hotchpotch/ruby18
- 悲観的ロックモデルは使ってはいけない
- その通り、本当にその通り
- VSS（デフォルトで悲観的ロック）とか、SVNで全てのファイルにロックかけるとかの経験があります
- 悲観的ロックモデルは本当にコードベースを共有しなくなるよ
- ビルドを壊す人がいるからという理由で導入された事がある
- ロック解除の監視とか本来のバージョン管理システムの目的から外れていく・・・（マージをするのが悪という文化）
- oh...
- 「ファイルをロックしたい」は共有サーバーでソースをいじっている感覚の延長線上だよね...
- そう考えれば「ロックされている」ことはありがたいのだろうけれども...
- 4番目の手順（マージ）が結構大変
- コンフリクトした場合どうしている？
- どっちの責任でマージする？マージしようとしている人の責任になる？
- わからなかったら書いた人に聞くよ
- コードの文脈が違っていたら確認しないと不安だよねぇ
- ビルドをだいじに
- 失敗するテストをコメントアウトするってやったことあるよね
- テストが悪かったらそのテストは作りなおせば良い
- リファクタリングテストを作るのが正しい方法だね
- バイナリファイルの管理は大変（ドキュメント類）
- バージョン管理を手軽にできるのはソースコードがテキストファイルだからだよねぇ
- Office系の差分を見ることができるツールもあるよ
- DB変更の管理をどうしていくのがよいか
- フレームワークに依存しないDB変更マージツールもある
- dbdeploy http://dbdeploy.com/
- railsのマイグレーションはよくできているよね（昔のバージョンだとコンフリクトすると結構大変なこともあるけど）
- フレームワークに依存しないDB変更マージツールもある
- リポジトリ管理を全くしていなくても数十年続いているプロジェクトも実際にある
- 綱渡りだなあ・・・
- 神様ばっかりいる集団のようだ
- そういう世界もあるんだね
- 10年続くプロジェクトであったならば継続的インテグレーションとか採用するかなあ
- 大きくなってきたら、後から変更することができないよね。不安だ
- でも何も導入しないのではなく、現状で最善の方法を採択するのが良いのではないかな
- 必要に応じて段階段階でテコ入れしてプロジェクトを育てる感じになるのかなあ
- Jenkinsのことだね
- 実行はコミット単位？
- そうなるよね -> だからビルドの実行時間が大事
- 分散バージョン管理システムだとpushした単位になるよね
- サーバーでのビルドの自動化はブームが過ぎた感がある、今はローカル環境でのビルド自動化が盛り上がっている
- 分散バージョン管理システムだとローカルにコミットしたタイミングやコードを保存したタイミングで継続的インテグレーションが実行されてほしいという気持ちが生まれてくる
- ローカルでコードを保存するたびに継続的インテグレーションができる仕組みなどが模索されている
- クリアコードさんのブログでコミットの単位について書かれていて議論がされていた http://www.clear-code.com/blog/2012/3/13.html
- コミットに意味を持たせたいよね
- コミットが乱れているということは、自分の作業進行が乱れているということが多い
- 先にコミットログを考えて作業をすれとよいよ
- チケットとか作業ブランチの切り方を考えるほうが難しい
- ブランチを使ったほうが良いのだね・・・
- 分散だと細かくコミットするようになるよね
- コミットはビルドを壊すかどうかを気にせずにコミットして良い、保存と同じ感覚、セーブポイント
- pushするときにビルドを壊さなければいい
- TDDやBDDと分散バージョン管理システムのコミットはとても相性がよいよ
- なぜ、そんなに細かくコミットする必要があるのか？
- セーブポイントとして戻したい？
- コーディングのリズムを取るため
- 他の人がどういうコードを書いているかをコミットログで知りたい
- ソースコードをチェック・レビューする人は単位が細かい方が嬉しい
- 細かくしたほうが、今何をやっているかを自覚しやすい（意識をつけやすい）
- システムの一部であっても継続的インテグレーションはしたほうがいい
- そうだよなあ
- ローカル環境での継続的インテグレーション
ついにこの台詞まで辿り着いた・・・・！
次回は15.8, 監訳者あとがき - 最終回（予定）！！