LoginSignup
2
2

More than 5 years have passed since last update.

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

Posted at

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

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

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

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

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

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

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

ビルド定義の作成

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

Pipelines -> Builds -> New -> New Build Pipeline
image.png

ソースリポジトリの選択
image.png

テンプレートの選択:.NET Coreアプリケーションなので構成が近いASP.NET Coreを選んでおく。
image.png

Tasksタブ
image.png
ビルドとテストだけ実行したいので、publishとpublish artifactは無効化してもよい。

Variablesタブ
image.png
必要に応じてBuild Configuration を Release ⇒ Debug にしておく

Triggersタブ
image.png

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

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

ブランチポリシーの作成

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

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

image.png

image.png

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

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

image.png

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

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

image.png

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

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

image.png

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

マージ方法の強制

※これは好みで。

image.png

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

ビルド検証

image.png

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

プルリクエスト

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

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

Overviewタブ

プルリクエストの概要が見れる。
image.png
ブランチポリシーで設定した条件が完了するまではプルリクエストを完了できない。

Filesビュー

Filesビューではファイル毎にDiffしながらレビューできる。コメントの記入も可。
image.png

プルリクエストの完了

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

image.png

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

image.png

補足

ブランチの作成方法

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

image.png

image.png

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

まとめ

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

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

Next?

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

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2