私は現在、分岐とマージが最初からうまく機能していないプロジェクトに取り組んでいます。これを変えるために、私たちはそれを行うためのさまざまな方法について話し合ってきました. この種のことを行う方法については、誰もが独自の哲学を持っていると思います。したがって、ここにもあるようです。
これまで話してきたことの 1 つは、機能ごとに分岐することです。この特定の方法の良い点と悪い点について、私たちはたまたま非常に異なる見解を持っています。
以前にこれを行った経験はありますか? うまくいきましたか？問題がありましたか - どのような問題がありましたか?
この質問に正解がないことはわかっていますが、世界中の他の開発者の意見を聞くのは非常に興味深いと思います。
機能ごとにブランチを使用しており、非常にうまく機能しています。最大の利点は、機能チームが、新しい機能が (この場合はメインに) 統合されるまで、自分たちが取り組んでいることは他の機能チームに影響を与えないことを知っていることです。
新しい機能が完成したら (そしてブランチが Main にマージされたら)、ブランチを Branch History フォルダーに移動します。これにより、開発者が確認する必要があるブランチ (フォルダー) の数が最小限に抑えられます。
私たちの場合、Main ブランチでは誰も働いていません。すべての開発は機能ブランチで行われます。初期開発 (本番環境への最初のリリース前) は、開発ブランチで行われます。本番環境への最初のリリース後、すべての開発は新しい機能ブランチで行われます。
小規模から中規模のチームの場合、ブランチを完全に分離する必要がない場合は、余分なブランチを避けてください。特に、開発チームの文化が適切なブランチとマージを嫌う場合はなおさらです。おそらく、維持するブランチを少なくすることと引き換えに、マージを許可されているすべての開発者が確実にマージの慣行に従っていることを確認してください。シェルフセット (TFS 内) と有効期間の短いフィーチャー ブランチは、マージのオーバーヘッドと関連するリスクを最小限に抑えるための優れた手法です。
これは、生産性とバージョン管理の安全性のバランスをとるために私が見つけたパターンです (〜25 人の開発者と〜3 人のテスターのチームの場合):
同じブランチで作業する:疎結合または関連のないコードに取り組んでいる開発者は、比較的安全に同じ Dev (または「統合」) ブランチで直接作業できます。バグ修正と互換性を損なわない変更はここにうまく適合します (他の開発者に影響を与える重大なリグレッションのリスクが低くなります)。継続的インテグレーション ビルドとゲート ビルドは、多くの開発者が同じブランチで作業するリスクを軽減する 2 つのベスト プラクティスです。 トグル 注:機能トグルを使用すると、分岐の必要性をさらに回避できますが、トグル動作をテスト/維持するためのオーバーヘッドが分岐を使用するよりもリスクが高くないことを確認してください。
シェルフセット:バージョン管理システムの機能を使用して、保留中の変更を開発者固有のプロト ブランチに保存します。TFS (Team Foundation Server) にチェックインする開発者は、統合/開発ブランチにチェックインする前に機能を開発およびテストする必要がある唯一の開発者である場合、個人ブランチ (または多くのマイクロ機能/タスク ブランチ) の代わりにシェルフセットを使用できます。 . 他のバージョン管理システムにも同様の構成があると 思いますアンチパターン:ローカル ワークスペースは、各開発者に一時的な分離を自動的に提供します... しかし、開発者は、ローカルの数日以上を失うリスクを防ぐために、ソース管理のどこかで頻繁に/毎日変更をチェックインする必要があります。働くだけです。）
存続期間の短いブランチ:分離のためにブランチが必要な場合 (複数の開発者が作業する必要がある破壊的な機能など)、存続期間の短い機能ブランチを作成するのが 1 つの良い方法です。ブランチの使用が明確に定義され、時間の経過とともに一意になるブランチの命名規則をお勧めします。
上記のワークフローの主な利点は、顧客の満足度を直接向上させる機能を開発するのではなく、マージ税 (フォワード/リバース (マージダウン/アップ) の統合に費やされる時間) を最小限に抑えることです。
シナリオ例:新しい「クール」機能は、完了するまで既存の機能とビルドを中断します。また、2 人以上の開発者が同じコードベースで共同作業する必要があります (シェルフセットを使用するオプションを排除します)。"Cool" の Dev オーナーCool1という名前のブランチを作成し、機能の最初のバージョンを開発および統合テストします。開発者の所有者は、親の変更を毎日 (絶対に多くても毎週) マージする責任があります。マージの準備ができていることを確認します (親が子 (FI) にマージされ、すべての UT およびコア受け入れテストが実行され、引き続き合格します)。親 (RI) にマージしてから、親ブランチで機能することを確認し (すべての UT およびコア受け入れテストに合格)、Cool1フィーチャー ブランチを削除します (クリーンアップ)。
開発/統合ブランチにマージした後、Cool 機能をより徹底的にテストします。(テスト リソースは限られているため、各ブランチの完全なテスト環境は避けてください。) Cool のバグ修正と戦術的な機能強化/リファクタリングは、Dev ブランチで直接行われます (割り当てられた開発者がチェックイン前に開発/テストをローカライズするのに何日もかかる場合は、シェルフセットを使用します)。後で Cool の大規模な (複数開発者による) リワークが必要になった場合は、新しいCool2ブランチを作成します。
TFS2010 の移動/名前変更 注: TFS 2010 の移動と名前変更の動作は (TFS 2008 から) 変更され、移動と名前変更 = "新しい名前/場所に分岐し、元のアイテムを削除済みとしてマークする" ようになりました。これは、ブランチを別のフォルダーに移動するのではなく、ソース管理 \Dev\ でそれらを表示したくない場合は、非アクティブなフィーチャー ブランチを削除する必要があることを意味します。これはまた、削除されたフォルダーを表示できる開発者が、これらの削除された (または移動または名前が変更された) 存続期間の短いブランチを常に「ゴースト」として表示し、混乱する可能性があることを意味します。(これにより、履歴を表示したり、削除されたアイテムを元に戻したりできます。)
機能の分岐に代わるものは、機能の切り替え (つまり、機能を使用可能にするかどうかを切り替えるコード内のスイッチ) です。この点で、それらは非常に役立ちます。新しい機能を開発して展開できるようにすることができますが、トグルが...うまくトグルされた場合にのみ利用できます (一言で言えば)。グーグルラボのアイデア全体のようなものだと思います。
ここで注意すべき点は、これらのトグルが開発中に慎重に検討およびテストされていない場合、これらのトグル自体もドラマを引き起こす可能性があるということです。機能を有効または無効にした状態での動作を確認するために実行する必要があるテストの量を事実上増やしています。開発中の機能が複数ある場合は、それらすべてが有効/無効状態のさまざまな組み合わせとどのように相互作用するかを確認する必要があります。
とはいえ、うまく行けば、大きなメリットも得られます。すべての人に影響を与えることなく、特定のユーザー (パワー ユーザー、または機能の擁護者など) に機能をリリースできます。それが問題を引き起こしていると考えられる場合は、何らかの構成要素の存在の DB レコードを変更することで無効にすることができます。
特定の機能がマスターを通過したと見なされたら、トグルを削除してアプリケーション全体の一部にすることをお勧めします。
そうは言っても、機能の分岐が悪いとは思いませんが、ソース管理とマージの概念を全員が理解し、分岐がメイン分岐から外れすぎて 1 つの大規模な OMG タイプが発生しないようにすることに依存しています。マージ。
私は最近、Thoughtworks が主催する会議に出席し、Martin Fowler がまさにこのトピックについて議論しました。講演では、継続的デリバリーと、これが遅くてリスクのある展開を克服する方法に焦点が当てられました。詳細については、 http: //www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops を参照するか、継続的配信を検索してください。
独自のブランチでマージ ターゲットに取り組むチームが多ければ多いほど、競合に対処するためのコミュニケーションを改善する必要があります。
コード内の高チャーン、結合、および共通領域に注意してください。それらは論争の領域になります。
機能による分岐は TFS で効果的に行うことができますが、dev のすべての場合と同様に、より複雑になるほど、発生するオーバーヘッドが増えます。