継続的インテグレーションを行う場合に使用する最適な分岐戦略は何ですか?
これらの両方の戦略を一緒に使用することは理にかなっていますか? のように、リリースごとに分岐しますが、大きな機能にも分岐しますか? これらの戦略の 1 つは、継続的インテグレーションとうまく調和しますか? 不安定なトランクを使用している場合でも、継続的インテグレーションを使用することは理にかなっていますか?
日常業務でブランチに大きく依存しているため、このトピックは非常に興味深いものです。
リンクが興味深いものであることを願っています。
答えは、チームの規模とソース管理の品質、および複雑な変更セットを正しくマージする能力によって異なります。たとえば、CVS や SVN のような完全なブランチ ソース管理では、マージが困難な場合があり、最初のモデルの方が適しているかもしれませんが、IBM ClearCase のようなより複雑なシステムを使用し、チームの規模が大きい場合は、2 番目のモデルの方が適している可能性があります。モデルまたは 2 つの組み合わせ。
個人的には、機能ブランチ モデルを分離します。このモデルでは、各主要機能が個別のブランチで開発され、個々の開発者が行う変更ごとにタスク サブブランチが作成されます。機能が安定すると、トランクにマージされます。トランクは適度に安定しており、常にすべての回帰テストに合格しています。リリース サイクルの終わりが近づき、すべての機能ブランチがマージされると、安定性のバグ修正と必要なバックポートのみを行うリリース システム ブランチの安定化とブランチ化が行われ、トランクは次のリリースの開発に使用されます。新しい機能ブランチのために分岐します。等々。
このようにして、トランクには常に最新のコードが含まれますが、大幅な変更と機能のマージで安定したラベル (タグ) を作成して、適度に安定した状態に保つことができます。機能ブランチから更新され、同じ機能に取り組んでいる全員を同期させながら、同時に異なる機能に取り組んでいる他のチームに影響を与えません。
同時に、一連のリリース ブランチの歴史を通じて、何らかの理由で製品の以前のバージョンまたは最新のリリース バージョンにとどまっている顧客に、バックポート、サポート、およびバグ修正を提供できます。トランクと同様に、リリース ブランチに継続的インテグレーションを設定する必要はありません。すべてのリグレッション テストとその他のリリース品質管理に合格すると、慎重に統合されます。
何らかの理由で 2 つの機能が相互に依存しており、相互に変更を加える必要がある場合は、同じ機能ブランチで両方を開発するか、コードの安定した部分をトランクに定期的にマージしてから変更を更新することを機能に要求することを検討できます。トランクブランチ間でコードを交換するトランク。または、これら 2 つの機能を他の機能から分離する必要がある場合は、それらの機能ブランチを分岐させ、機能間でコードを交換するために使用できる共通のブランチを作成できます。
上記のモデルは、開発者が 50 人未満のチームと、まばらなブランチと CVS や SVN のような適切なマージ機能のないソース管理システムではあまり意味がありません。このモデル全体をセットアップ、管理、統合するのは悪夢です。
個人的には、安定したトランクを持ち、機能の分岐を行う方がはるかにクリーンだと思います。そうすれば、テスターなどは単一の「バージョン」にとどまり、トランクから更新して、コードが完成した機能をテストできます。
また、複数の開発者がさまざまな機能に取り組んでいる場合は、それぞれ独自のブランチを持ち、完了したらトランクにマージして、テスターが複数のブランチに切り替えてさまざまな機能をテストすることなく、テストする機能を送信できます。
追加のボーナスとして、自動的に行われるある程度の統合テストがあります。
各開発者が毎日トランク/メインラインにコミットする重要な原則の 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/
アプリの複数のバージョンを維持する必要がある場合、リリース ブランチは非常に便利であり、絶対に必要です。
フィーチャー ブランチも非常に便利です。特に、ある開発者が大きな変更に取り組む必要があり、他の開発者がまだ新しいバージョンをリリースしている場合に便利です。
したがって、私にとって両方のメカニズムを使用することは非常に優れた戦略です。
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 による次の記事を読んでください。メインライン モデルを継続的インテグレーションに関連付けるのに役立ちます。
チームを立ち上げたとき、私たちが担当しようとしていたシステムを最初に開発したベンダーから、リリースベースの戦略を継承しました。いくつかの開発された機能をリリースに含めるべきではないという顧客の要求があったときまで、それは機能していました (約 25 万行のコード、約 2500 ファイル、XP SDLC を使用したスクラム)。
次に、機能ベースのブランチを検討し始めました。これもしばらくの間機能しました - 回帰テスト プロセスに 2 週間以上かかることが判明するまで 2 か月ほどかかり、何がリリースされるかについての不確実性と相まって、大きな不便が生じました。
純粋な SC 戦略の最終的な「棺桶の釘」は、1. 安定したトランクと 2. プロダクションに ST、UAT、および回帰テスト済みのバイナリ (ソースだけでなく、CC を考えてください) を含める必要があると決定したときに起こりました。
これにより、機能ベースの SC 戦略とリリース ベースの SC 戦略を組み合わせた戦略を考案することになりました。
だから私たちはトランクを持っています。スプリントごとにスプリント ブランチを分岐させます (アジャイルではない人にとっては、スプリントは、複雑さに応じて可変出力を使用する時間制限付きの開発作業です)。スプリント ブランチから機能ブランチを作成し、そこで並行開発を開始します。機能が完成し、システムがテストされ、それらを展開する意図を受け取ると、それらはスプリント ブランチにマージされます。一部の機能は、複数のスプリントにまたがる場合があり、通常はより複雑なスプリントになります。スプリントが終わりに近づき、機能が完成したら... スプリント ブランチを「リグレッション」に「名前変更」し (これにより、CruiseControl が再構成なしでそれを選択できるようになります)、その後、cc-built でリグレッション/統合テストが開始されます。耳。それがすべて完了すると、生産に入ります。
つまり、機能ベースのブランチは、開発、システム テスト、および UAT 機能に使用されます。スプリント ブランチ (実際にはリリース ブランチ) は、オンデマンド機能と統合テスト機能を選択的にマージするために使用されます。
ここでコミュニティへの質問です。開発が多くのブランチで行われるという事実と、CruiseControl の再構成のオーバーヘッドが原因で、明らかに継続的インテグレーションの実行に問題があります。誰かが提案してアドバイスできますか？
私の見方では、集中できるブランチのセットを制限したいと考えています。テスト、コード品質メトリック、およびビルドで実行する多くの興味深いものが必要なため、レポートが多すぎると、情報を見逃してしまう可能性があります。
いつ、何を分岐するかは、通常、チームの規模と開発中の機能の規模によって異なります。黄金律はないと思います。フィードバックを早期に/頻繁に得ることができる戦略を使用するようにしてください。これには、機能の最初から品質を含めることが含まれます。品質ビットとは、チームの開発に合わせて自動化するときに、チームが構築している大規模な機能セットに分岐する場合、チームにも品質を関与させる必要があることを意味します。
psこれらのアプローチリファレンスはどこで入手しましたか？-それらのグラフがすべてのオプションを表しているとは思わない
更新1：それがゴールデンルールではないと言った理由を拡張します。基本的に、比較的小規模なチームの場合、混合であるアプローチを使用するのが最適であることがわかりました。機能ブランチは、それが長いものである場合に作成され、チームの一部は引き続き小さな機能を追加します。