Azure と Azure DevOps を使った開発の流れをふんわりと

Azure DevOps は、開発を補助するサービスです。
例えば(当然といえば当然ですが)、Visual Studioを使って開発し、Azure DevOpsで管理し、Azureにデプロイするという使い方ができます。

その全体の流れを絵でふんわりとみていきます。

# 全体の流れ

![20190620-1-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/7574f5e0-bece-e564-da64-0b5a9e09f412.png)

では１つ１つ順番に、左上からみていきたいと思います。

# 開発する

![20190620-1-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/4a22e0a2-7490-de14-1b7e-1f42d4b536f1.png)

はじめに、何らかのモノを作ります。
"Boards(ボード)"を使い

- どんなものが欲しいのか
- なぜ欲しいのか
- そのためにどんな機能が必要なのか
- どう作るのか
- どうなっていたら欲しいモノが手に入ったとするのか
- 具体的にいつまでに何をするのか
- 何を今やらないのか

などなど、決めていきます。
決まったら開発を実施します。開発環境はどのようなものでもかまいません。
"MicrosoftのサービスだからVisual Studioしか使えないでしょ？"という誤解を抱いている方に時々お会いしますが、そんなことはありません。
最終的にはソースコードが"Repos(リポ)"に上がるだけですので、何で開発しているのかを Azure DevOps は問いません。
プラグインが準備されているIDEとしましては以下になります。

- Visula Studio
- Visual Studio Code
- Eclipse
- IntelliJ
- Android Studio

などがあります。
開発が済んだものから順に、"Repos"に登録していきます。
コマンドでGitがたたければ登録できます。一緒にテストコードを書いて登録することをおすすめします。(この先はテストコードが書いてある前提で進みます。)

# "Repos"への登録を"Pipelines(パイプライン)"に検知させる

![20190620-1-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/4a76348d-67f6-6016-d718-7220289b9275.png)

プログラムが出来上がってきたら("Repos"にPushされたら)、そのことをトリガーにして"Pipelines"を起動します。

# "Pipelines" でビルドとテストとデプロイを自動化する

![20190620-1-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/5ae31677-731f-25d9-791c-a905680e57f0.png)

"Pipelines"では

- ビルドに必要なサーバーを準備してビルドする
- 単体テストを実施する
- 開発環境へデプロイする
- 機能テストを実施する

などの作業を実施してくれます。
専用のサーバーを準備しておく必要もありません(準備しておくこともできます)し、ビルド職人が夜明けのコーヒーを楽しむ必要もありません。
この作業を毎晩実施することで、いつも品質が高いモノを生産し続けることができます。
(余談ですが品質は上げないでください。最初から高く、その状態を継続してください。)
アジャイル開発やDevOpsを実施する上で、基本的に品質が高いというのは非常に重要なファクターとなります。コーディングする際に元のコードが信用ならないとすると、まずは元のコードを疑うところからコーディングを始めることになります。
結果としてソースコードは同じメソッドのコピペばかりになっていきます。

毎晩ビルドとテストを繰り返し、バグ収束曲線が低空飛行の直線になるよう目指しましょう。
昨日のバグはすぐに直せますし、バグをみんなで笑って迎え入れることができるようになります。

# 検証環境(とか、品質保証用環境)へ自動デプロイする

![20190620-1-5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/c0a3f061-5c4a-4671-7913-7415f66ee704.png)

作成したモノは機械的にチェックした結果、問題の無い状態となっています。
人間がチェックしても問題が無い状態になっていますので、ここでは人間がチェックするための、ほぼ本番同等の環境にデプロイを実施します。

# 品質確認テストを実施する

![20190620-1-6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/bb06defe-e536-d1b7-f9e2-94a96954b482.png)

人間系で実施すべきテストを実施します。例えば受け入れテストです。"Test Plans(テストプラン)"にどんなテストを実施するのかを記載し、手分けしてテストを実施します。"Test Plans"を使ってテストの項目や結果を共有します。テスト項目を作る元ネタは"Boards"に記載するようにしてください。
また、負荷テストも実施しましょう。

# 本番環境へ自動デプロイする

![20190620-1-7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/720a4649-f86a-bf0e-65d2-afa99edf1c8d.png)

本番へのデプロイも自動で実施します。

# 各環境からテレメトリーデータを取得し監視する

![20190620-1-8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/d9b0fa28-98ae-2640-f97f-86aed45a22ff.png)

各環境で現実問題として何が起きているのかを監視します。
"App Insights(アップインサイト)"を使えば、より詳細なアプリケーションテレメトリーデータを収集できます。
Azureの"Monitor(モニター)"を使えば、インフラとアプリケーションのテレメトリーデータを統合して確認することができます。

# フィードバックを次の開発やバグとして"Boards"に反映

![20190620-1-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/7574f5e0-bece-e564-da64-0b5a9e09f412.png)

監視した結果、もっと改善した方が良いこと（遅いとか、ユーザーが使い勝手が不明瞭で迷っている）やバグを検知・収集できます。
これらを"Boards"に記載することにより、障害対応の抜け漏れ防止やサービスの改善につなげます。

# まとめ

Azure DevOps は、開発から運用までを支えてくれる強力なサポーターであることがおわかりいただけたのではないでしょうか。
素早い開発を手抜き無しで実施するためには、こういう仕掛けが必須であると思います。