「継続的デリバリー」読書会 第3章 継続的デリバリー

852 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
852
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
15
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

「継続的デリバリー」読書会 第3章 継続的デリバリー

  1. 1. 『継続的デリバリー』読書会   第3章   継続的ンテグレーション 大崎的デリバリー   @pinori
  2. 2. 3.2.1  始める前に必要なもの   1.  バージョン管理 •  プロジェクトにあるものはすべて単一のバージョ ン管理レポジトリにチェックインしなければならな い   –  コード   –  テスト   –  データベーススクリプト   –  ビルド・デプロイメントスクリプト   アプリケーションの構築・インストール・実行・テストを行 う上で必要なものすべて  •  どんな小さいプロジェクトでも  
  3. 3. 3.2.1  始める前に必要なもの   2.  自動ビルド •  ビルドはIDEを使わずコマンドラインから実行 できるように   –  CI環境からビルドプロセスを自動的に実行でき、 何か問題が起こったときに監視できるように   –  ビルドスクリプトもテストし、リファクタリングする。   –  これによって、ビルドの理解や保守、デバッグす るのが容易になる。
  4. 4. 3.2.1  始める前に必要なもの   3.  チームの合意 •  継続的インテグレーションはプラクティスで あって、ツールではない。  •  故に下記のような規律を開発チームに   –  インクリメンタルな変更を少しずつこまめにチェッ クイン   –  変更によってアプリが壊れたら、それを最優先で 修正  
  5. 5. 3.2.2  基本的な継続的インテグレー ション •  CIツール例   –  CruiseControlファミリー   –  Jenkins  (旧Hudson)   –  Go  (Thought  Works  Studios社)   –  TeamCity  (JetBrains社)   –  etc.
  6. 6. 3.2.2  基本的な継続的インテグレー ション •  自分の変更のチェックインの準備が整ったら   1.  ビルドがすでに実行されているかを確認。実行中で あれば終了を待つ。失敗したら他のメンバと動くよう に修正。   2.  開発環境のコードをバージョン管理の最新バージョ ンで更新、他人の変更を取得。   3.  開発機上でビルド&テスト。   4.  バージョン管理に自分の変更をチェックイン。   5.  CIツールがビルド&テスト。   6.  失敗したら、即座に修正して3.へ。   7.  成功したら、次のタスクへ。
  7. 7. 3.3  継続的インテグレーションの前提 条件 •  CIはプロジェクトの途中から始めようと思うと 多大な苦痛を伴いかねない。  •  始める前に次に上げるプラクティスを準備し ておく必要がある
  8. 8. 3.3.1  定期的にチェックインせよ •  trunkやメインラインにこまめにチェックインす べし(少なくとも1日に2回)   –  変更は小さくなり、ビルドを壊す可能性も低くなる   –  間違った場合にも、元に戻りやすい。   –  コンフリクトの可能性も低くなる。  •  ブランチを使いながらの本当の意味でのCIは 不可能   –  ブランチは他の開発者と統合していないから
  9. 9. 3.3.2  包括的な自動テストスイートを作 成せよ •  ユニットテスト   –  コードの振る舞いを個別にテスト  •  コンポーネントテスト   –  アプリ内のコンポーネントの振る舞いをテスト  •  受け入れテスト   –  受け入れ基準のテスト   •  機能、キャパシティや可用性、セキュリティ、etc.   –  アプリ全体を擬似本番環境で起動した状態で実 行するのが望ましい  
  10. 10. 3.3.3  ビルドプロセスとテストプロセス を短く保て •  ユニットテストの時間が長いと…   –  チェックイン前に手元でテストするのをやめてしま う   –  ビルド中に複数のチェックインが行われた場合、 どのチェックインで壊れたのか分からなくなる   –  チェックインをこまめにやらなくなる  •  できる限り短くすべき   –  10分が限界?
  11. 11. 3.3.3  ビルドプロセスとテストプロセス を短く保て •  ビルド時間を減らすために   –  まず、ユニットテストをより高速に  •  さらには、テストプロセスを複数のステージに 分けることも   –  コミットステージ(第7章でより詳細に)   •  コンパイル   •  ユニットテスト   –  受け入れテストステージ   •  受け入れテスト、etc.
  12. 12. 3.3.4  開発ワークスペースを管理する •  一般的に開発環境は開発者のローカルマシ ンに置いておくべき  •  そのためには…   –  自動テストが通り、構成管理されたソースコード、 テストデータ、DBスクリプトなどを取得   –  構成管理されたサードパーティーのライブラリや コンポーネントを取得   –  開発機上で自動テストが通ることを確認  
  13. 13. 3.4  継続的インテグレーションソフト ウェアを使用する •  継続的インテグレーションソフトウェアのの最も基本的な機 能   –  バージョン管理システムをポーリング   –  コミットがあれば最新バージョンをチェックアウト   –  ビルドして結果を通知  •  ガジェットで最新のビルドステータスを様々なスタイルで表 示できるので、可視性あげよう   –  ラバーランプとか音声読上げとか…   –  ビルドの状態が一目瞭然になる  •  ちなみに、ビルドの失敗はごく自然なこと   –  品質への問題の兆候ではない   –  顧客が近いと不安になるかもしれないので、ちゃんと説明すべ し
  14. 14. 3.5  基本的なプラクティス •  継続的インテグレーションはツールではなくプ ラクティス  •  開発チームはかなりの規律を守る必要があ る
  15. 15. 3.5.1  ビルドが壊れているときには チェックインするな •  ビルドが壊れたら直ちに修正する  •  問題が修正されるまでチェックインはしない  •  さもなければ、   –  問題がより複雑になり、修正により時間がかかっ てしまう   –  壊れたままの状態に容易に慣れてしまう
  16. 16. 3.5.2  コミットする前に、常にローカルでコミットテストを実 行せよ あるいは代わりにCIサーバーにやってもらえ •  コミットする前にバージョン管理から最新版を取得した 上で、ローカルでコミットテスト   –  ビルドを壊していないかローカルで気づける   –  CIのコミットメントステージでのエラーは、チェックインし忘 れか、もしくはこの作業中に他人がチェックインしたか  •  この作業を自動化できるものもある   –  プレテストコミット、パーソナルビルド、プリフライトビルドな どと呼ばれる   –  Pulse、TeamCity、ElectricCommanderなどがサポート   –  コミットテスト終わるのを待たずに次の作業を開始できる
  17. 17. 3.5.3  次の作業を始める前に、コミット テストが通るまで待て •  チェックインしたら、ビルドの進捗を観察する 責任が生じる  •  コミットテストに通るまで、作業を新しく開始し てはならない  •  ビルドに失敗したらすぐに対応すべし
  18. 18. 3.5.4  ビルドが壊れているのに、家に 帰ってはならない •  修正するか、変更を取り消すか  •  そのためにも、業務終了時間前のチェックイ ンは避ける   –  チェックインは翌日に持ち越すとか   –  万が一失敗しても対応できるように
  19. 19. 3.5.5  常に以前のリビジョンに戻す準 備をしておくこと •  問題の修正に時間がかかるようであれば、   –  レポジトリをリバート   –  問題の解決をローカルで
  20. 20. 3.5.6  リバートする前にタイムボックス を切って修正する •  例えば10分とか決めて、その間に修正できな ければリバートする
  21. 21. 3.5.7  失敗したテストをコメントアウトす るな •  原因を突き止め、以下のいずれかの対応を   –  コードを修正(リグレッションが見つかった)   –  テストを修正(仕様が変更された)   –  テストを削除(テスト対象が削除された)  •  一度許すとテストのコメントアウトだらけになり がち  
  22. 22. 3.5.8  自分が変更してビルドが壊れた ら、すべてに対して責任をとれ •  自分の変更は他人の書いたテストも通ること   –  通らなければ、そのテストも修正を   –  そのためには、全員がコードベース全体にアクセ ス可能であること
  23. 23. 3.5.9  テスト駆動開発 •  ユニットテストのカバレッジが十分である必要 がる   –  素早いフィードバックのために  •  そのためにはテスト駆動開発は必須   –  お勧め本   •  『Growing  Object-­‐Oriented  SoTware,  Guided  by  Tests』   •  『xUnit  Test  PaXerns:  Refactoring  Test  Code』
  24. 24. 3.6  やったほうがいいプラクティス
  25. 25. 3.6.1  エクストリームプログラミング (XP)の開発プラクティス •  継続的インテグレーションは、XPのプラクティ スのひとつ  •  他のプラクティスとの相性もよい  •  特にリファクタリング   –  CIとテスト駆動開発でリファクタリング可能に
  26. 26. 3.6.2  アーキテクチャ上の違反事項が あった場合にビルドを失敗させる
  27. 27. 3.6.3  テストが遅い場合にビルドを失 敗させる
  28. 28. 3.6.4  警告やコードスタイルの違反が あった時にビルドを失敗させる •  コードチェックツール例   –  Simian   –  JDepend  (Java)、NDepend(.NET)   –  CheckStyle、FxCop   –  FindBugs  •  ラチェット方式   –  警告やTODOの数が以前のチェックインより増え ていたら失敗  
  29. 29. 3.7  分散したチーム •  チームが分散している場合のお話   –  物理的に離れている場合   –  時差がある場合
  30. 30. 3.7.1  プロセスに与えるインパクト •  チームが分散していても時差がなければ、継 続的インテグレーションに違いはない  •  時差がある場合は、よりプレセスを厳密に守 る必要がある   –  ビルド壊れたまま帰宅しちゃうと…  •  VoIPとかメッセンジャーでのコミュニケーション が非常に重要
  31. 31. 3.7.2  中央集権的継続的インテグレー ション •  1箇所で集中的に継続的インテグレーション   –  環境の一貫性を保証しやすい  •  開発者がすぐにこの環境にアクセスできるよ うにしておかなければならない   –  申請して数日待たないといけないとか…
  32. 32. 3.7.3  技術的な問題 •  バージョン管理システムとの回線速度や品質 を十分なものに  •  さもなくば分散バージョン管理システム   –  GitやMercurial   –  回線落ちててもチェックイン可能  •  バージョン管理システムと自動テストホスト間 の回線なども大事
  33. 33. 3.7.4  代替案 •  中央と太い回線が用意できない場合、バー ジョン管理システム、CIシステムをローカルに たてる方法もある   –  中央と環境を合わせ、同じビルドができるように   –  ローカルでバージョン管理のためには   •  コンポーネントベースのアプローチ⇒13章   •  分散バージョン管理システム  •  長期的視点では回線を太くするほうが安上が り
  34. 34. 3.8  分散バージョン管理システム •  分散バージョン管理システムでCIするには   –  一つのレポジトリをマスターと定め、そこへプッ シュする  •  GitHubモデルはフォークしたレポジトリが分散   –  どれが統合できるかわからない   –  変更をすぐにマージ?→たぶん失敗   –  各レポジトリでCI   •  変更があったらマスターをマージしてCI   •  マスターにマージしても正常であることを保証

×