1

次のタスクを達成するために TeamCity ビルドステップを構成する方法を見つけようとしています。

  1. dev ブランチをテスト ブランチ (TFS 内) にマージし、プロジェクト構成に使用されるテスト ブランチ内のファイルの一部を手動で変更するコンソール アプリを呼び出します。このプロセスは完全に機能し、テスト済みです。また、この手順では、マージされたファイルまたは変更されたファイルがテスト ブランチにチェックインされないことに注意してください。
  2. このビルド ステップにより、テスト ブランチの実際のソリューション ビルドが開始されます。(これは C#.NET ですが、重要ではないと思います)
  3. このビルド ステップは、追加されたすべての SQL スクリプトのデータベース移行を処理します。(この手順もテスト済みで動作します)
  4. この手順では、別のコンソール アプリを呼び出します。このステップは、前のステップが失敗した場合でも実行されます。ビルドが成功すると、ステップ 1 の保留中の変更がチェックインされ、ビルドがデプロイされます。前のステップでビルドが失敗した場合、ステップ 1 からの保留中の変更が取り消されます。

それは十分に簡単に思えますが、ステップ 1 と 2 の間の相互作用は、どうすればよいかわかりません。ステップ 2 でサーバー側のチェックアウトを使用すると、サーバーからソースがプルされ、ステップ 1 の変更は使用されません。エージェント側のチェックアウトを使用すると、新しいワークスペースが作成され、ソースがプルされます。サーバー、再びステップ1での変更を使用しません。

ステップ 1 で作成された保留中の変更を使用してステップ 2 をビルドする方法はありますか? 私が考えることができる他の唯一のオプションは、ステップ 1 の後に変更をチェックインし、ビルドが失敗した場合はステップ 4 で変更セットをロールバックすることです。ただし、その場合、ステップ 4 で変更セットをロールバックする方法を知るにはどうすればよいでしょうか。

また、1 つ小さな質問があります。ビルドの成功をパラメーターとしてステップ 4 に渡すにはどうすればよいですか? 組み込みパラメーターを調べましたが、ビルドの失敗/成功のパラメーターはありませんでしたか?

ありがとう！

4

1 に答える 1

1

使用しているVCS名(Git/SVN)を教えていただけると助かります。質問は主に2つの主要なポイントについてです

  • Teamcity build Stepsを使用している場合、すべてのビルド ステップが単一のターゲットの一部である場合、 Step 1 と Step 2 の間の相互作用について心配する必要はありません。すべてのステップを同じディレクトリで実行できます。サブステップ全体で常に作業コピーの状態を維持します。
  • teamcity の唯一の不具合は、「前のステップが失敗した場合にのみ」ビルド/ステップを実行できないことです。これを回避する
    には、前の手順のいずれかで失敗ファイルを作成し、そのファイルが存在する場合にのみビルドを実行します。次のビルドで偶発的な問題が発生しないようにするために、すべてのビルドの最後にファイルを削除してください。

したがって、要するに、ビルド手順は、(1) ブランチをチェックアウトし、(2) 別のブランチをそれにマージし、(3) ビルドと db デプロイを実行し、(4) コードをコミットし、失敗した場合はデータベースの変更をロールバックすることができます。失敗ファイルで。

2 番目の質問については、teamcity の各ステップは、ビルド全体の成功ステータスと、ここで説明した前のステップを認識しています。欠落している唯一のステップは、「前のステップのいずれかが失敗した場合にステップを実行する」です。

于 2014-07-23T00:45:10.947 に答える