2

私の質問は、本番環境を適切にバージョン管理するにはどうすればよいですか？

これが現在の環境です。

  • （内部サーバー）開発-バージョン管理されたソースコード
  • （お客様のサーバー）受け入れテスト環境
  • （カスタマーサーバー）ステージング環境
  • （お客様のサーバー）本番環境

受け入れテスト用の新機能をリリースするときは、Visual Studioで公開し、変更を圧縮してテストサーバーに適用します。そこで、バックアップフォルダーを作成し（変更を元に戻すことができるように）、リリースフォルダーを作成して、承認されたときにこれらの変更をステージングに移動できるようにします。

これは、バックアップフォルダーの作成、フォルダーのリリース、ディレクトリ構造の再作成、およびリリースに含まれる機能の追跡を試みるための多くの手作業です。それは面倒であり、リリース手順に従わない開発者には常に問題があります。

理論的には、テスト環境用のリポジトリを作成できます。（ソースコードを忘れてください。これは公開されたアプリケーションに関するものです）リリースごとに、開発者はコミットを行い、リリースしている機能についてコメントを提供します。

機能をテストからステージングに移動する必要がある場合は、ステージング環境が最後に更新された日付から行われた変更をエクスポートし、ステージングアプリケーションにコピーします。そこで、本番環境にリリースするために後で抽出できるコミットを実行します。

これの欠点は、Subversionを使用すると、アプリケーションがそれらの.svnディレクトリで乱雑になることです。これは、IISまたはweb.config内のこれらのディレクトリへのアクセスを禁止することで修正できます。別の解決策は、アプリケーションのルートディレクトリの上のディレクトリでGitを使用することです。しかし、Gitは、Windows環境で経験の浅い開発者にとっては扱いにくいものです。

誰かがこの問題の経験がありますか？本番環境をどのようにバージョン管理しますか？リリースを元に戻す必要がある場合、リリース前に作成したバックアップフォルダはありますか？

私はこれについて開発者と話し合いましたが、テスト/ステージング/本番環境のバージョン管理とバックアップにSubversionを使用しても問題はありません。まったく逆に、新しい機能をリリースする必要があるたびにリリース/バックアップフォルダを作成しないことを喜んでいます。

同時に、これについていくつかの不安があります。アプリケーションをバージョン管理システムに配置しているため、これについて聞いたことはありません。欠点が何であるかはわかりません。

このようなシナリオの経験があれば、喜んでお聞きします。

ミカエル・ルンディン

4

4 に答える 4

2

別の方法は、ビルドサーバーを使用することです。コードをチェックインするたびに、ビルドサーバーは開発環境内で新しいビルドをビルドしてパッケージ化します。次に、デプロイ可能なパッケージをコードとともにチェックインします。

その後、パッケージ化されたビルドを他の環境にデプロイできます。このように、メインリポジトリにすべてのビルドされたバージョンがすでにあるため、そこにバージョンをバックアップする必要はありません。展開が完全に自動化されており、1つのコマンド（PowerShell？）で実行できることを確認すると、サーバーにバックアップを保持する必要がなくなります。

これは、実際には、提案するソリューションよりも優れており、保守が容易です。ビルドのすべてのバージョンがコードと一緒に保持されるため、ビルドパッケージの完全な開発環境をいつでも見つけることができます。サーバーを個別にバージョン管理していて、どこかでバグを見つけた場合、バグの原因となっているコードのバージョンを見つけるのは難しいかもしれません。

于 2008-11-05T08:45:23.017 に答える
1

さまざまなサーバー（prod、demo、devなど）に物事をデプロイする方法としてsubversionを使用しており、問題は発生していません。注意すべき点は、データベースの違いと構成ファイルの違いだけです。構成ファイルは、それぞれの異なるデプロイメントでファイルを上書きしないようにテンプレート化できますが、その場合、その特定のプラットフォームへの変更に対してバージョン管理されません。

この種のシステムでは、subversionのタグを利用して、特定のデプロイメントバージョンに簡単に更新/ロールバックできます。

于 2009-02-26T23:04:46.170 に答える
1

私は本番バージョン管理システムとしてMercurial （Hg）を使用しています。（コードではなく、実際にデプロイされたバイナリ）。それは非常にうまく機能します。Subversionをシナリオで使用するのは適切ではありません。本番環境の変更（構成ファイルなど）をテストや開発に同期できるようにしたいからです。Subversionは、異なるリポジトリ間で同期/マージするのが困難です（多くの手動で対処します）。また、hgタグとhgアップデートを使用すると、安定した（または不安定な）タグに簡単に戻すことができます。

ああ、私は完全に同意します。ビルドサーバー（cruisecontrol.net）などを使用して、すべてのものをそこに保持する必要があります。私のシナリオでは、顧客の本番システムの構成はカスタム固有であり、広範なテストを行っても、2つのリリース間（または次のリリース間で同じことを行わない構成）が存在する可能性があるため、十分ではありません。データが大幅に変更されました）

于 2008-11-05T08:43:07.157 に答える
0

回答と提案をありがとうございます。

これらの環境へのリリースを処理する方法を再考する必要があることがわかりました。これまでに作成されたすべてのリリースを含むビルド サーバーを用意することで、問題の一部を解決できます。ソース コードのコミット コメントを取得し、どの機能をどのビルドに組み込むかをより適切に制御できます。何か問題が発生した場合にリリースを元に戻すことができるように、どのビルドがどの環境にあるかを追跡する必要があります。

@Jonke Mercurialを見ていきます。各リビジョンにバージョン管理されたソース コードがあるビルド システムがある場合、バージョン管理された運用環境は過剰かもしれません。しかし、新しい機能の展開中に何か問題が発生した場合に、変更を以前のリビジョンにすばやく戻す方法が必要です。また、サーバー上でバージョン管理された構成ファイルを取得する方法も気に入っています。これは、運用環境の構成が開発環境とは常に異なるためです。

多分私は銀の弾丸を探しています:)

于 2008-11-11T08:05:40.757 に答える