[解決済み] 開発コードと本番コードのメンテナンスはどのように行っていますか？[クローズド］

質問

コードをメンテナンスする際に従うべきベストプラクティスやルールオブサムは何でしょうか？ 開発ブランチに生産準備の整ったコードだけを置くのは良い習慣でしょうか、それともテストされていない最新のコードも開発ブランチで利用できるようにすべきでしょうか？

開発コードと本番コードをどのようにメンテナンスしていますか？

編集 - 補足質問 - あなたの開発チームは、開発ブランチにコードをコミットする際に、 "commit-as-soon-as-possible-and-often-if-the-code-contains-minor-bugs or-is-incomplete" プロトコルと "commit-ONLY-perfect-code" プロトコルに従いますか?

どのように解決すればよいですか?

2019年にアップデートします。

最近では、この質問はGitを使った文脈で見られると思いますが、その10年前の ディストリビュート 開発 ワークフロー (主に共同作業 GitHub を通して ) は、一般的なベストプラクティスを示しています。

• master はいつでも本番環境にデプロイできるブランチです: 次のリリースで、選択された機能ブランチのセットがマージされます master .
• dev (または統合ブランチ、または ' next ') は、次のリリースで選択された機能ブランチが一緒にテストされるものです。
• maintenance (または hot-fix ) ブランチは、現在のリリースの進化やバグフィックスに対応するブランチです。 にマージされる可能性があります。 dev と master

そのようなワークフロー（マージしない dev を master に、しかし、featureブランチのみをマージする場合は dev に、そして選択された場合は master に変更されます。これは、次のリリースに間に合わない機能ブランチを簡単に削除できるようにするためです。 gitworkflow (1つの単語 ここに図示されている ).

さらに詳しく見る rocketraman/gitworkflow . この対Trunk-Based-Developmentの歴史は、コメントやディスカッションで Adam Dymitruk によるこの記事 .

^{(出典 Gitworkflow: タスク指向の入門書 )}

注意: この分散型ワークフローでは、いつでも好きなときにコミットし、個人用ブランチに WIP (Work In Progress) をプッシュすることができます。

元の回答 (2008年10月、10年以上前)

それはすべて リリース管理のシーケンシャルな性質

まず、トランクにあるすべての は本当に次のリリースのために ? 現在開発されている機能のいくつかはそうであることがわかるかもしれません。

• あまりにも複雑で、まだ改良が必要
• 時間的余裕がない
• 面白いけど、この次のリリースには使えない

この場合、トランクには現在進行中の開発作業が含まれているはずですが、次のリリースの前に早期に定義されたリリースブランチは、次のような役割を果たすことができます。 コンソリデーションブランチ このブランチでは、適切なコード (次のリリースのための検証済み) のみがマージされ、次にホモロゲーションフェーズで修正され、最後に生産に入るときに凍結されます。

実稼働コードに関して言えば、あなたはまた、あなたの パッチ ブランチ を念頭に置きながら、それを管理する必要があります。

• 最初のパッチのセットは、最初の本番リリースより前に開始されるかもしれません (つまり、時間内に修正できないバグがある状態で本番に入ることは分かっていますが、それらのバグに対する作業を別のブランチで開始することができます)。
• 他のパッチブランチは、明確に定義された本番用ラベルから開始する余裕があります。

開発ブランチに関しては、他に必要な開発作業がない限り、トランクを1つ持つことができます。 を並行して行う必要がある場合を除きます。 のようなものです。

• 大規模リファクタリング
• 他のクラスでの呼び出し方法を変更する可能性のある新しい技術ライブラリのテスト
• 重要なアーキテクチャの変更を組み込む必要がある、新しいリリースサイクルの開始。

さて、開発-リリース サイクルが非常に順次的である場合、他の回答が提案するように、1 つのトランクと複数のリリース ブランチを作成することができます。これは、すべての開発が次のリリースに移行することが確実な小規模なプロジェクトでは有効であり、凍結してリリース ブランチの出発点とし、そこでパッチを適用することができます。これは一般的なプロセスですが、より複雑なプロジェクトになると...もう十分ではありません。

Ville M.さんのコメントにお答えします。

• 開発ブランチは「開発者ごとにひとつのブランチ」ではなく、「開発作業ごとにひとつのブランチ」であることに留意してください (そうすると、各開発者が他の開発者の作業を見る/取得するためにマージしなければならなくなり、「マージマニア」を誘発します)。
• これらの作業を trunk (またはあなたが定義した他の "main" やリリースブランチ) にマージする必要がある場合、これは開発者の作業となります。 ではなく - 繰り返しになりますが、SC マネージャーの仕事ではありません (SCマネージャーは競合するマージを解決する方法を知らないでしょうから)。プロジェクト リーダーはマージを監督することができ、時間通りに開始/終了することを確認します。
• 実際にマージを行うために誰を選んでも、最も重要なことは。
  • マージの結果をデプロイ/テストできるユニットテストおよび/またはアセンブリ環境を持っていること。
  • タグを定義する必要があります。 の前に は、マージが複雑すぎたり解決に時間がかかったりした場合に、前の状態に戻ることができるようにするために、マージの始まりに設定します。