0

私のチームは HG を使用して 3 つの異なる環境を開発しています (それぞれが独自のブランチです)。

  • リリース（稼働しているもの）
  • QA (テスト対象)
  • Dev (開発しているもの)

QA が変更のバッチで完了したら、QA を Release にマージします。次に、Dev を QA にマージします。リリースに直接コミットされるホットフィックスがリリースで必要になる場合があります。その後、リリースは QA にマージされ、QA は開発にマージされます。

このワークフローは、1 つの詳細を除いて、非常にうまく機能しています。私たちのビルド システムは、ブランチごとに異なる Maven 依存関係を参照します。たとえば、QA では、ビルド ファイルは次のようになります。

// build.gradle
apply plugin: 'java'

dependencies {
    // This dependency shouldn't ever change during a merge.
    compile 'internal.lib:lib-qa:1.0'
}

リリース時には、次のようになります。

// build.gradle
apply plugin: 'java'

dependencies {
    // This dependency shouldn't ever change during a merge.
    compile 'internal.lib:lib-release:1.0'
}

何らかのマージ (ホットフィックスまたは通常) を行うと、Mercurial は次のような行を変更します。

    compile 'internal.lib:lib-release:1.0'

マージをコミットする前にこの変更を手動で元に戻すことができますが、最終的にリリースを忘れて壊れてしまうため、この手順は避けたいと思います。このステップを不要にするための練習やコツはありますか?

これまでに思いついた最善の方法は、ビルドでブランチをチェックしてから、使用する依存関係を動的に決定することですが、ビルドが HG に依存するようになるため、満足のいくものではありません (Gradle Eclipse で問題が発生しました)。 Gradle で HG が必要な場合、プラグインは正しく機能しません)。

4

1 に答える 1

1

Gradle Eclipse の問題と、バージョン管理のクエリに基づいて依存関係を動的に選択する問題が何であるかはよくわかりませんが、解決できるはずだと思います。いくつかの他のアプローチ:

  • リリースの開始時やマージを行った後など、特定の時点でのみ実行される (およびバージョン管理をクエリする) 検証タスクを記述します。
  • ビルド スクリプトでブランチ タイプをエンコードします (たとえば、バージョン番号の一部として)。次に、マージで1行だけを取得する必要があります（常に同じ行です）。
  • 外部からブランチ タイプを挿入し (デフォルトは dev)、それに応じて CI ビルドを構成します。
于 2013-10-02T20:51:00.147 に答える