問題タブ [xamlbuild]

xaml ビルドを実行する最新の TFS サーバー (TFS 2018 Update 2) をインストールしました。更新後、エージェントを開始しましたが、xaml コントローラーはまだオフラインであり、これを再度開始する方法がわかりません..

私たちにできることはありますか？

私の質問は、vNext/Octopus プロセスと XAML ベースのプロセスの保守性についてです。むしろ、それらを正常に維持することが不可能であることについて、私たちが何かひどく間違ったことをしていると私に信じ込ませています.

与えられた:

• Microsoft は、vNext ビルドを優先して、TFS XAML ビルドを段階的に廃止することを推進しています
• Octopus Deploy は、人気のある展開自動化フレームワークです。
• 多くの XAML ベースのビルドがありますが、vNext への移植を開始しています
• デプロイは Octopus Deploy で自動化されています

具体的には、QA で 3 種類のビルドが進行中です。

• 古い XAML ベースのコンパイル ビルドは、デプロイするアーティファクトを生成します
  • 最終的には、コードをビルドして圧縮し、既知の場所に配置するだけです
• 新しい vNext コンパイル ビルドは、デプロイされるアーティファクトを生成します
  • 同上
• 展開ビルド
  1. 展開環境ごとの XAML ベースのビルド定義。これは、すべての構成 URL、接続文字列、証明書の拇印などを含む、特定の展開の信頼できる情報源です。ビルド定義には 100 を超えるビルド パラメーターがあります。新しい環境がセットアップされるたびに、既存の XAML ビルド定義を複製し、パラメーターを変更します。
     • このビルドはビルド アーティファクトをアンパックし、構成パラメーターに基づいてすべての Web/アプリ構成ファイルを生成し、octo.exe を使用して多くのパラメーターで Octopus Deploy を開始し、終了を待ちます。
  2. タコの展開プロセス
     • Web ファーム、バックグラウンド ジョブ エンジン クラスター、およびデータベースの 3 つの展開領域に一致するように、XAML ビルドによって以前に展開されたビルド アーティファクトから 3 つのパッケージを作成します。
     • 関連するパッケージを関連する触手に届けます。
     • 触手はそれぞれのパッケージを開梱してセットアップします

したがって、50 の展開環境がある場合、50 の XAML 展開ビルドがあり、それぞれがそれぞれの環境のコンテキストをキャプチャします。しかし、XAML デプロイ ビルドはデプロイ ジョブを Octopus に委任するため、ここでは 50 個の Octopus プロジェクト (デプロイごとに 1 つ) を持たなければなりません。

なぜそうなのですか？Octopus Project を 1 つだけにするオプションを検討しましたが、そのようなプロジェクトのリリース バージョンはどうなりますか? 膨大な数のリリース間をナビゲートできるようにするには、リリース バージョンに次のものが含まれている必要があります。

• デプロイされたコードのビルド バージョン。55.0.18709.3
• デプロイメント環境の名前。atwfm

上記の例を使用すると55.0.18709.3-atwfm、 が得られますが、同じビルド アーティファクトを同じデプロイ環境に 2 回デプロイしたい場合があります。しかし、唯一の Octopus プロジェクトには既に releaseがあるため、既存のリリースを削除せずに再度55.0.18709.3-atwfmデプロイするにはどうすればよいでしょうか?55.0.18709.3atwfm

回避策が見つからなかったため、デプロイごとに Octopus プロジェクトがあります。

タコのプロジェクトは更新するのが面倒なので、これは絶対にクレイジーです。ステップを追加する必要があるとします。50 個のプロジェクトで実行してください。自動化を使用して複数のプロジェクトを編集することについて、インターネット上に大きなアドバイスがあります。まったく理想的ではありません。

vNext、ところで、同じ問題があります。既存の XAML ビルドを vNext に移植する場合、50 個の vNext 展開ビルドが必要になります。ステップを追加する場合は、50 ビルドすべてで行う必要があります!!!

XAML ビルドには、プロセスがパラメーターとは別であるため、この問題はありません (ただし、他にも多くの問題があります)。ワークフローを一度変更すると、すべての XAML ビルドが新しいプロセスの変更で更新されます。

私の質問は、人々が vNext と Octopus をどのように使っているかということです。もっと良い方法があるはずです。

編集1

明確にしたいと思います。同じビルド アーティファクトを 2 回デプロイしたい場合があります。それらを再コンパイルして同じバージョンを再利用することはありません。いいえ。ビルド アーティファクトは既に手元にあり、ビルド バージョンはアーティファクト内に焼き付けられています。たとえば、その環境の一部のデータベースが誤って構成されており、これが修正され、再デプロイする必要があるため、同じ環境に 2 回目のデプロイが必要になる場合があります。これは、既存の Octopus リリースを再実行できるという意味ではありません。修正には、それぞれの XAML 展開ビルド定義の展開パラメーターの微調整が含まれる可能性があるためです。したがって、コードをコンパイルしない XAML 展開ビルドの再起動を余儀なくされる場合があります。

編集2

まず、Octopus からではなく、TFS XAML ビルドからデプロイを推進するのはなぜでしょうか? 歴史的な理由。最初はタコがありませんでした。展開はアドホック コードによって行われました。Octopus を導入したとき、次の 2 つの理由から XAML デプロイメネット ビルドを維持することにしました。

1. 莫大な数のデプロイ パラメーターを含むすべての XAML デプロイ ビルドを Octopus に移行するコストを節約するため。間違った決定だったのかもしれません。移行を自動化できたのかもしれません。
2. TFS の方がテスト結果を表示する機能が優れているためです。展開は展開スモーク テストで終了する可能性があり、その結果はどこかに公開する必要があります。Octopus が結果の公開にどのように役立つかはわかりませんが、TFS は可能です。

なぜ再デプロイするのでしょうか? たとえば、展開パラメーターの 1 つは証明書の拇印です。証明書が更新されたら、このパラメーターを変更する必要があります (XAML ビルド パラメーターを更新するための自動化があります)。しかし、多くの場合、それが既に間違った拇印でデプロイされていることがわかります。そのため、デプロイを修正して再デプロイします。または、デプロイされたアプリケーションの奇妙な動作を発見し、追加のトレース/デバッグ機能を使用して再デプロイしたいと考えています。

TFS サーバー Azure DevOps Server 2019 をアップグレードしました。2015 XAML ビルド サーバーを新しい URL に接続する際に問題が発生しています。2015 XAML ビルド サーバーを完全にアンインストールして、インストールを再開したときに設定が残されないようにする必要があります。コントロール パネルから Team Foundation Server をアンインストールしても、アンインストールされないようです。アンインストール後に他に何をクリアする必要がありますか?