問題タブ [branching-strategy]

私が働いている会社は、現在の分岐モデルに問題を抱え始めています。コミュニティはどのような種類の分岐戦略にさらされているのでしょうか?

さまざまな状況に適したものはありますか? あなたの会社は何を使っていますか？それらの長所と短所は何ですか??

Git のチーム作業の原則を理解するのに苦労しています。

Aとの 2 人のプログラマーのチームを考えてみましょうB。彼らはに取り組んでいProjectます。また、レポがあるリモートサーバーもあります。リモートでコラボレーションしていますA。Bリポジトリにはすでにいくつかのコードがあります。

Git で段階的なワークフローを整理するための支援をお願いします。
1. 独自のローカル ブランチを作成する必要がありますか?
2. 本番サーバーに作業コードをアップロードするにはどうすればよいですか? rsync?

どんな助けでも大歓迎です。

Web アプリケーション プロジェクトの最適な分岐戦略を決定しようとしています。これが私がこれまでに思いついたことです。コメントや経験をいただければ幸いです。

私の見方では、「リリースによる分岐」と「機能による分岐」という 2 つの主要な分岐戦略があります。

"Branch by release" : 開発はトランク上で行われます。リリースの時期が近づくと、そのリリース用のブランチが作成されます。その後、このブランチは安定化/テストされ、最終的にリリースされます。リリース後、ブランチはトランクにマージされますが、バグ修正のためにリリース ブランチは維持されます。バグ修正が適用されている場合は、トランクにマージされます (トランクの開発が他の方法でバグを覆い隠していない場合)。新機能はトランクに追加され、リリース ブランチには影響しません。新しいリリース時期が近づくと、新しいリリース ブランチが作成されます。

"Branch by feature" : トランクは常に "production" トランク (ライブのコード) です。バグ修正はトランクに直接コミットされます。次のリリースの機能は機能ブランチで開発されます。バグ修正は時々機能ブランチにマージされます。リリース時期になると、フィーチャー ブランチはトランクにマージされ、ライフ サイクルが継続します。

これら 2 つの戦略の実際的な大きな違いは、「リリースごとに」ソフトウェアのさまざまな製品バージョンを維持できることです (クライアント A がバージョン 1 でクライアント B がバージョン 1.5 の場合、クライアントはこれで有料の顧客です)。場合）。対照的に、「機能別」戦略を使用すると、現在の製品バージョンのみをサポートできます (すべてのクライアントが最新バージョンを使用しています)。

典型的なWeb アプリケーションでは、すべてのクライアントが同じ「最新」バージョンを使用しているため (すべて同じサーバーにアクセスするため)、「機能ごと」のアプローチが最も一般的に使用されていると思います。3 つのリリース バージョンすべてにバグ修正を適用する必要がある場合など、「階層全体」でマージする必要がなくなります。

したがって、私の現在のステータスは、「機能ごとに分岐」する必要があるということです。それが問題なら、私のチームはあまり熟練していません。

過去

Subversion を scm として使用してソフトウェア プロジェクトを開発しています。これまで開発は常に で行われてtrunkいたため、バグ修正リリースが必要になると問題が発生しました。ここで、分岐戦略を再考したいと考えています。要件は次のとおりです。一度に複数の将来のリリースに取り組めるようにしたいのです。

タスク

つまり、現在取り組んでいるバージョンが 1.0 であるとします。次に予定されているバージョンは 2.0、その次のバージョンは 3.0 です。1.0 をリリースしたので、

• バージョン 1.0 を維持する
• 2.0 の機能を開発する
• 同時に 3.0 の機能を開発する

もちろん、1.0 で適用された修正は、他の 2 つのバージョンでも必要です。さらに、2.0 の機能も 3.0 に含める必要があります。また、マイナー リリースが計画されている可能性もあります。たとえば、1.1 には新機能も含まれており、個別に維持する必要があります。

可能な解決策

次の分岐戦略を思いつきました。

• トランクは捨てます
• 新しく計画されたリリースごとに、最後のリリース ブランチに由来するブランチが作成されます。
• 変更は、バージョン タイムラインで「上方」に反映されます

これをもう少し詳しく説明しましょう。この例では、トランクからバージョン 1.0 を分岐します。また、バージョン 1.0 からバージョン 2.0 を分岐し、バージョン 2.0 からバージョン 3.0 を分岐します。1.0 で変更が行われると、2.0 にマージされ、その後 3.0 にマージされます。

質問

これは有効な方法論ですか？技術的にうまくいくでしょうか？組織の落とし穴はありますか？ベストプラクティスはありますか? （インターネットで思いつくのは、「トランクで開発し、リリースブランチで維持する」だけです）。トランクを放棄するのは特に奇妙に思えます-それは間違っていますか?

TFSを使用すると、次のようになります。

• メインベースライン
• 各開発作業の開発ブランチ。これらはベースラインにマージされます。
• リリースごとに作成されるリリースブランチ。バグ修正はここで行われ、リリースされ、ベースラインにマージされます。
• シェルフセットを使用すると、ベースラインを汚染することなく、必要に応じて開発ブランチ間でコードを共有できます。コードレビューに役立ちます。
• 開発の変更をベースラインに配信すると、自動ビルドが開始され、変更がテストサーバーに自動的に配置されます。

問題は、ビジネスアナリストがテストサーバーにアクセスするまで変更を確認できないことです。現在、テストサーバーで変更を取得する唯一の方法は、変更をベースラインにチェックインすることです。したがって、BAが何か問題を見つけた場合、残念ながら、コードはすでにベースラインにあり、それを元に戻すという問題を経験する必要があります。

ベースラインを汚染することなく、BAが見たいものを取得するために、分岐戦略またはプロセスを変更する方法はありますか？

次の要件を備えた専門的な開発セットアップがどのように見えるかについて、いくつかの意見が欲しいです。

• 数人の PHP 開発者 (PHP など)
• 各開発者は 1 つのグループに属します
• 各グループには、タスクを委任するチーム リーダーが 1 人います。
• 各開発者は 1 台の Windows 7 マシンで作業します
• NetBeans または Eclipse で開発
• 各開発者は、コードを実行できる 1 つの仮想テスト サーバーを「所有」します。
• 使用中の VCS は SVN です
• 製品がリリース/デプロイされる前に最終的にテストされるステージング サーバーがあります。

抽象的になりすぎないように特定のテクノロジーをいくつか挙げました。また、プラグインなどの具体的な提案にも興味があります。

そのセットアップで私の頭に浮かぶいくつかの質問があります。

1) したがって、すべての開発者は個人のブランチで作業します。

2) このブランチは作業コピーでチェックアウトされます。

今...この作業コピーは、開発者のIDEを使用してPC上でローカルに編集され、サーバー上で実行/テストされます。

その場合、それを行う最善の/通常の方法は何でしょうか? つまり、オーバーヘッドをあまり発生させずに、編集したコードをサーバーに取得するにはどうすればよいでしょうか?

開発者は自分のローカル ディスクにコードを持っているでしょうか? それとも、トンネルまたは特定のプロトコルを介してリモート仮想サーバーに IDE で書き込みを行う方がよいでしょうか?

3) 開発者は毎日、中央リポジトリにある自分の個人用ブランチに自分の作業をコミットします。

リポジトリの配置場所に関するベスト プラクティスはありますか? 別サーバー？

4) 次に、開発者がタスクを完了した後、開発者またはチームリーダーが新しいコードをそれぞれのメインブランチまたはトランクにマージします。

一番ややこしいのは、2)と3)の間に書いたことについてです。これまでのところ、私はローカルサーバーでしか作業していませんでした. たとえば、共有フォルダーにあるコードを実行するサーバーを備えた VM を直接編集できるようにします。サーバーが実際にリモートになったときに、ギャップを効率的に埋める方法がわかりません。効率的とは、たとえば FTP 経由で手動でアップロードする必要がないことを意味します。

また、外部ソースや書籍の推奨事項も歓迎します。

編集

私の質問は、準標準/ベストプラクティスを目指しています。これはほとんど標準的な開発シナリオだと思うので、「通常の」解決策が必要です。

編集 2

わかりました...画像で試してみましょう：

V は、1 人以上の開発者 D の仮想テスト サーバーです。C と C' は、2 つのコード バージョンです。それらは可能な限り同一に保つ必要があります。

2つの解決策が思い浮かびます：

1 : C を編集して C' にアップロードし、C' を実行してから C をコミットします。

2 : C は存在しません。いくつかのトンネル技術を介して編集され、実行され、コミットされたJust C'。

私の直感では、どちらのソリューションも準最適であると言えます。では、「プロフェッショナル」/最も効率的/最速/最も便利/最も摩擦が少ない/エラーが発生しにくい/ベストプラクティス/業界標準とは何でしょうか?

質問は？

次の状況のベストプラクティスを探しています。

1つのbll/dalプロジェクトと、bll/dalプロジェクトを使用するツリーUIプロジェクトがあります。最初は、すべてをSVNリポジトリの1つのトランクフォルダーに入れました。ユーザーブランチを使用しているため、各ユーザーブランチにはすべてのソースコードがあります。

ここで、TeamCityをビルドサーバーとして使用し始め、各プロジェクトに独自の製品バージョンを持たせたいと考えました。そのため、トランクを異なるSVNリポジトリ（各プロジェクトは別のSVN）に分割し、すべてのプロジェクトがその製品バージョンで独自のリビジョン番号を持つようにしました。

チームシティのプロジェクトごとに継続的インテグレーションと継続的デプロイがあります。4つのプロジェクトで8つの構成が提供されます

ここで、各ユーザーにもブランチのCIが必要です。ただし、プロジェクトごとにユーザーブランチを作成する必要があるため、ユーザーごとに4つのユーザーブランチが作成されます。これには、TeamCityのユーザーごとに4つのCI構成を構成する必要があることも含まれます...

今、私はただ疑問に思っています、これは良いアプローチですか、それともより良い解決策がありますか...？

前もって感謝します。

ブルーノ

以前の仕事では、各開発者が自分のブランチで作業することで、安定したプレリリース ブランチ (またはセットアップに応じてメイン) の管理と維持が容易になることがわかりました。実稼働インスタンスは 1 つしかないため、同じアプリの複数のバージョンをサポートする必要はありません。

この「プレリリース」ブランチは、ステージングおよび本番リリースを作成する別のブランチ (メイン) があったため、そのように名付けられました。ブランチは、プレリリース ブランチのコードのみをリリース ブランチにマージできるようにセットアップされました。これらのマージは、コード レビューのチェックポイントでした。CI ビルドもこのプレリリース ブランチから作成されており、その一連の作業の開発が完了したときに複雑なマージの問題を軽減するために、「プレリリース」から独自のブランチにマージするのは各開発者次第でした。

開発者がペアを組んで特定の機能の 1 つを共同で作業する必要がある場合、開発者自身のブランチのアクセス許可以外に、他の開発者との作業を妨げるものは何もありませんでした。これは、各チーム内の個人が個別/複数の機能に取り組んでいる分散チームを管理する場合にうまく機能しました。

頻繁な (週に 1 ～ 2 回) 30 分間のステータス更新ミーティングの助けを借りて、私たちはチームとして、特定の QA リリースで何を QA に入れ、何を入れないかを決定しました。

このシステムは機能しましたが、このトピックを検索すると、開発者ブランチに対する多くの憤りが見つかりました。git のローカル リポジトリ機能には多くの熱意があるようです。それでも、それらは同じ問題に対処するための異なる方法にすぎないようです。チェックインの遅延など、ローカルリポジトリが対処するクロスネットワークの問題を考慮していません。

そのため、私が維持している従来のASPWebアプリのSCMとしてSubversionを使用しています。機能の分岐を使用して、依存関係や長期的な開発がある変更を処理します。

Dev / QAには共有Webサーバーを使用します。ここで、私の質問が出てきます。中央のDevサーバーはトランクの作業コピーであり、機能ブランチからのDevの変更を確認する必要がある場合は、それらをDevにマージします。作業コピー。これまでのところ良いですが、私は将来的に悪いことに自分自身を設定していますか？

たとえば、今日、アナリストは、機能に加えた変更を「削除」してから、デモのためにDevサイトにマージできると言った。機能が強制終了されたからではなく、見る必要がなかったからだ。もうそれ。そして、私はそれを簡単に行うことができないことに気づきました。マージした変更は、Dev作業コピーにローカルの変更として表示されるだけで、簡単に削除することはできません（完全に元に戻すと、関連する変更が強制終了される可能性があるため、影響を受けるファイルへの変更を手動で元に戻す必要があります）その他の機能）。

書くほど、自分の質問に答えたような気がします。ブランチ戦略を変更する必要がありますか？環境ごとにブランチしますか？または、ブランチごとに個別の「共有開発」サイト（dev.mysite.com:4801、dev.mysite.com:4802）が必要ですか？それとも、これはあなたがこれをどのように扱うのですか？

私は、自分のコードベースに取り組んでいるアウトソーシングされた開発チームを管理することを計画しています。そのチームには、割り当てられたすべての作業をフィーチャー ブランチで作業させます。彼らは、トランクからの変更を毎週マージする責任があります。私自身のチームも、必要に応じてフィーチャー ブランチを引き続き使用します。

特定の分岐戦略を使用してアウトソーシング作業を統合した経験に基づくヒントはありますか?