#scmbc in hokkaido_session

アジェンダ

SCMとはなにか

ブランチ戦略

アジェンダ

今回は参加者が少なめで、
SCMとはなにか
なおかつVCSに対する理解のある人が多かっ
たので、
ブランチ戦略
SCMの重要性については省略してみました。
不明点は質問してください！

Software
Conﬁguration
Management

ソフトウェア構成管理

バージョン管理システム

ALM
(=Application Lifecycle
Managemant)

なんかプログラマーさんは
いろんな単語を。。。

ふわっと整理してみた

VCS Build

CI
SCM
CD
ALM

VCS Build

CI
SCM
今日の話はここ
CD
ALM

SCMの定義
構成の識別チームワーク

構成の管理

状態の監査

レビュー

ビルドの管理

プロセスの管理

構成の識別

いわゆる履歴を管理できること

構成の管理

つまるところ、VCSの主要機能

リビジョンを管理する

リビジョン間を自由に行き来する

構成の管理

リリースやリリースに対する修正をプロ

ダクトのライフサイクル全体にわたって

管理し、プロダクトの作成の一貫性を保

証すること。

構成の管理

リリースタグを打ったり、リリースブラ

ンチ上で管理するようなことで実現して

いる

状態の監査

コンポーネントの状態や変更要求を記録

して報告出来る事。メトリクスなども収

集して見れる事。

状態の監査

タスクとビルド結果を結びつける

ITS,CIと連携

VCSのコミットコメントでタスク管理

レビュー

プロダクトの完備性の検証、コンポーネ

ントが理解しやすい集合であることをラ

イフサイクルを通じて保証する

レビュー

プロダクトを実行するために必要なものを管理でき、

理解し易い構造であること。

検索性が高いこと。

ビルドの管理

ビルドやリリースをするためのツールや

プロセスを管理する

ビルドの管理

ビルドスクリプトやデプロイスクリプトを管理する。

それらを実行する環境に関しても同様。

最近だとCIサーバーやビルドツールが多くを担当する

ようになっている。


リリースが組織のプロセスに則っている

事を保証する


リリース、運用、改修、カスタマイズバージョンなど

のライフサイクルが組織が必要としている形態に対応

できること。

分散チームの場合なども考慮する必要がある。

チームワーク

開発者間の意思疎通を管理し、変更が適

切なタイミングでシステムに反映される

ようにする

チームワーク
リビジョンの追加自体や、リジェクトさ

れた場合、追加の申請、ブランチの開始

終了など。

ITSやVCSのフックスクリプトやCIで行

うことも多い。

アジェンダ

SCMとはなにか

ブランチ戦略

DVCS

ブランチや
リポジトリの構成

ブランチ戦略類似語

ブランチ戦略

ブランチ

ブランチモデル

リポジトリパターン

ブランチの定義
by kyon_mm

ブランチを定義する
DVCSによらない概念としてのブランチを次のように

定義する。

リビジョングラフのツリー構造それぞれの枝をブラン

チとして見る。

物理的に分散された協調するリポジトリのこともブラ

ンチとして扱う。

ブランチの負債化を防ぐ

ブランチポリシーを
決定する要因

ブランチ特性
Readyの定義マージポリシー

Doneの定義ユーザー数

コミット粒度

事前検査

Ready/Doneの定義

Ready : なにをもってそのブランチが作成されるかの定義。

Done : なにをもってそのブランチがあるサイクルを終えるか

の定義。

実質的にはDoneの定義はマージのタイミングになる。

コミット粒度

どの単位でリビジョンを作成するか。

例えば、リリース単位、単体テストが終わる単位、タスク管

理上での1タスク単位、など。

事前検査

コミットする前にどのような検査をどの程度行う必要がある

か。

例えば、コンパイルが通る、ユニットテストが全て通る、最

も近いユニットテストが通る、全てのテストが通る、など。

マージポリシー

マージコミットを作成するかどうか

逆方向マージを実施するかどうか

ユーザー数

異なるユーザー同士がどれくらいの頻度でコミットするのか

特定ユーザーのみが頻繁にコミットするのか、5ユーザーそれ

ぞれが1日に10回以上コミットするのか、など。

これらを鑑みて
ブランチ戦略を決定する

今回は代表的な
ブランチ戦略を紹介します

特性毎にまとめる実力があ
りませんでした。

kyon_mmの次回作に
ご期待ください

@ 4:リリースバグへの対応
|
o 3:Release1
|
o 2:Function2を追加する
|
o 1:Function1を追加する
|
o 0:リポジトリ説明用のreadmeを追加する

リリースしたものを保守す
るブランチ

@ 6: default :リリースバグ対応を取り込み
|
| o 5: release1 :リリースバグへの対応
||
o | 4: default :Function3を追加
|/
o 3: default :Release1
|
o 2: default :Function2を追加する
|
o 1: default :Function1を追加する
|
o 0: default :リポジトリ説明用のreadmeを追加する

フィーチャーブランチ

追加する仕様/機能などをそれ
ぞれ開発するためのブランチ

@ 6: default :Function2を取り込む
|
| o 5: feature/2 :Function2を修正する
||
| o 4: feature/2 :Function2を追加する
|/
o 3: default :Funtion1を取り込む
|
| o 2: feature/1 :Function1を修正する
||
| o 1: feature/1 :Function1を追加する
|/

日々のタスクレベル毎に
開発するためのブランチ

@ 4: default :Task1を取り込む
|
| o 3: topic/1 :Task1のテストが通ったのでリファクタリングを実施
||
| o 2: topic/1 :Task1のテストを追加
||
| o 1: topic/1 :Task1の実装が三角測量レベルで完了
|/
o 0: default :リポジトリ説明用のreadmeを追加

リリース準備ブランチ

リリース前検査用の
ブランチ

A Successful Git Branch Model
はここまでのものを組み合わせたもの。
それを強制的にサポートするのが
git-ﬂow, hg-ﬂow。

開発のスピードは落とさずに
低速なリポジトリと連携する

Local 1

Fast Slow
Central Central

Local 2

Local 1

Fast Slow
Central Central

Local 2
常に同期

夜間JOB同期
Local 1

Fast Slow
Central Central

Local 2
常に同期

ゲートウェイチェックイン

pushされたものを
安全に保つ

Push
Local 1
Central

Pull
Local 2
Central

Push Push
Local 1 専用
Central

Pull
Local 2
Central

Push Push
Local 1 専用
Central

Pull Pull
Local 2 専用
Central

Push Push
Local 1 専用
Central

テストが
通ったら
push

Pull Pull
Local 2 専用
Central

他の戦略

並行バージョン

プルリクエスト

ブランチ削除(cherry-pick)

サブリポジトリー

etc...

まとめ

SCMはVCSに留まらない。ソフトウェア構成管理である。

開発者間のコミュニケーションパスが増える程、ブランチ戦

略が曖昧だと破綻しやすい傾向にある

現状ではSCMツールと言えるものは少ないので、多くはデジ

タル/アナログな手法を組み合わせる

ご清聴ありがとうぴょん◆

#scmbc in hokkaido_session

Recommended

Recommended

More Related Content

Similar to #scmbc in hokkaido_session

Similar to #scmbc in hokkaido_session (20)

More from kyon mm

More from kyon mm (20)

Recently uploaded

Recently uploaded (7)

#scmbc in hokkaido_session

Editor's Notes