01. 最後にコンフィギュレーション管理/バージョン管理が問題を解決するには？
R＆Dプロセスパノラマ
プロパティマネジメントプロセス：管理機能「計画バージョン」の設立、何をすべきか、完全な追跡、実行する方法を、どのように進行します
プロセス工学のプロパティ：残っている「バージョンを提供する」ビルド管理能力、完全な追跡、どのように、どこで、どのように品質
私が顧客にもたらすためにどのようなすべてのこのようなものを、達成した場合、すべてのソフトウェア要件は、推測に基づくものです。
チューブを必要とするものを最後にコンフィギュレーション管理/バージョン管理？
nは二つの意味のバージョン：
uのプロパティマネジメント（計画バージョン）：私たちは、チームがこのバージョンで提供何披露したいですか？
uはプロパティ（配信版）プロジェクト：何配信チームは本当にこのバージョンで披露？
はっきり知っている目的のn管理/バージョン管理は、開発プロセスに関わるすべての人を取得することです
uが私たちが行うには何ですか？
uが私たちが残って何をしていますか？
我々は、U行っていますか？
nは構成管理/接続リンクの収束点として、バージョン管理、開発プロセスは、だけでなく、管理コードの必要性を考慮すべき
uのチームモデル
U試験モデル
U CI / CDライン
連続配信の挑戦：3ソフトウェア開発を結合します
コードレベルのカップリング：開発者を変更すると、チームの規模のシステム全体に影響を与える可能性が<20
実行中の遅延の影響に、マルチチームコラボレーションはないインタフェース定義を使用することによって、呼ばれるかもしれない、できないクロス使用テクノロジ・スタック：コンポーネントレベルを結合します
サービスレベルのカップリング：本番環境への遅延の影響、スタックと呼ばれるマルチチーム、マルチテクノロジーのコラボレーション、インターフェイスに応じて、セルフサービス、定義されていることがあります。
目的の分岐戦略
コードは、nデカップリング
nは同じコードの異なるコピーを同期する上での作業に異なる開発者またはチームを許可します
n個の異なる目的コード/属性が存在することができ、かつ相互接続トラック
Uバックボーン：マスター
U特性：機能
Uパッチ：ホットフィックス
U検定：テスト
uが公開：リリース
-------------------------------------------------- ---------------------
02. 構成リポジトリスプリット
ライブラリを考慮することが妥当であるかどうか
デプロイ可能ユニット
N コンパイル、デバッグ、テスト、CI / CD及び場所に依存しないコードを展開するに接することができ
nは スプリットモード
コードにuが依存パッケージに依存します
Uサービスと依存（マイクロサービス）
U分離プロセスデータ
nは 減少し、展開ユニットのメリット
Uは、コードのコンパイル/デバッグ/テスト/ CI / CDと展開のスピードを改善するために、コードベースを減らします
uがミスの可能性を減らします
Uは、モジュラーコンポーネント、および交換（オープン、代替）を導入しやすいプッシュします
悪趣味構成管理
n個の虐待ブランチ
異なるブランチのn痕跡関係上のコード（マージ移行コードを使用しますが、再提出していません）
n個の異なるコードの異なる枝上に保持
n個のピッキング操作コードの過度の使用
n個必要性を再設定するには、CI / CDは、いつブランチ私を得ました
n個の異なるブランチは異なる製品を生産します
-------------------------------------------------- ---
進化ポリシー支店ポリシー
機能分岐構造で：
Lチームの用途は、機能的なチーム（開発、試験、運用、保守）滝：各コードの別個のスタンドアロンバージョンを必要とするので、機能領域の明確な分割
L独立テスト分割典型的症状であります
リットルごとに、単一のアーキテクチャが変更、紛争を大量にマージ決定し、痛みの問題のコードのプログラミングチームポイントを選びます
リットルごとに単一のアーキテクチャは、合併が大きな変化を生成し、その後コードプログラミングチームの競合や痛みのポイントの問題を選択するかを決定します
厳密生産バックログに公開することなく、多くのコードを引き起こした銃口解除の操作および維持を制御するためのL個の憎悪、製品の多数（廃棄物及び未実現値）の形成、発達のサイズを大きくし、作業のテスト中には、複雑さを増加しました
リットルの リリースウィンドウ厳密に制御し、ソフトウェアの品質を向上させることはありませんが、新しい展開機能から生産の損失の原因となる品質管理（増分リリース）、リリースされたコードの量を削減しようとするチームによって生じたソフトウェアプロセスのリスクの制約、異なるコード分岐の品質を向上させるためにコードは互いを追跡することはできません
ごみの山にLコードベース
トランク開発ブランチリリース（トランク開発モデル）：
リットルの利点：
n個のシンプルな
Nクロス機能共有コードライブラリ
nは、開発/テスト用ハイブリッド作業をサポートしています
n個の並列RC版とのDev
Nレポのコードとして以下のデプロイメントユニットの境界を必要とするかもしれません
nは簡素化CI / CD操作、一意採用の線形性を保証するのは簡単
リットルの短所：
その他のバージョンでは、並列をサポートしていません。
大きな国コードライブラリを満たすことができないシングルモード（コード・ロジックのデカップリングを導入するスイッチ機能の必要性を残しました）
機能ブランチ、トランクリリース
リットルの利点：
クロス機能共有コードベース
並行開発のためのより多くのコード
（マージしなければならない、直接挿入することが許可されていない）より堅牢なマスター支店コード
リットルの短所：
nは機能ブランチの生存期間は、紛争の多くを引き起こす傾向があります
nは独立して機能への各分岐ニーズCI / CDの設定、CI / CDの設定を助長されていません
nが製品の独自性を確保するために助長されていません
分岐した欠点の解決機能 - 引っ張っ要求
合わせた要求は、nへのプルありません
uが要求（プル要求）に引っ張っ：
、いわゆる「プル」のコード「プル」ASKリットル
Lコードまだ合成されていないが、そう「要求」と呼ばれます
リクエストが私を得たときのn Doが料理を作成するためにマージする必要がありません
要求はnに引くことができます
Uコードレビュー/評価における「コード変更」の周りの社会的プログラミング、
uがトラッキングコードレビュータスク
U（ヘッドdiffが代わりに表示差分をコミット）トラッキング状態を容易にするためにコードの最終バージョン
uの保護対象のブランチ（マスターすることができ、あなたはまた、他の支店を使用することができます）
uはCI / CDの設定を簡素化する、唯一のあなたは、数え切れないほどの機能ブランチをサポートすることができ、一度設定する必要があります
uがユーザーによって物語の開発を支援します
-------------------------------------------
ベスト分岐戦略テンプレート
何のブランチが存在しないこと
