4

リリースをどのように追跡していますか?

現在、2つの主要な支店があります

  • 開発者
  • リリース

複数の人による進行中の開発は、常に で行われdevます。十分な量の変更が行われると、コードが にマージされrelease、そこからビルドされ、タグ付けされます。次に、コードがデプロイされます。

問題:これは問題なく動作しますが、多くの場合、現在 dev ブランチで処理されている新しいバグが発生します。問題が修正されると、顧客に提供される新しいビルドには多くの場合、修正といくつかの新しい機能の両方が含まれます。

プロセスを次のように変更したいと思います。

  • current <- 現在の開発ストリーム、最新かつ最高、まだデプロイされていない
  • prod <- 現在 prod にあり、dev/1.0.2 からマージされました
  • dev/1.0.0 <- 少し前にビルドされ、製品に配信されました
  • dev/1.0.1 <- 以前のビルドのバグ修正、ビルドして製品に配信
  • dev/1.0.2 <- 以前のビルドのバグを修正し、ビルドして製品に配信します。現在生産中

どう思いますか？この傾向は機能し、長期的に持続可能でしょうか? 私たちは年間約 15 回のリリースを行っており、リリースごとに少なくとも 2 ～ 3 回の修正が必要な製造後の事故が発生しています。除去される）

4

1 に答える 1

4

複数の人が新しい機能 (および既存の機能の改善) に取り組んでいて、全員が dev ブランチを使用してコードをコミットしている場合、dev ブランチが安定していることを確認することはできません。開発者が機能ブランチを使用して新しい機能を構築し、機能が完成したときにのみそれらを dev ブランチにマージする場合、dev ブランチは常に安定している必要があります。(その後、機能ブランチも削除できます。)

の解が好きですgit flow。マスター (運用) ブランチと開発ブランチがあります。また、新しい機能に取り組むことができる機能ブランチと、本番環境で修正する必要があり、次のリリースまで待てない問題のホットフィックス ブランチもあります。

于 2012-08-04T21:16:45.690 に答える