2

メインリポジトリは、すべての開発者がチェックインする場所であり、 http：//hg.main.com：8000 /projectにあると言います。

現在、http：//hg.qa.com： 8000 / projectもあり、すべてのLATESTコードを同期する必要があります。さらに、テストやその他のアーティファクトがこのリポジトリにあります。これは、テストの85％が合格した場合にのみ、中央リポジトリに「プッシュ」されます。

  1. これを実装するためのより良い方法はありますか？
  2. 最新のコミットを上書きしないようにするために必要なhgコマンド
4

1 に答える 1

0

似たようなことから始めましょう: 承認管理: 監査と QA

誰のため？

開発者のチームと別の QA チームを使用して、完全な実績を持つ明示的に承認されたコード履歴が必要な場合は、このワークフローが適している可能性があります。

要件

Mercurial (コマンド ライン)、データ交換用の共有リポジトリ (単一のプライベート bitbucket リポジトリと同様に、単純な SSH サーバーで十分です)、および GpgExtension だけが必要です。

フロー

このワークフローでは、開発用のデフォルト ブランチと、QA という名前のブランチおよびリリース ブランチを使用します。

利点は、デフォルトを QA にマージするには明示的なマージが必要であり、その後、それを担当する開発者によって GPG 署名される可能性があることです。

QA が変更の適用を完了すると、最初にデフォルトにマージして (開発者が QA バージョンで作業できるように)、リリースにマージし、GPG がマージ コミットに署名します。

デベロッパー

hg pull # 最新の変更を取得
hg アップデート
hg commit -m ""
hg update -C QA
hg マージ デフォルト
hg commit -m "QA 用にマージされたデフォルト ブランチ"
hgサイン
hgプッシュ

QA

hgプル
hg 更新 QA
hg commit -m "QA 修正"
hg update -C デフォルト
hg マージ QA
hg ci -m "QA 修正を開発ブランチにマージしました"
hg update -C リリース
hg マージ QA
hg commit -m "完成した QA をリリースにマージ"
hgサイン

変更

開発者と QA 以外の層が必要な場合は、リリース前に staging-release などの名前付きブランチを追加するだけです。

コードがすべての人によって実際にチェックされていることを確認するには、上位のリポジトリに入るために、すべてのヘッドが GnuPG 署名されている必要があることを要求できます。

于 2011-03-22T20:12:24.803 に答える