6

gitflow は私たちのニーズに適合し、giversion は gitflow に適合しているようです。しかし、私が完全に理解していないことが1つあります。何が私を悩ませているのか説明しましょう。

  1. 私たちは開発ブランチでいくつかの機能に取り組んでいます - すべてのパッケージはこの 1.3.0-unstable.1、1.3.0-unstable.2 などのようにマークされています。
  2. すべてのパッケージは、開発、テスト、uat、製品などのパイプラインを通過します。
  3. したがって、開発の準備が整い、すべてが良好な状態になったら、gitflow に従ってリリース ブランチを開始します。
  4. リリース時に変更を行う必要はありません。すぐに終了します - リリース ブランチはマスターと開発にマージされます。
  5. ビルド サーバーは、もう 1 つのパッケージ 1.3.0 を作成します。これは、prod 対応の一種です。

ビルドを一度達成するには、ここで多くを展開しますか? すべてのルールに従って、1.3.0-unstable.x を prod env に昇格する必要があります。これは、このパッケージが開発およびテストでテストされたためですが、prod のバージョンは少し奇妙に見えますよね? master ブランチから来た 1.3.0 がどこにもデプロイされなかったとき。

質問はこれに似ています: git フロー モデルでは、マスターのマージ コミットからリリースまでビルドする必要がありますか?

答えは本当に満足のいくものではありません:

  1. マスターへのマージ中に -no-ff を実行します
  2. 相変わらずパッケージが違う
4

1 に答える 1

1

この質問に自分で答えさせてください。gitflow を使用して複数のバージョン/複数の環境をサポートすることは大きな負担であることに気付きました。したがって、よりシンプルなもの、つまりgithub flowを探していました。もちろん、元の問題 (1 回のビルドで多数のデプロイ) が完全に解決されたわけではありませんが、これで部分的に解決できました。

パイプラインが変わりました

from: dev -> test -> uat -> prod

to: dev -> test そして uat -> prod

前に言ったように、私たちは github フローを使用しています。新しい機能に取り組んでいるときはいつでも、最初に最新のマスターからブランチ機能名を作成します。このブランチからのすべてのビルドは、この 1.3.0-featurename.1、1.3.0-featurename.2 などのようにバージョン管理されます。

開発者が実装を完了し、すべての開発チェックを行うと、これらの正確なバイナリが QA のためにテスト環境に送られます。QA 担当者がこのバージョンを承認した後、2 番目のパイプライン uat -> prod を通じてこれをプッシュします。featurenameブランチのプル リクエストと、後で取得したビルド バージョンをマージします。たとえば、1.3.1 は uat 環境に移動します。そこでサインオフしたら、まったく同じバイナリを本番環境にプッシュします。

同時に開発中の機能ブランチが複数ある場合、テスト環境にプッシュする次のバージョンは、最新のマスターの上にリベースされ、再びパイプラインを介してリベースされます。

于 2016-11-15T20:04:19.953 に答える