2

最近のプロジェクトで Mercurial を使用しています。プロジェクトをデプロイしているWebサーバーには、本番設定のわずかに異なる構成ファイルがあります。問題は、私がpullとupdate、しばしば と もしなければならない場合mergeですcommit。

これは正しいワークフローですか? 更新を継続できるようにするために、変更セットをコミットする必要があるのは奇妙に思えます。マージにより、それらが本番ブランチに統合され、更新するたびに継続されると考えました。これは、私がまだ慣れていない分散バージョン管理パラダイムですか?

4

2 に答える 2

5

1 つのオプションは、サーバー固有の展開設定をバージョン管理リポジトリから完全に除外することです。

これは、それらをアップロードしてサーバー上で手動で変更することを意味しますが、常にマージする必要がなくなります。また、データベースのパスワードなどをバージョン管理から除外します。これはおそらく良いことです。

たとえば、Django アプリケーションで作業する場合、次のsettings.py内容を含むファイルをチェックインします。

  • サーバー間で変わらないすべての設定 (サイト名、インストールされている Django アプリなど)。
  • ローカル開発用の「サーバー固有」の設定 (データベースの場所など)。
  • 最後の行from deploy import *。

ファイルが存在する場合、このfrom deploy import *行はファイル内のすべてのアイテムを取り込みdeploy.pyます。テスト/ステージング/運用サーバーでこのファイルを作成し、サーバー固有の設定を内部に配置します。これらの最後にインポートが行われるためsettings.py、メイン設定ファイル内のローカル開発固有の設定が上書きされます。

このようにすると、ローカルで実行および開発するために必要なすべてがバージョン管理にチェックインされますが、サーバー固有の情報や機密情報 (パスワードなど) はチェックインされません (したがって、マージする必要はありません)。セットアップには少し余分な作業が必要です (deploy.py最初にインポート行を追加し、サーバー上にファイルを作成します)。

この特定のスキームは Django プロジェクト用ですが、同様のアイデアがうまくいくかもしれません。

于 2009-12-02T14:17:25.320 に答える
4

これは、この質問で処理されたようなものですが、もう少し明確にするという点で、あなたの質問の方が優れていると思います。

要するに：はい、それは正常です。ここに少し説明があります：

これをメイン リポジトリ (ボックスはチェンジセット) で開始します。

main: --[E]--[F]--[G]

次に、本番サーバーにクローンを作成し、デプロイメントのカスタマイズを行う変更セット H を追加します。したがって、デプロイ リポジトリは次のようになります。

production: --[E]--[F]--[G]--[H]

その後、メイン リポジトリでさらに作業が行われ、変更セット I と J が追加され、メイン リポジトリが次のようになります。

main: --[E]--[F]--[G]--[I]--[J]

本番環境に移行すると、次のようになります。

production:  --[E]--[F]--[G]--[I]--[J]
                            \         
                             \-[H]

マージして取得する 2 つのヘッド:

production:  --[E]--[F]--[G]--[I]--[J]
                            \         \
                             \-[H]-----[K]

ここで、K は単に J に H で最初に行った変更を加えたものです。

main でより多くの作業が行われるようになり、次のようになります。

main: --[E]--[F]--[G]--[I]--[J]--[L]--[M]

これを本番環境で取得すると、次のようになります。

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \
                             \-[H]-----[K]

次に、マージして取得します：

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \         \
                             \-[H]-----[K]-------[N]

したがって、メインから変更を取り込むたびに、マージを 1 回実行し、新しい変更セット (今回は N) を 1 つ作成します。

それが「当たり前」で大丈夫だと思います。

ただし、上記でリンクした質問の回答のいくつかを使用することで回避できます。元の H の親 (およびコンテンツ) を変更し続けるために使用できる新しいトリックがあり、常に最後に移動します新しいヒント。

トリックはRebase Extensionであり、本番環境で線形の履歴が生成されます (ただし、それを取得するために本質的にマージを行う必要があります)。変更セットがコミットされた後に変更するのは好きではないので、私はそれが好きではありませんが、H は本番環境から離れることはないので問題ありません。

他の答えは、mercurial キューであり、本番環境の変更を開発リポジトリでライブにし、本番環境で異なる何か(Host: ヘッダーなど) によってトリガーされます。

于 2009-12-02T04:45:20.817 に答える