このシーンを処理する方法についてのアドバイスを探しています。
Dev、QA、Production の 3 つの環境があります。
現在、コードを各環境にプッシュするのは手動のプロセスであり、Cruisecontrol や TeamCity のようなものがこのプロセスをどのように合理化できるか疑問に思っています。
自動化された方法でさまざまな環境にプッシュするにはどうすればよいでしょうか?
これを実現するには、TFS をどのように設定する必要がありますか? つまり、マスター ブランチ、フィーチャー ブランチなどです。
シーン:
開発者 #1 は、変更を開発サーバーと QA サーバーにプッシュします。開発者 #2 は、変更を Dev および QA サーバーにプッシュします。
これで、Developer#1 の変更を本番環境にプッシュするだけで済みます。
メイン ブランチには、本番環境に移行するコードのみを含める必要がありますか?
各環境に何がプッシュされるかを制御するには、ブランチとマージを使用する KMoraz のアプローチが正しいでしょう。
現在、ビルドとデプロイの自動化のために、私が使用している最新のセットアップは Team City です。
私のセットアップは次のとおりです。
Trunk build : コミットごとにコンパイルし、すべての単体テストを実行し、コード カバレッジ レポートを生成し、FxCop を実行します
静的分析ビルド: Trunk に対して夜間に実行され、Duplicate Finder (Team City)、ConQAT コード クローン分析、StatSVN、および Resharper コード インスペクション (Team City) を実行します。
DEV デプロイメント(トランク ビルドへの依存): コミットのたびに、トランク ビルドが成功すると、アプリケーションは MS WebDeploy と構成変換を使用して、DEV 環境に自動的にデプロイされます。
QA 展開: QA に移動するときに、Team City のインターフェイス (ボタンをクリック) を介して手動でトリガーされます。MS WebDeploy と構成変換を使用して、アプリケーションを QA サーバーにデプロイします。
また、ニーズに応じて、さまざまなブランチ、特に安定版のリリース用に作成されたブランチのビルドをセットアップします。
重要な部分は、異なるビジュアル スタジオ ビルド構成 ( "Release"と"Debug"があるのと同じように、"Dev"、"QA"などを使用する必要があります) を持つことです。これは、順番に web.config 変換と共に使用する必要があります。 WebDeploy を取得して環境を構成します。そうすれば、特定の設定を使用して、ビルド構成ごとに 1 つずつ、異なるweb.Dev.config、web.QA.config変換を行うことができます。
Troy Hunt による「You're deploying it wrong!」という優れた一連の投稿があります。これにより、自動化されたビルドとデプロイのセットアップがガイドされます。
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html
これを設定するとき、それは私にとって非常に役に立ちました。
これで、Developer#1 の変更を本番環境にプッシュするだけで済みます。
-開発者 #1 は自分のコードを Dev ブランチにチェックインしました。QA が彼の変更を確認した後、変更をメイン ブランチにマージし、メインから本番用のリリースをビルドします。
メイン ブランチには、本番環境に移行するコードのみを含める必要がありますか?
-はい。理想的には、本番リリースは Main ブランチからビルドする必要があります。
自動化された方法でさまざまな環境にプッシュするにはどうすればよいでしょうか?
-TFS では、ブランチやビルド タイプごとにビルド定義を定義するのが一般的な方法です。ソースとビルドの種類とは別に、各定義には独自のタスクを含めることもできます。つまり、単体テストの実行、特定のフォルダーへの公開、ビルド アーティファクトのLab Managementへのデプロイなどです。
ProjectName-Main-Gated
ProjectName-Dev-CI
ProjectName-Dev-Nightly
ProjectName-Test-CI