Skip to content

Readingagilesamuraiinsapporo20120522

Jump to bottom Edit New page
irasally edited this page May 22, 2012 · 12 revisions

第21回読書会

第15章 継続的インテグレーション：リリースに備える

15.1 ショータイム

15.2 リリースに備える文化

  • シナリオ1って、継続的インテグレーション以前の問題じゃぁ？
    • コミット頻度の問題も含まれているね
  • 今、毎月のようにリリースのあるチームにいる
    • 機能開発には数ヶ月かかる場合もある => 複数のブランチができる
    • ブランチのバリエーションが山のようになってきて大変だった
    • そういう場合の管理はブランチ運用だと大変だなあと思った（ブランチが枝ではなくなってくる）
      • メインブランチで動いたものがリリースブランチで動かないなんてことが起きた
  • 継続的インテグレーションのあるプロジェクトにいた事のある人 -> 小数
    • どこまでを継続的インテグレーションというのかな？
      • テスト、コンパイル、ビルド、デプロイ
    • Jenkinsだけではなく、コミットのタイミングをフックするスクリプトで同じ事をしていたこともあったよね
    • Mavenの独自プラグインとか
  • Jenkinsは導入や利用が難しそう
    • 導入は今はそこまで難しくないないよ
    • 利用もWebから設定できるから敷居は高くない
    • 言語によっては対応があまりされていなかったりする
  • チームで継続的インテグレーションを導入することになったきっかけって？
    • プロジェクトの途中で必要になって作った
      • だんだんモジュールが増えていって、工夫するうちに導入されていくことになった
    • リリース頻度が高くなって、必要に迫られて
    • 本番環境へのリリース時に人為的なミスがあったことをきっかけとして
      • 仕組みでなんとかしよう ⇔ 手順書を強化しましょう（どちらに転ぶかは分かれ道だよね）
    • 初めから環境が用意されているという（幸せな）環境もあったよ
  • 「入れよう」という人がいて入れることが出来る人がいれば意外と導入の敷居は低いのかも
    • 事後報告しやすいところ
    • テストなどに比べて開発者の時間を奪わない
    • 全員に目に見える結果が出る
    • 実際に導入した人もCIから導入するのが一番良いと話をしていた
  • 本などを通して製品じゃないところでコードを書くことが大事だという文化に気がつけたのがよかった
    • 実際に周りに仲間がいるともっといいよね
  • 上司などに説明して納得してもらう方法
    • 「テスト」というキーワードを入れてしまうと「単体テストを書きたい」という希望をなかなか理解してもらえなかった
      • 「コードの質を高めたい」という同じ目的のはずなのに...
      • 説明を続けたら、最後は「コードの質を高めるために単体テストを書く」ということを理解してもらえた
    • 数字で説明出来れば説得しやすそう
      • それが出来ればよいのだけどねぇ....
      • メトリクスとかカバレッジとかで数字を示すことができる
        • 長期的な傾向を見るのも大事だよね、相対的に数字を使うのはよいかも
      • 数字がひとり歩きするのは危険（特にカバレッジ）だよね
      • 最終的に「良いコードだったのかどうか」という指針は必要だよね
      • お客さんにとっても価値を提供する「良いコード」ではなければいけないね
  • 無駄だよねと思っている中にお客さんが大事だと思っていることがある
    • プロジェクトの文化によって重要度が違う
    • 「これって無駄じゃない？」という判断は開発者がしてはいけないよね、お客さんに聞くところから

15.3 継続的インテグレーションとは

  • ビルド時間
    • 例えばレポートは1日1回にする、内容によってテスト頻度を変える（毎コミット時にテストするものは絞る）
    • Cookpadさんが札幌で話したことにビルド時間短縮について話をしていたよ -> http://www.slideshare.net/hotchpotch/ruby18

15.4 どうすればうまくいくのか

  • 悲観的ロックモデルは使ってはいけない
    • その通り
    • VSS（デフォルトで悲観的ロック）とか、SVNで全てのファイルにロックかけるとか
    • 本当にコードベースを共有しなくなるよ
    • ビルドを壊す人がいるからという理由で導入された
    • ロック解除の監視とか本来のバージョン管理システムの目的から外れていく・・・（マージをするのが悪という文化）
      • oh...
    • ファイルをロックしたいは共有サーバーでソースをいじっている感覚の延長線上だよね...
  • コンフリクトした場合どうするか
    • どういう責任でマージする？
    • わからなかったら書いた人に聞く
    • コードの文脈が違っていたら確認しないと不安だよねぇ

15.5 チェックイン手順を習慣づける

  • ビルドをだいじに
    • 失敗するテストをコメントアウトするってやったことあるよね
    • テストが悪かったらそのテストは作りなおせば良い
      • リファクタリングテストを作るのが正しい方法だね
  • 4番目の手順が結構大変
  • バイナリファイルの管理は大変（ドキュメント類）
    • バージョン管理を手軽にできるのはソースコードがテキストファイルだから
    • Office系の差分を見ることができるツールもあるよ
  • DB変更の管理をどうするか
    • フレームワークに依存しないDB変更マージツールもある DB deploy
    • railsのマイグレーションはよくできているよね（コンフリクトすると結構大変）
  • リポジトリ管理を全くしていなくても数十年続いているプロジェクトもある
    • 綱渡りだなあ・・・
    • 神様ばっかりいる集団のようだ
    • そういう世界もあるんだね
  • 10年続くプロジェクトであったならば継続的インテグレーションとか採用するかなあ
    • 後から変更することができないよね
    • でも何も導入しないのではなく、現状で最善の方法を採択するのが良いのではないかな
    • 必要に応じてテコ入れする

15.6 ビルドを自動化する

  • Jenkinsのことだね
  • 実行はコミット単位？
    • そうなるよね -> だからビルドの実行時間が大事
    • 分散バージョン管理システムだとpushした単位になるよね
  • サーバーでのビルドの自動化はブームが過ぎた感がある、今はローカル環境でのビルド自動化が盛り上がっている
    • ローカルでコードを保存するたびに継続的インテグレーションができる仕組み
    • 分散バージョン管理システムだとローカルにコミットしたタイミングやコードを保存したタイミングで継続的インテグレーションが実行されてほしい

15.7 作業単位を小さくする

  • クリアコードさんのブログでコミットの単位について書かれていて議論がされていた http://www.clear-code.com/blog/2012/3/13.html
  • コミットに意味を持たせたいよね
  • コミットが乱れているということは、自分の作業進行が乱れているということが多い
    • 先にコミットログを考えて作業をすればよいのだよね
  • チケットとか作業ブランチの切り方を考えるほうが難しい
    • ブランチを使ったほうが良いのだね・・・
  • 分散だと細かくコミットするようになるよね
    • pushするときにビルドを壊さなければいい
    • コミットはビルドを壊すかどうかを気にせずにコミットして良い、保存と同じ感覚、セーブポイント
    • TDDやBDDと分散バージョン管理システムのコミットはとても相性がよいよ
  • なぜ、そんなに細かくコミットする必要があるのか？
    • セーブポイントとして戻したい？
    • コーディングのリズムを取るため
    • 他の人がどういうコードを書いているかをコミットログで知りたい
    • ソースコードをチェック・レビューする人は単位が細かい方が嬉しい
    • 細かくしたほうが、今何をやっているかを自覚しやすい（意識をつけやすい）

マスターセンセイと熱心な弟子

  • システムの一部であっても継続的インテグレーションはしたほうがいい
    • そうだよなあ
    • ローカル環境での継続的インテグレーション

次回は15.8, 監訳者あとがき - 最終回（予定）！！

Add a custom footer
Add a custom sidebar

Clone this wiki locally