3

私たちのWindows成果物には、さまざまな顧客向けにさまざまな構成ファイルとバイナリアセットのセットがあります。現在、構成はパッケージ化の前に手動で行われ、エラーが発生しやすくなっています。顧客ごとにブランチを使用し、パッケージビルド/スクリプトで顧客のブランチをトランクと自動マージすることについてどう思いますか？

私は、この自動化されたASAPを入手するよりも、スケーラビリティに関心がありません。

packagの内容全体がSVNに含まれていますが、SVNの分岐とマージは非常にデリケートなため、自動化されたときに一貫して機能するとは思えません。皆さんがこのアイデアを気に入ったら、私はこれにgit-svnを使用しようとするかもしれません。これにより、マージの繊細さが軽減されることを願っています。アセットは、インストーラーが不適切なディレクトリツリーをスキップできるように編成されているため、必ずしもマージする必要はありませんが、構成はそれほど単純ではありません。

4

3 に答える 3

2

それは、どれだけ多くのことを変更しなければならないかによると思います。構成ファイルについては、単一のファイルをソース管理下に置き、ビルド スクリプトを使用して環境固有 (またはこの場合はクライアント固有) の項目を設定するのが好きです。

http://automaticchainsaw.blogspot.com/2008/02/automate-config-changes-for-different.html

バイナリの場合、それはおそらくあなたが持っているバイナリの数とそれらがどこから来たのかにもっと関係があります. それらがコード コンパイルの一部である場合、理想的には、コンパイル プロセスによって必要なものが作成されます。グラフィックスなどの他のリソースである場合は、1 つのディレクトリの下に顧客固有のフォルダーのセットがある可能性があります。ビルド スクリプトは、スクリプトに渡されたパラメーターに基づいて、正しいクライアント フォルダーを取得します。これは基本的に、質問で言及したブランチとマージのアイデアです。

複数行の構成変更に関する後のコメントについて - それが xml であると仮定すると、MSBuild Community Tasks の XmlMassUpdate クラスを見ることができます。私自身は使用していませんが、必要なもののようです。

于 2008-11-11T16:31:17.833 に答える
0

これは、さまざまな顧客、環境 (QA、ステージング、本番など)、地域 (米国、EU、アジアなど)、またはさまざまなアプリケーション タイプ (モバイル クライアントにサービスを提供しているときにサーバーを構成する必要がある場合) で発生する可能性があります。ウェブやデスクトップではなく）。

通常、人々は（あなたが述べたように）構成ファイルを手動で維持しますが、これはエラーが発生しやすく安全ではありません。または、ペドロが述べたように、ビルドスクリプトを使用して、構成ファイルの内外で適切な値を「覗き見」します。このアプローチは、構成に影響を与えるすべてのコード変更に対して、スクリプトも変更する必要があることを意味しますが、これは理想的ではありません。また、これらのスクリプトのデバッグとテスト (言語に関係なく) は、通常、不可能ではないにしても困難です。

あなたの正確な問題に直面して、クライアントに構成を提供する中央構成サーバーに基づくソリューションを開発しました。サーバーは、値の継承、変更の監査とバージョン管理、テンプレート作成、さらにクライアントにリアルタイムでプッシュされる実行時の変更をサポートします。

このサービスをクラウド ホスト型の構成管理ソリューションとしてリリースする日が近づいています。試してみたい場合は、http: //woot.configchief.com でベータ版にサインアップしてください。

于 2012-01-10T11:21:49.387 に答える
0

どの言語については言及していませんが、条件付きコンパイルを行うことを検討してください:

#If FirstCustomer Then
   ' <code specific to the FirstCustomer version>.
#ElseIf SecondCustomer Then
   ' <code specific to the SecondCustomer version>.
#Else
        ' <code specific to other versions>.
#End If
于 2008-11-11T17:30:59.350 に答える