TL;DR

Azure DevOps Serverの環境（オンプレ）は構築し、ビルドサーバー設定済みであることが前提
.NET アプリケーションのプロジェクトで事前に必要な設定
ビルド定義作成、手動キューまでの手順

そもそも継続的インテグレーションとは？

定期的、または手動でリポジトリに頻繁にマージし、かつ「定期的・自動的」に「ビルド・テスト」を行うという手法。また、その先の継続的配置（CD）を行うこともできる。

https://www.techmatrix.co.jp/product/cisolution/cisolution1.html
https://docs.microsoft.com/ja-jp/sharepoint/dev/spfx/toolchain/implement-ci-cd-with-azure-devops

利点

そのビルドにどの変更点が含まれているか、ということがわかりやすくなる
テストコードを記載すると、テストまで自動で実施してくれる
毎日ビルドを実施すると、どの時点でビルド、テストに失敗したかということを早めに見つけることができる
ビルド結果をリリースとして保存することもできる。リリースで自動でテストサイトに適用することも可能であるため、正確性、時短につながる
ビルド結果をダウンロードできるため、いつ時点のビルドでテストをしたのか、ということも分かりやすい
ビルド結果は、ファイル共有に出力することも可能

.NET アプリケーションのプロジェクトで事前に必要な設定

同じソースコードから常に同じバイナリを生成する

Deteministicを使用する

ビルドした日が違うと、ソースが同じでも作成したバイナリが別になることへの対応。

/deteministic: GUID の算出にタイムスタンプと乱数を使わなくする
ソースコードなどのハッシュ値から計算するので、ソースコードに変化がない限り一意

制限としては、バージョンとして*を使用できなくなる

手順：Directory.Build.propsを作成

https://ufcpp.net/blog/2018/12/directorybuild/
https://thomaslevesque.com/tag/build/

対象としたいプロジェクトファイルの上の階層（ソリューションファイルと同じ場所など）に、Directory.Build.propsを配置する。vbproj, csprojなどに、自働で適用される。UTF-8で作成する。

Directory.Build.props

<Project>
  <PropertyGroup>
    <Deterministic>true</Deterministic>
  </PropertyGroup>
</Project>

Pathmapを使用する

デバッグ情報のパスが問題となる場合は、pathmapの設定も行う

/pathmap: デバッグ情報などで使うファイルのパスを所定のルールで置き換え可能にする
置き換え元=置き換え後という形式で、単純な置換をするだけ
置き換え元の方に $(MSBuildProjectDirectory) とかを指定して、置き換え先の方を/とかあたりさわりのない固定の文字列にしておけば、どの環境でも同じ結果が得られる

手順

1．パイプラインの作成

1－1．左側のビルドをクリックし、新しいパイプラインをクリック（すでに作成していたら新規作成）

1－2．使用しているソース管理を選ぶ、TFVCかAzure Git

自分のプロジェクト以外に参照している（相対で）ソースがあれば追加する

1－3．作成したいテンプレートを選択（ここでは、.NET デスクトップ）

1－4．エージェントを選択する

後は、必要に応じてカスタマイズ（対象とするソリューションや、最終的にコピーする成果物の絞り込みなど）

2．手動ビルド（キュー）の手順

2－1．ビルド定義右上のキューをクリック（ビルドできる）

2－2．ビルド結果を参照できる

右上のリンクから、成果物（デスクトップアプリならexeなど）をダウンロード

※成果物リンクがない場合は、F5更新

2－3．概要タブから、関連する変更を確認できる