継続的インテグレーションを行う場合に使用する最適な分岐戦略は何ですか？
これらの戦略の両方を一緒に使用することは理にかなっていますか？同様に、リリースごとに分岐しますが、大規模な機能にも分岐しますか？これらの戦略の1つは、継続的インテグレーションとうまくかみ合いますか 不安定なトランクを使用している場合、継続的インテグレーションを使用しても意味がありますか？
回答:
私は毎日の仕事で枝に大きく依存しているので、このトピックは本当に興味深いと思います。
リンクがおもしろいと思ってください。
答えは、チームの規模とソース管理の品質、および複雑な変更セットを正しくマージする能力によって異なります。たとえば、CVSやSVNのような完全なブランチソース管理では、マージが困難になる可能性があり、最初のモデルの方がよい場合がありますが、IBM ClearCaseのようなより複雑なシステムを使用し、チームのサイズが大きい場合は、2番目のモデルの方が優れている可能性があります。モデルまたは2つの組み合わせ。
私は個人的に機能ブランチモデルを分離します。各主要機能は個別のブランチで開発され、個々の開発者が行う変更ごとにタスクサブブランチが作成されます。機能が安定すると、トランクにマージされます。トランクはかなり安定していて、すべての回帰テストに常に合格しています。リリースサイクルの終わりに近づき、すべての機能ブランチがマージされると、安定性のバグ修正と必要なバックポートのみを行うリリースシステムブランチの安定化とブランチを行い、トランクは次のリリースの開発に使用されます。新しい機能の分岐のために分岐します。等々。
このように、トランクには常に最新のコードが含まれていますが、かなりの安定性を維持し、大きな変更と機能のマージで安定したラベル（タグ）を作成します。機能ブランチは、ペースの速い開発であり、継続的な統合と個々のタスクのサブブランチが頻繁に発生します。機能ブランチから更新されて、同じ機能で作業している全員が同期し続けると同時に、異なる機能で作業している他のチームに影響を与えません。
同時に、履歴を通じて一連のリリースブランチがあり、何らかの理由で製品の以前のバージョンまたは最新のリリースバージョンにとどまっている顧客に、バックポート、サポート、およびバグ修正を提供できます。トランクと同様に、リリースブランチで継続的な統合を設定するのではなく、すべての回帰テストとその他のリリース品質管理に合格すると、統合が慎重に統合されます。
何らかの理由で2つの機能が相互に依存していて、相互に変更を行う必要がある場合は、両方を同じ機能ブランチで開発するか、コードの安定した部分をトランクに定期的にマージしてから変更を更新するよう機能に要求することを検討できます。トランクブランチ間でコードを交換するトランク。または、これら2つの機能を他の機能から分離する必要がある場合は、それらの機能ブランチを分岐させ、機能間でコードを交換するために使用できる共通ブランチを作成できます。
上記のモデルは、スパースブランチとCVSやSVNのような適切なマージ機能がなければ、50人以下の開発者とソース管理システムのチームにはあまり意味がありません。
個人的には、安定したトランクを持ち、機能の分岐を行う方がずっとクリーンだと思います。このようにして、テスターなどは単一の「バージョン」にとどまり、トランクから更新して、コードが完成した機能をテストできます。
また、複数の開発者が異なる機能に取り組んでいる場合、それらすべてが独自の個別のブランチを持ち、完了したらトランクにマージし、テストする機能を送信することができます。テスターが複数のブランチに切り替えて異なる機能をテストする必要はありません。
追加のボーナスとして、自動的に行われるある程度の統合テストがあります。
各開発者がトランク/メインラインに毎日取り組む主要な原則の1つを覚えていれば、どちらの戦略も継続的な開発で使用できると思います。
http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay
編集
私はこの本を読んでいます CIを、著者はリリースごとのブランチが好ましいブランチ戦略であることを示唆しています。同意する必要があります。CIを使用する場合、機能による分岐は意味がありません。
このように考えている理由を説明します。3人の開発者がそれぞれ機能に取り組むためにブランチをとるとします。各機能が完了するまでに数日または数週間かかります。チームが継続的に統合していることを確認するには、少なくとも1日に1回はメインブランチにコミットする必要があります。彼らがこれを始めるとすぐに、彼らは機能ブランチを作成する利点を失います。それらの変更は、他のすべての開発者の変更と切り離されていません。それで、そもそもなぜ機能ブランチを作成するのが面倒なのでしょうか？
リリースごとのブランチを使用すると、ブランチ間のマージがはるかに少なくなり（常に良いことです）、すべての変更ができるだけ早く統合され、（正しく行われた場合）コードベースが常にリリースできる状態になります。リリースごとに分岐することのマイナス面は、変更にかなり注意する必要があることです。たとえば、大規模なリファクタリングは段階的に行う必要があり、次のリリースで不要な新しい機能をすでに統合している場合は、何らかの機能切り替えメカニズムを使用して非表示にする必要があります。
別の編集
この問題については複数の意見があります。これは、CIで分岐するプロ機能のブログ投稿です。
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
アプリの複数のバージョンを維持する必要がある場合、リリースブランチは非常に便利であり、絶対に必要なものですらあります。
機能ブランチも非常に便利です。1人の開発者が大きな変更に取り組む必要があり、他の開発者がまだ新しいバージョンをリリースしている場合は特にそうです。
したがって、両方のメカニズムを使用することは、非常に優れた戦略です。
Book of SVNからの興味深いリンク。
最近、gitを使用するときにこのモデルが好きになりました。あなたの質問には「svn」というタグが付けられていますが、それでもそれを使用できる場合があります。
継続的インテグレーションは、このモデルの「開発」ブランチ（またはそれと呼ぶもの）である程度発生する可能性がありますが、将来のリリースで長時間実行される機能ブランチを使用しても、コードのどこかで発生するすべての変更を考慮するほど厳密ではありません。あなたが本当にそれを望んでいるかどうかという問題は残っています。マーティン・ファウラーがします。
継続的インテグレーションは、分岐戦略を決定する際のいかなる要因であってはなりません。分岐アプローチは、チーム、開発中のシステム、および使用可能なツールに基づいて選択する必要があります。
そうは言っても ...
このすべては、図を取得したページの4番目の質問で答えられました。http：//blogs.collab.net/subversion/2007/11/branching-strat/
原則を理解している限り、いつでもベストプラクティスを作り直すことができます。原則を理解していない場合、いくつかの競合する外部要件のためにバラバラになる前に、ベストプラクティスでそれが行われます。
メインラインモデルの最適な紹介については、次をお読みください：https : //web.archive.org/web/20120304070315/http : //oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
リンクを読んでください。基本を理解したら、由緒あるHenrik Knibergによる次の記事を読んでください。メインラインモデルと継続的インテグレーションを関連付けるのに役立ちます。
私たちがチームを始めたとき、私たちが担当しようとしていたシステムを最初に開発したベンダーからリリースベースの戦略を継承しました。これは、お客様がいくつかの開発された機能をリリースに含めないように要求するまで機能しました（〜250k行のコード、〜2500ファイル、XP SDLC付きスクラム）。
次に、機能ベースのブランチを検討し始めました。これはしばらくの間も機能しました-私たちの回帰テストプロセスには2週間以上かかることがわかって、リリースされるものの不確実性と相まって、非常に不便を感じるまで2か月かかりました。
純粋なSC戦略の最後の「棺桶の爪」は、1。安定したトランクと2.生産にST、UAT、および回帰テスト済みのバイナリを含める必要があると決定したときに来ました（ソースだけでなく、CCと考えてください）。
これにより、機能とリリースベースのSC戦略のハイブリッドである戦略を考案しました。
トランクがあります。すべてのスプリントは、スプリントブランチから分岐します（非アジャイルの人々の場合-スプリントは、複雑さに基づいてさまざまな出力を持つタイムボックス化された開発作業です）。スプリントブランチから機能ブランチを作成し、それらの並列開発を開始します。機能が完成し、システムがテストされ、展開する意図が得られたら、それらはスプリントブランチにマージされます。一部は、複数のスプリント（通常はより複雑なスプリント）にまたがる場合があります。スプリントが終わりに近づき、機能が完了したら...スプリントブランチを「リグレッション」に「名前を変更」します（これにより、CruiseControlが再構成せずにスプリントを取得できるようになります）。その後、ccビルドで回帰/統合テストが開始されます。耳。それがすべて完了すると、本番環境に移行します。
つまり、機能ベースのブランチは、システムテストとUAT機能の開発、使用に使用されます。スプリントブランチ（実際にはリリースブランチ）は、オンデマンドで機能を選択的に統合し、統合テストを行うために使用されます。
ここでコミュニティへの質問です。多くのブランチで開発が行われ、CruiseControlの再構成オーバーヘッドがあるため、継続的な統合の実行に明らかに問題があります。誰かが提案してアドバイスできますか？
私が見るところ、あなたが集中できるブランチの限られたセットを持ちたいと思っています。テスト、コード品質メトリック、およびビルドで実行する多くの興味深いことをしたいので、レポートが多すぎるとおそらく情報を見逃してしまいます。
いつ、何を分岐するかは、通常、チームの規模と開発中の機能の規模によって異なります。黄金律はないと思います。フィードバックを早く/頻繁に得ることができる戦略を使用していることを確認してください。これには、機能の最初から品質を関与させることが含まれます。品質ビットとは、チームの開発に合わせて自動化しているときに、チームが構築している大規模な機能セットに分岐する場合、チームにも品質が関与する必要があることを意味します。
PSアプローチのリファレンスはどこで入手しましたか？-これらのグラフがすべてのオプションを表すとは思わない
更新1：なぜ私がゴールデンルールではないと言ったのかを拡大します。基本的に、比較的小規模なチームの場合は、ミックスするアプローチを使用するのが最適です。機能ブランチは、それが長く、チームの一部がより小さな機能を追加し続ける場合に作成されます。
Continuous Deliveryの作者であるDave Farleyは、Trunk Based Development（TBD）を継続的インテグレーション（CI）と継続的デリバリー（CD）の基礎として言及しました。彼は言う：
あらゆる形態の分岐は、継続的インテグレーションとは正反対です。
彼はまた言います、
機能の分岐は、個々の開発者の観点からは非常に優れていますが、チームの観点からは最適ではありません。みんながやっていることを無視して、仕事を続けられるようになりたいです。残念ながら、コードはそうではありません。懸念の分離が素晴らしく、コンポーネントの結合が素晴らしく、非常によく分解されたコードベースであっても、一部の変更はシステムの他の部分に影響を与えます。
トランクベース開発（TBD）は、コードの変更を少なくとも1日に1回、できれば1日に複数回、トランク（別名、マスター、メインライン）に統合する方法です。継続的インテグレーション（CI）は、自動化されたテストを使用してコードの変更を検証することを除いて、同様の手法です。このための最良の分岐戦略は、トランクの外で直接作業し、ペアプログラミングを介してコードレビューを実行することです。何らかの理由でペアリングできない場合、または本当にブランチしたい場合は、ブランチの有効期間を短くしてください（1日未満）。
私はGITリポジトリの「マスター」であるTrunkで作業しています。ローカルでマスターすることを約束し、ネットワークに接続したらすぐに、CIが実行されている中央のマスターリポジトリにプッシュします。それでおしまい！
大きな機能（1日以上かかる機能など）の場合は、ソフトウェアを壊さずにトランクに統合できる小さなロジックチャンクにそれらを分解するようにしてください。機能フラグや抽象化による分岐などの技術を使用して、エンドユーザーに影響を与えることなく不完全な作業を展開することもできます。
私は抽象化によるブランチ、ダークリリース、そして時には機能フラグを使用しています。私が見返りに得られるのは、高速で決定的な（少なくとも私のテストの品質に対して）フィードバックです。