1

ビルド\テストにTeamCityを多用しています。

私が見る限り、TeamCity はパッケージ化と展開のための適切なツールではありません。もちろん、TeamCity によって任意のコマンドライン プロセスを開始できますが、欠けているのは、デプロイ先の「環境」の概念です。

Nolio などの一部のツールには、これが任意の形式で含まれています。たとえば、プロジェクトの環境タイプを定義できます。

 1 app server:
  - IIS web site with:
     - Virtual Dir \ Web Application:
        - App Pool
        - .NET Framework version
  - Windows service with:
    - Name
    - Description

 1 db server:
  - db name
  - db user
  - db password

したがって、すべての環境 (Dev、QA、PreProd、Prod) は、これらのパーツの異なるパラメーターを持ちます。また、パッケージ化ステップ (たとえば、Wix による MSI へ) で、これらのパラメーターを使用して、特定の環境用の MSI を作成できます。たとえば、Web.config の connectionString を更新します。

他のプロジェクトでは、環境の定義が異なる場合があります。このような構造や値を記述するには、おそらく XML 形式が最適でしょう。

このようなものを NAnt スクリプトに実装しました。環境ごとに .build ファイルがあり、フラットな値のリストが含まれています。次に<xmlpoke>、値をWeb.configファイルに入れます。しかし、これを維持するのは非常に困難です。

そのため、TeamCity と統合して (ビルド アーティファクトを取得するため)、それらをインストール可能な MSI にパッケージ化し、環境に簡単にデプロイできるツールを探しています。このようなツールには、この概念「環境」が必要であり、構造を簡単に定義できるようにし (上記の例を参照)、環境インスタンスを追加\変更\削除できるようにし、パッケージ化\デプロイ時にそれらを自動的に使用できるようにする必要があります。

アイデアや経験はありますか？

4

1 に答える 1

1

さまざまな環境への自動および手動の展開は、実際には MSDeploy を使用した Team City と構成変換を使用して行われます。

これは、Troy Hunt による、私が使用した段階的なガイドです: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html

変換構文に関する追加情報は次のとおりです: http://msdn.microsoft.com/en-us/library/dd465326.aspx

このセットアップでは、各環境は、ソリューション内の異なるビルド構成と、特定の構成変換になります。

于 2012-06-22T13:15:13.887 に答える