4

私たちはかなり標準的なmaven-release-pluginスタイルの開発を使用しています。master ブランチには、次のリリースに向けた開発が含まれています (xy-SNAPSHOT とラベル付けされた pom)。コードフリーズに入ると、マスターから分岐してリリースを準備します。このブランチからリリースを実行します。バグはこのブランチで修正されます。

さて、私の質問です。xy リリースの準備をするとき、通常、このリリース ブランチからビルドされた xy-SNAPSHOT に対してテストを行いました。ただし、テストが「合格」したとき、SNAPSHOT ラベルの付いたインストーラーに対して合格したことがわかりました。したがって、リリースを実行するには、コードを変更し (SNAPSHOT ラベルを削除)、新しいリリースを再スピンする必要があります。私たちの意見では、ビルドを再スピンすると、SNAPSHOT に対して行ったすべてのテストが無効になり、最終リリースを再テストする必要が生じました。

何をすべきか？

非 SNAPSHOT ビルドに対してのみ正式なテストを実行することを推奨することを検討しています。本質的に「リリース候補」にバグが見つかった場合は、リリース ブランチで修正し、バージョン xy(z+1) を上げて、再テストします。欠点は、クリーンな xy0 リリースではなく、xyz という名前になったことです。z は、リリース候補の数です。

このようなシナリオの経験がある人はいますか? これは正常なプロセスですか、それとも SNAPSHOT のテストについて過度に反応しているのでしょうか?

4

1 に答える 1

2

There are generally two ways this is handled:

  1. The maven project itself uses the Staging feature of some repository managers to hold the artifacts in a staging area where they can be tested. If the tests fail, the staging repo is dropped, the tag deleted, and the release respun

  2. In other situations the view is that version numbers are cheap (sure there's an infinite supply), so if the release is borked, just respin the next number

The first means you don't need to track which releases are good/bad, but requires people to verify that the correct artifacts are being tested.

The second requires some additional tooling to identify the status of each version and doesn't require modifying tags.

Either works, pick your poison ;-)

于 2013-04-16T21:36:56.053 に答える