Azure DevOps で .NET Core アプリケーションの継続的インテグレーションを実装する

# Azure DevOps で .NET Core アプリケーションの継続的インテグレーションを実装する

Azure DevOpsを使って.NET Core コンソールアプリケーションの継続的インテグレーションを実装する例を紹介する。

Azure DevOpsのとっかかりとして参考になればいいな。

想定シナリオ：下記のような運用ルールがある数人規模の小さい開発チーム

- バージョン管理システムにはGitを使う
- masterブランチは直接変更できない(プルリクエストでしか変更できない)
- プルリクエストの完了条件は下記の通り
    - バックログアイテムに基づく変更となっていること
    - 変更者とは別のレビュアーにより承認されていること
    - ビルドとユニットテストに成功していること

プロジェクトとリポジトリはすでに作成されている前提で、次の３つの機能の設定手順を記す。

1. ビルド定義
2. ブランチポリシー
3. プルリクエスト

## ビルド定義の作成

ビルド＆テストを実行させるためのビルド定義を作る。

Pipelines -> Builds -> New -> New Build Pipeline
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/96ac51d3-81d7-6336-e18f-d860ae5eff3f.png)

ソースリポジトリの選択
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/f47473ce-ce94-8e97-6ad5-6cd689eee018.png)

テンプレートの選択：.NET Coreアプリケーションなので構成が近いASP.NET Coreを選んでおく。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/289de6fd-54aa-b093-b9fa-40c5c0da9ac7.png)

Tasksタブ
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/ab6b2042-a933-ebfa-14ad-77516a793215.png)
ビルドとテストだけ実行したいので、publishとpublish artifactは無効化してもよい。

Variablesタブ
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/938afc4c-a48a-8889-e07c-e4a5e02d9027.png)
必要に応じてBuild Configuration を Release ⇒ Debug にしておく

Triggersタブ
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/e392ee65-4eb8-89e1-6676-9b9fd56ce6bd.png)

- プルリクエストを完了させる条件としてビルドを実行したい場合（今回の場合）：
  - 特に設定する必要はない
- プッシュされるたびにビルドを実行したい場合：
  - Enable Continuous integration にチェックを入れる。
  - CIビルドを実行するブランチを設定。ワイルドカード指定可
- Dailyビルドを実行したい場合：
  - Scheduled を Add
  - 曜日や時刻等を設定

Options, Retentionは好みで。設定が完了したらSave&queue↓で Save.

## ブランチポリシーの作成

masterブランチを保護するためのポリシーを作る。

Repos -> Branches -> master ブランチの Branch policies

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/c90aeb6d-8395-0333-997f-b350909525d3.png)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/30436656-8035-bc9f-21b5-085da2e62666.png)

各項目の設定値については次。

### コードレビュアーの最低人数

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/d6404b1f-ed5c-5e4a-4617-dda53d44de9e.png)

コードを変更した人とは別の最低１人によるレビューと承認が必要。
⇒1人が勝手にコードを変更できないようになる(Separation of Duty)

### ワークアイテムの関連付け

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/3c3bd0e3-b599-911b-b49b-45a5e28372be.png)

プルリクエストはワークアイテム（ユーザストーリーやバグなど）に関連付けされてなければならない。
⇒プルリクエストの意図や目的が明確になる。

### コメントが解決されていることの確認

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/b20bcaf0-5315-f8c6-e59c-5094df1a9c7a.png)

プルリクエストを完了させるには、コードレビューのコメントがすべて解決されている必要がある
⇒レビュアーが指摘した問題点の解決漏れを防げる。

### マージ方法の強制

※これは好みで。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/2d3c86e8-5330-bc4e-00ce-1041893f6a68.png)

プルリクエストがmasterブランチにマージされるとき、Squash mergeされる
⇒余計なコミットログを残さないようにできる。


### ビルド検証

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/ff62f034-8b72-2936-5bd0-854153ab79f5.png)

上で作成したビルド定義を設定する。
⇒ビルドとテストに失敗するコードのマージを防げる。

## プルリクエスト

上で作成したビルド定義とブランチポリシーが機能していることを確認する。

ブランチを作成して変更をプッシュ後、プルリクエストを作成する。

### Overviewタブ

プルリクエストの概要が見れる。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/7c8210f2-8cb7-2d3e-629b-648f19e154e2.png)
ブランチポリシーで設定した条件が完了するまではプルリクエストを完了できない。

### Filesビュー

Filesビューではファイル毎にDiffしながらレビューできる。コメントの記入も可。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/fd766e48-cdff-d5cf-a51f-69db9f7908b6.png)

### プルリクエストの完了

指摘事項が解決され、レビュアーの承認させるとプルリクエストを完了できるようになる。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/f66c6052-d8a6-b3b7-e06d-20a244946fb9.png)

masterブランチの履歴はSquashされるのでしょうもないコミットログは残らない

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/9834683e-9d89-3de5-12e5-76ba57a8fcec.png)

## 補足

### ブランチの作成方法

ブランチはユーザストーリーやバグから作成できる。
こうするとブランチにユーザストーリーやバグが関連づくので、プルリクエストの目的が分かりやすくなる。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/c3ec83d1-0fff-f0ec-7baa-0c32f6a1231d.png)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/118451/de58d71c-88b2-8451-df12-ebd4435e8817.png)

※こういった手順はブランチ戦略等と合わせてREADMEやWikiに明記しておくとよい。

## まとめ

Azure DevOps の下記３つの機能を使ったCIの実装例を紹介した。

1. ビルド定義
2. ブランチポリシー
3. プルリクエスト

## Next?

プロジェクトの規模や開発チームの成熟度によって下記のようなことをしてもいい。

- コードレビューせず、ビルドとテストが通ったら自動的にマージする
- 人力コードレビューの代わりに静的解析ツールを実行させる
- 特定メンバーによるレビューを必須にする
- コミット毎にビルド＆テストを実行させる
- Nightlyビルドを構成して、重いテストは夜中に実行させる
- リリース用ビルドを定義して、パッケージ作成を自動化する
- Release を使って Continuous Delivery/Deploy に挑戦