Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (18)
Similar a 継続的デリバリー読書会 14章
Similar a 継続的デリバリー読書会 14章 (20)
Más de Yusuke HIDESHIMA
Último
Último (9)
継続的デリバリー読書会 14章
- 2. 14.1 導入 • バージョン管理システムの目的 – アプリケーションに対して行われたすべての 変更の完全な履歴を管理すること – ソースコード/ドキュメント/ビルドスクリプ ト/テストも含める • 本章の目的はバージョン管理システムを活 用してチームの生産性をあげること
- 3. 14.2 リビジョン管理システムの 簡単な歴史 • SCCS – あらゆるバージョン管理システムのご先祖 – 1972年ベル研究所で生まれる – マーク・J・ロックカインドが作った • その派生がいろいろいっぱいある
- 4. 14.2.1 CVS • Concurrent Version System • 複数の開発者が同時に同じリポジトリ上で作 業できる(という意味) • クライアントサーバ型アーキテクチャ • 協力なブランチ、タグ機能 • 長い間よくつかわれた（他に自由に使えるも のがなかったから) • ファイル単位での変更追跡 • ただ、いろいろ問題もある(P.449参照)
- 5. 14.2.2 Subversion • よりよいCVSを目指してつくられた • CVSの問題を修正。CVSユーザにとって 使いやすいように作られた • リビジョン単位でのバージョン管理 • リビジョン番号が各リポジトリ全体に適 用される – 各ファイル単位ではない • やっぱり問題点もいろいろある(P.451参 照)
- 6. 14.2.3 商用のバージョン管理シ ステム • Perfoce – パフォーマンス、スケーラビリティに優れる • AccuRev • BitKeeper – 真の分散型バージョン管理システムとして最 初に登場したもの • TeamFoundationServer – VisualStudioつかっているなら使ってもいい んじゃない？
- 7. 14.2.4 悲観的ロックをやめろ • 楽観的ロックに対応してるならそれを使え ばよい – つまり、ローカルの作業コピーのファイルを 編集しているときに、他のメンバーも各自の 作業コピー上で同じファイルを編集できる • 悲観的ロックの方がマージの際の衝突を防 ぎやすいが、開発プロセスの効率を下げ る – 悲観的ロック：排他ロックを取得しないと、 そのファイルを編集できない
- 8. 14.3 ブランチとマージ • ブランチの主な目的 – 複数の作業ストリームを同時に稼働させる – 互いが他のラインに影響を及ぼさないように する • 開発はメインライン、バグフィックスはリ リースブランチで行うという方法がよくと られる
- 9. 14.3 ブランチとマージ • (先ほどの例以外で)チームがコードのブランチを作る理由がいくつかある • 物理的な理由 – システムの物理的な構成によるブランチ – サブシステム単位でブランチを切っている • 機能的な理由 – システムの機能的な構成によるブランチ – 論理的な変更、バグフィックス、機能拡張、デリバリー可能な機能単位 • 環境的な理由 – システムの運用環境によるブランチ – ビルド時や実行時のプラットフォームの違いなど • 組織的な理由 – チームの開発活動によるブランチ – タスク、サブプロジェクト、グループ単位 • 手続き上の理由 – チームの作業の振る舞いによるブランチ – 運用ポリシーやプロセス、状態単位
- 11. 14.3 ブランチとマージ • ブランチはあとでマージしなければならな い • 各ブランチがデリバリープロセスにおいて どのような役割を果たすかポリシーを定 義する必要がある
- 12. 14.3.1 マージ • 各ブランチは完全に独立している、他のブ ランチの存在を全く無視して存在している • しかし、ある時点でブランチへの変更内 容を別のブランチに適用する時がくる – => とても時間のかかる作業
- 13. 14.3.1 マージ • 真の問題が発生するケース • マージしたい二つのブランチでそれぞれ別 の変更を行い、それらが衝突している場合 – 機能の実装方法が食い違っているような変更 の場合、かなりの量のコードを書きなおさな いといけない。 – これをマージする場合はコードを書いた人の 意図をしらないと不可能
- 14. 14.3.1 マージ • 意味的な衝突はバージョン管理システムで は検知できない • 包括的な自動テストがなければ、実際に障 害がおこるまで衝突があったことに気づ かない • マージするまでの期間が長くなればなるほ ど、作業する人がおおくなればなるほど マージに悩まされる
- 15. 14.3.1 マージ • マージで悩まないためには…… • ブランチの数を増やし、ひとつのブラン チで行われる変更の数を減らす • ブランチの作成をなるべく控え、リリース 毎に１つずつ程度にする
- 18. 14.3.2 ブランチ、ストリーム、 そして継続的インテグレーション • より管理しやすいブランチ方針 – 寿命の長いブランチをリリース時にだけ作る (p.459 図14-2) – 新しい作業は常にtrunkにコミット – マージされるのはリリースブランチに修正が はいったときだけ – コードが常にリリース可能な状態
- 19. 14.4 分散型バージョン管理シス テム • Distributed Version Control System • DVCS
- 20. 14.4.1 分散型バージョン管理シ ステムとは？ • 各自が自己完結した一人前リポジトリを自分のコンピュータ上に持 つ • 変更はローカルリポジトリにコミット • 他のユーザの変更を直接取り込める • 更新を特定のユーザたちにだけ送ることが可能 • どのパッチを採用して、どのパッチを却下するのかを簡単にきめら れる チェリーピック • オフラインでもコミットできる • ローカルでのコミットを、手軽に変更したり、分岐したり、まとめ たりといった作業をしてから他のリポジトリに送ることができる リ ベース • 何かのアイディアをローカルリポジトリで試したいときに中央リポ ジトリにブランチを作らなくてよい • 高可用性 • リポジトリのコピーが多数作られているので耐障害性が上がる
- 21. 14.4.1 分散型バージョン管理シ ステムとは？ • いわゆるメインラインはどこにも存在しない(P. 461 図14-3) • GitHub, BitBucket, GoogleCode – 既存リポジトリのコピーを作るの簡単 – 手元で変更した内容を他のユーザに公開してみてもら うのも簡単 – 本家のメンテナーもこれらの変更を確認でき、気に 入ったものは自分のマスターリポジトリに取り込め る • 協調作業におけるパラダイムシフト • 新機能やバグフィックスのデリバリーが高速化
- 22. 14.4.2 分散型バージョン管理シ ステムの簡単な歴史 • Linuxの一部のセクションのメンテナーが BitKeeperを使い始めたのが普及のはじまり • 現在は – Git – Mercurial – Bazaar – Darcs – Monotone – など
- 24. 14.4.4 分散型バージョン管理シ ステムを使う SVN • svn up (最新のリビジョン の取得) • 何らかのコードを書く • svn upで自分の変更と中央 リポジトリの更新をマージ • コミットビルドをローカル で実行 • svn ciで自分の変更をバー ジョン管理にチェックイン hg (Mercurial) P.465 図14-4 • hg pull でリモートリポジトリの最新の 更新をローカルリポジトリに取得 • hg co でローカルの作業コピーの内容を ローカルリポジトリから更新 • 何らかのコードを書く • hg ci で変更をローカルリポジトリに保 存 • hg pull リモートリポジトリの更新を取 り込み • hg merge ローカル作業コピーの内容を マージ結果で更新 • コミットビルドをローカルで実行 • hg ci マージ結果をローカルリポジトリ にチェックイン • hg push 更新をリモートリポジトリにプ シュ
- 26. 14.5.1 ストリームベースのバー ジョン管理システムとは？ • 一連の変更を複数のブランチへ同時に適 用出来る – マージの際の問題を解決するため • ブランチが協力な概念であるストリーム置 き換えられる • ストリームが継承できる – 親ストリームに変更を適用すると、子孫スト リームにも変更が同時に適用される
- 29. 14.5.1 ストリームベースのバー ジョン管理システムとは？ • あるストリームへの変更は、その変更を昇 格させるまで他のストリームに何の影響も 及ぼさない • 昇格させるとそのストリームを継承するす べてのストリームから変更が視えるように なる
- 30. 14.5.2 ストリームを使った開発 モデル • 特定の機能を実装するためのストリームを作 る • 機能の実装が終えたら、そのストリーム内で のすべての変更をチーム全体のストリームに 昇格させる • 継続的インテグレーションに投入する • 中規模∼大規模のチームでも複数の機能を同 時に開発しつつお互いに影響を及ぼさないよ うにできる
- 31. 14.5.2 ストリームを使った開発 モデル • 別々のチームが共有コードを異なる方法で 変更した際に複雑なマージが発生 • ある新機能が依存する別の機能のコード がまだ昇格していない場合に、依存関係の 管理に問題が発生する • リリースストリーム上でのインテグレー ションテストやリグレッションテストが新 しい設定ではうまく動かないという場合 に統合時の問題が発生する
- 32. 14.5.2 ストリームを使った開発 モデル • チーム数やレイヤの数が増えるほど問題は 悪化 • 影響はどんどん増殖 • チームレベル、ドメインレベル、アーキテ クチャレベル、システムレベル、本番レベ ルの5つのストリームを作ることで解決 • ……しかし、ストリームを昇格させるたび に先に挙げたような問題が発生した
- 33. 14.5.2 ストリームを使った開発 モデル • 上位ストリームへの昇格は可能な限り頻繁 に行う • 可能な限りの頻度で自動テストを実行する
- 34. 14.5.3 静的ビューおよび動的 ビュー • ClearCaseの「動的ビュー」機能 – ファイルがストリームにマージされたときに そのストリームを継承するすべてのストリー ムを使う開発者のビューを更新する機能 – 各開発者が変更をこまめにチェックインして いれば、マージが楽になる – 超低速 • 「静的ビュー」 – 開発者が自分でビューを更新しない限り変更 は反映されない
- 35. 14.5.4 ストリームベースのバー ジョン管理システムによる継続的 インテグレーション • 利点 – 開発者が自分だけのストリームで作業するの が容易 – マージも容易 • 変更が定期的に昇格されていれば継続的イ ンテグレーションが可能 – これをやると、前述した利点もそれなりの制 約を受けることになる
- 36. 14.5.4 ストリームベースのバー ジョン管理システムによる継続的 インテグレーション • ClearCaseでは…… – 完全にサーバーベースのモデル – マージ、タグ付け、ファイルの削除まですべてが サーバ側で処理 – 親ストリームに変更を昇格させようとすると、兄 弟ストリーム上で発生する衝突をこみったが解決 しないといけない – どんなサイズのリポジトリでも操作（チェックイ ン、ファイル削除、タグ付けなど）に恐ろしく時 間がかかる – 頻繁にチェックインしようとすると大きなコスト になる
- 37. 14.5.4 ストリームベースのバー ジョン管理システムによる継続的 インテグレーション • 変更セットの昇格機能について、継続的イ ンテグレーションを組み合わせるときは 問題がある • バグフィックスをストリームの祖先に昇格 すると、その子孫のストリームすべてに対 してビルドを起動しなくてはならない – 無理
- 39. 14.6 メインライン上での開発 • 開発者は常にメインラインにチェックインする • ブランを切ることはめったにない • すべてのコードが継続的インテグレーションの対 象 • 各開発者が他のメンバーによる変更をすぐに受け 取れる • プロジェクトの終盤になって「マージ地獄」や 「インテグレーション地獄」に陥らずに済む
- 40. 14.6 メインライン上での開発 • 通常の開発では開発者がメインライン上で作 業を進める • 少なくとも一日に一度はコードコミットする • 基本的にブランチは作らない • ひとつひとつの変更が充分に小さく、インク リメンタルなものになるように計画・実装し、 各段階でテストを通し、既存の機能を壊さな いことを確認しながら進めていく
- 41. 14.6 メインライン上での開発 • ブランチを否定しているわけではない • すべての開発作業は、いつかひとつのコー ドラインに落ち着く • ブランチを作るのは、メインラインへの マージが不要な場合のみ(リリースや、変 更前のスパイク)
- 42. 14.6 メインライン上での開発 • メインラインで開発を行うということは、 メインラインが常にリリース可能な状態で あるとは限らない • 変更に対するフィードバックを素早く得ら れるという利点 • 完全に結合されたアプリケーションにど のように影響を及ぼすかすぐにわかると いう利点
- 44. 14.6.1 複雑な変更をブランチな しでおこなう • コミットは常にtrunkに • 少なくとも一日一度はコミット • メインラインへのインクリメンタルな変更 をこまめに進めていくのが重要
- 45. 14.7 リリース用のブランチ • リリース直前は常にブランチを作ってもか まわないだろう • リリースブランチをつくればコードフリー ズを止めることができる – コードフリーズ：バージョン管理システムへ のチェックインを数日から数週間にかかえて 止めてしまうこと • リリースブランチをきれば、開発者はメイ ンラインで開発を進められる
- 46. 14.7 リリース用のブランチ • 新規機能の開発は常にメインラインで行う • ブランチを作るのは、特定のリリース用に必 要な機能が完全に揃った段階で、さらに新し い機能の開発を始めたくなったときだけ • 致命的な欠陥の修正だけをブランチに適用し、 それはメインラインにもただちに反映 • リリースが完了したら、そのブランチにタグ を打つ
- 47. 14.7 リリース用のブランチ • リリースブランチからさらに別のブランチ を切ってはいけない • リリース用のブランチはすべてメインライ ンからつくる
- 48. 14.8 フィーチャによるブランチ • 大規模なチームが並行して機能を開発しな がらメインラインもリリース可能な状態に 保つ • すべてのストーリー/フィーチャーは個別 のブランチを用意して、そこで開発を進め る • trunkを常にリリース可能な状態にしてお きたい場合に使う
- 49. 14.8 フィーチャによるブランチ • メインライン上での変更は常にブランチにマージ • 一つのブランチの活動期間を短めに • ある時点でのアクティブなブランチ数がその時点で作業中のストー リー数を決して超えない • 一つ前のストーリーのブランチがメインラインにマージされるまで は新しいブランチは作らない • テスターによるストーリーの受け入れテストをしてからマージする • リファクタリングはすぐにマージして、マージの際の衝突を最小化 する • リーダーの役割の一つはtrunkを常にリリース可能な状態に保つこ とにあんる • リーダーはすべてのマージをレビューしなければならない • リーダーはtrunkを壊す可能性のあるパッチを却下する権限を持つ
- 50. 14.8 フィーチャによるブランチ • 長期にわたって使われつづけるブランチを 作りすぎるのはよくない • マージで死ぬ • ブランチを切るという行為は本質的に継 続的インテグレーションに反する • 真の継続的インテグレーションに近いの はCIシステムが全部ランチを一つの仮想 trunkにマージすること – でもこれはたぶん失敗する
- 51. 14.8 フィーチャによるブランチ • 分散型バージョン管理システムはこの手の パターンを想定して作られている • メインラインからのマージ、最先端にに対 するパッチの作成が簡単にできる • オープンソースの世界ではうまくいく • 商用製品のプロジェクトでも、コア開発 チームが少数精鋭であればうまくいくだろ う
- 52. 14.8 フィーチャによるブランチ • 大規模なプロジェクトでこのパターンでうま くいく場合 – コードベースがモジュール化されている – きちんとリファクタリング済み – デリバリー舞台が複数の小規模なチームにわかれ ている – 経験豊富なリーダーが率いている – チーム全体がチェックインやメインラインへの統 合を頻繁に行なっている – デリバリーチームにリリースを迫るようなプレッ シャーを与えないこと
- 53. 14.9 チームによるブランチ • 大規模チームが複数の作業を並行で進めて いる時に、メインラインも常にリリース可 能な状態にしたい • trunkを常にリリース可能にしてしておく • チーム毎にブランチを切り、ブランチが安 定した時点でtrunkにマージする • あるブランチに何らかのマージをした場合、 他のブランチにもすぐに同じ内容をマージ しなければならない
- 54. 14.9 チームによるブランチ • 小さめのチームを作り、チーム毎のブランチで作 業を進める • あるフィーチャ/ストーリーの実装が完了したら、 ブランチを安定させてそれをtrunkにマージ • trunkへの変更は常にすべてのブランチにマージ する • ユニットテストや受け入れテストは各ブランチで のチェックインのたびに実行する • インテグレーションテストを含むすべてのテスト は、各ブランチからtrunkへのマージがあるたび に実行する
- 55. 14.9 チームによるブランチ • trunkへチェックインさせていると定期的 なリリースを保証しにくくなる • 複数のチームがそれぞれのストーリーに対 応しているとtrunkはほぼ常に中途半端な 作業が残った状態になる • そのままではアプリケーションをリリース できなくなる
- 56. 14.9 チームによるブランチ • 開発者たちはみな自分のチームのブランチ にのみチェックインする • このブランチをtrunkにマージするのは作 業中のすべてのフィーチャーが完了したと きのみ
- 57. 14.9 チームによるブランチ • うまくいく場合 – 複数の小規模なチームが比較的独立して作業 – システム内で機能的にそれぞれ独立した部分 を扱っている • すべてのブランチはオーナーを任命し、 オーナーにそのポリシーをまとめさせる必 要がある
- 58. 14.9 チームによるブランチ • trunkを常にリリース可能な状態に保つ • ブランチが安定するまでtrunkにマージで きない – 安定：trunkにマージするときに自動テストを 一切壊さない状態
- 59. 14.9 チームによるブランチ • マージを頻繁に行わなければ、真の継続的 インテグレーションが実現できなくなる – マージの際の衝突地獄 • すべてのチームはひとつのストーリーが完 了した時点でtrunkにマージする • trunkでの変更の取り込みも一日一度は行 う
- 60. 14.10 まとめ • 洗練されたモダンなバージョン管理システム の使いやすさは、チームでのソフトウェア開 発において最も重要 • バージョン管理のパターンはデプロイメント パイプラインを設計する際に重要なポイント • バージョン管理がうまくできてないと素早く ローリスクなリリースをするのは難しい • 使える機能を理解した上で正しいツールを選 んで適切に使うことがプロジェクト成功の鍵
- 61. 14.10 まとめ • 継続的インテグレーションを推進したいとい う思いと、ブランチを切りたいという思いは 基本的に相反する • CIを元にした開発を進めている時にブランチ を切ろうとすると、なんらかの妥協が必要 – 完全にCIの立場で考えるとすべての変更はできる だけ早くtrunkにコミットするべき – trunkは常に最新の完全な状態を保つ • あらゆるブランチの内容を一日一度以上の頻 度でメインラインにマージするべし