4

私たちは svn から hg へと夢中になりました。開発ワークフローは多かれ少なかれ洗い流されているため、ステージングと統合システムという最も難しい部分が残っています。

願わくば、この質問が、よくある「xxx から Mercurial に移行するにはどうすればよいですか」よりも少し進んでいるといいのですが。長くて、おそらく文章が下手な質問を許してください:)

私たちは多くのプロジェクト (主に PHP と Zend) を行う Web ショップであるため、100 以上のフォルダーを持つ 1 つの巨大な svn リポジトリがあり、それぞれが独自のタグ、ブランチ、トランクを持つプロジェクトを表しています。私たちの統合およびテスト サーバー (QA とクライアントが作業結果とテスト内容を確認する場所) では、すべてがほぼ自動化されています。mysql 移行スクリプトもトランクにあり、開発者は単純な Web インターフェイスを介してそれらを適用できます。簡単に言えば、ワークフローは次のようになります。

  1. コードのチェックアウト、作業、コミット
  2. Web インターフェイスを介してサーバーで更新を実行します (これは基本的に、特定のプロジェクトのサーバーで svn を実行し、必要に応じて db-migration スクリプトも実行します)。
  3. サーバー上の QA の変更

このアプローチは、2 人以上の開発者が同じコードで作業している大規模なプロジェクトには最適ではありません。svn での分岐は頭痛の種になるだけだったので、Mercurial に移行しました。そして、ここに問題があります - このタイプの作業のために効率的なステージング/統合/テストサーバーをどのように編成しますか (多くのプロジェクトがある場合、1 人の開発者が 1 日に 3 つの異なるプロジェクトに取り組んでいるとします)。

基本的に「デフォルト」のブランチ トラッキング プロダクションを使用し、個々のブランチですべての変更を行うことにしました。この場合、各ブランチのステージング更新を自動化するにはどうすればよいでしょうか? 以前は、1 つのプロジェクトでほぼ常にトランクで作業していたので、1 つの DB、1 つの vhost などが必要でした。現在、プロジェクトごとの N データベース、N vhost 構成などについて話している可能性があります。 phpDocumentor や単体テストを実行している)？「デフォルト」でのみ行う必要がありますか？枝に？

他のチームがこの問題をどのように解決しているのか、おそらく私たちが使用していない、または見落としていないベスト プラクティスでしょうか?

その他の注意事項：

おそらく、レポ ホスティング サービスとして Kiln を選択したことに言及する価値があるでしょう (主に、とにかく FogBugz を使用しているため)。

4

2 に答える 2

3

これは、最終的に選択する完全な答えではありませんが、考慮に入れる可能性が高いいくつかのツールを次に示します。

  • 作業ディレクトリのないリポジトリ - 作業ディレクトリのないリポジトリ (.hg のみ) を取得したclone -U場合。hg update nullサーバーの方が場所を取らず、誰もそこで編集しようとしないので、サーバーの方が優れています。
  • changegroupフック

最後の 1 つについては、changegroupプッシュまたはプルによって 1 つ以上の変更セットが到着するたびにフックが実行され、次のような興味深いことを行うことができます。

  • 到着したものに応じて、変更セットを別のレポにプッシュします
  • 受信レポの作業ディレクトリを更新する

たとえば、上記のツールのみを使用して、次のようなことを自動化できます。

  1. 開発者は、5 つの変更セットを central-repo/project1/main にプッシュします
  2. 最後の変更セットはブランチ 'my-experiment' にあるため、csets はオプションで作成されたリポジトリ central-repo/project1/my-experiment に自動的に再プッシュされます
  3. central-repo/project1/my-experiment は、ブランチhg update tipに確実にあるものを自動的に実行しますmy-expiriment
  4. central-repo/project1/my-experiment は、その作業ディレクトリでテストを自動的に実行し、テストに合格すると、デプロイする「make dist」を実行します。これにより、データベースと vhost もセットアップされる可能性があります

大事なことは、mercurial book の第 10 章でこれがカバーされていますが、ユーザーがそのプロセスを待たないようにすることです。おそらく大丈夫なコードを含むリポジトリにユーザーにプッシュしてもらい、自動化されたプロセスがCIを実行して作業をデプロイします。これが成功すると、おそらく大丈夫なリポジトリになります。

私が働いていた最大のmercurialセットアップ（20人ほどの開発者）では、CIシステム（Hudson）がそれぞれの多分大丈夫なリポジトリから定期的にプルし、ビルドとテストを行い、各ブランチを個別に処理するようになりました.

要するに、必要なものをセットアップするために必要なすべてのツールはおそらく既に存在しますが、それらをつなぎ合わせるのは 1 回限りの作業になります。

于 2010-07-15T21:19:10.600 に答える
2

覚えておく必要があるのは、DVCS (対 CVCS)はバージョン管理に別の次元を導入するということです:もう分岐だけ
に 頼る必要はありません(そして、適切な分岐からステージング ワークスペースを取得します) DVCS を使用すると、公開ワークフロー(レポ間のプッシュ/プル)

つまり、ステージング環境がリポジトリ (プロジェクトの完全な履歴を含む) になり、特定のブランチでチェックアウトされます:
多くの開発者は、多くの異なるブランチをそのステージング リポジトリにプッシュできます: 調整プロセスは、そのリポジトリ内で分離して実行できます。選択した「メイン」ブランチ。
または、レポでそのステージング ブランチをプルして、プッシュ バックする前にテストすることもできます。

代替テキスト
Mercurial HgInitに関する Joel のチュートリアルから

開発者は、他の人が確認できるようにコミットする必要はありません。DVCS での公開プロセスにより、最初にステージング ブランチをプルし、ローカルで競合を調整してから、ステージング リポジトリにプッシュすることができます。

于 2010-07-15T21:08:40.633 に答える