Azure DevOps関連

##### 目録
- [画面と機能](#画面と機能)
- [DevOps reposで、pull request作成の時、自動的にdescription文字を追加（上限4000字まで）](#devops-reposで自動的にdescription文字を追加)
- [pipeline起動条件を設置（特定の動作・特定のブランチ）](#pipeline起動条件を設置)
- [それぞれのbranchの為、特有のpull requestテンプレートを設置](#それぞれのbranchの為特有のpullrequestテンプレートを設置)
- [reposのpipelineが修正されたため、pipeline適用されたpull requestが「Build expired」になる場合](#pull-request出す後pipelineが修正された場合)
---
##### 画面と機能
- タスク管理画面
  - プロジェクト - Boards - Sprints画面。azure devopsはアジャイルの推進型に向いている。
    - 左の「ガイド」でdevopsの各機能を選択、このタスク管理画面はBoardsのSprints機能
    - 真ん中のエリアはタスクを表示、左の白い背景の列は今sprint中の目標タスク、上の「New Work Item」で作成。左のグレー背景は目標タスクのサブタスク、目標タスク右下の緑「＋」ボタンで作成。タスクエリア上のタスク状態はサブタスクの進行状態を表示、これはカスタマイズできる。サブタスクの進行状態はタスクブロックの下「status」の右で表示、新作成のサブタスクは黙認「To do」状態。
    - タスク状態上のは「フィルター」、タスクが多い時、フィルターで情報洗い出す。
![スクリーンショット 2023-02-01 20.47.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/042d056f-f826-ff44-c666-ed5a772a7f1e.png)
  - プロジェクト - Boards - Retrospectives画面。Sprint中の問題や助言をまとめる。大体keep、problem、try三つの方面に分けてまとめる、ユーザ入力したら匿名表示になる。
    ![スクリーンショット 2023-02-01 21.27.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/73623679-b9c4-e977-54d1-b42ea5cd85d3.png)
- wiki画面。プロジェクトのドキュメントをまとめる。内容編集の時、`[[_TOC_]]`を入れると、目次自動生成できる。
  ![スクリーンショット 2023-02-01 21.35.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/fcee1f7f-6421-7ada-382f-20ce6f2a29ef.png)
- repository画面。devopsにはgithubと似た様な倉庫ブランチ機能がある
  ![スクリーンショット 2023-02-01 21.40.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/7c1eab68-b2dc-4c75-410c-de850993c0a7.png)
- pipeline画面。CICD機能として、レポジトリ資材をサービス環境に反映するための自動化処理がある。
  ![スクリーンショット 2023-02-01 21.43.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/3cdcf37b-8f7f-ad5e-6b86-57f8e02c0399.png)


 
##### Devops reposで自動的にdescription文字を追加
- 倉庫のdefault branchのroot pathにpull_request_template.mdを追加、その中身がdescriptionのテンプレートとして、pull request作成度自動追加される。他の機能は[オフィシャル説明](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-request-templates?view=azure-devops) に記載されている
  - もし違うpull request先にそれぞれのテンプレートを用意したい場合、[オフィシャル説明](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-request-templates?view=azure-devops) の【Branch specific pull request templates】を参考

##### pipeline起動条件を設置
- azure Repos git種類の倉庫では、pull requestの作成をpipelineの起動条件にしたい場合、PRを受ける予定ブランチのbranch policiesで、起動したいpipelineを手動追加する。 [オフィシャル説明](https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers)、PR triggers部分を参考

- 「pull request作成」を起動条件にしたpipelineの中、pull request作成側のブランチ名によってい、pipelineの動作を設置（if文の様に）。下↓例文の中、PR作成側のブランチ名が“gitresource“で始まる場合、下の”job”内容が起動される；逆に、PR作成側のブランチ名を”gitresource”以外で始まるを限定したい場合、“startsWith”を“not”で入れ替える
  ```
  - job: Update_git_resources
    condition: startsWith(variables['System.PullRequest.SourceBranch'], 'refs/heads/gitresource')
    steps:
      - script: echo Git資材更新
  ```

- pull requestがmergeされた後、上のPRのようにpipelineをPR投げ側のブランチ名でpipelineの実行すべきjobを分ける事は出来ない。'System.PullRequest.SourceBranch'と言うパラメータはbranch policiesが追加されたpipeline中のみ使用出来る。システムは、PRがmerge後、どのブランチからPRを投げたのは分からないので。だから現在考えられる、PRがmerge後起動のpipelineに、ファイルやフォルダのチェックを入れるのは妥当だと思う。
例えは、sfdx metadataなら、全ての資材が「force-app」フォルダ、deploy用xmlは「manifest」フォルダ。この二つのフォルダ内容の修正をpipeline　triggerにするのはありと思う。
ちなみに、merge動作をtriggerにするpipeline中、'Build.SourceBranch'パラメータがPRを受け側のブランチを表す。
詳しくは[オフィシャル説明](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml)、SourceBranch部分を参考
- [pipeline基礎的の文法、パラメータの処理](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops) 

##### それぞれのbranchの為特有のpullrequestテンプレートを設置
DevOps倉庫で、違うブランチへpull request投げたとき、投げ先ブランチ名によってい、「Description」欄にブランチ名に合わせたテンプレート文を自動入力するため、倉庫に
` <repository root>/pull_request_template/branches/`のフォルダを作成、そして` ブランチ名　.md`のファイルを追加すると、ブランチ特有のテンプレートが設置完了。
詳細は[オフィシャル説明](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-request-templates?view=azure-devops)「Branch specific pull request templates」部分を参考

##### pull request出す後pipelineが修正された場合
具体的な情報は：
- ブランチ01からブランチmainに向けてPR作成した、
- そのPRがmergeされる前、ブランチmainの中、PR受ける時のpipelineが修正された、
- その為、PRが「Build expired」の状況になってmerge出来無い
- この状況を解決為二つ方法がある
  1. 現在のPRを取り消し、もう一回ブランチmain向けの新PRを作成
  2. 現在のPR画面で「re-queue」ボタンを押す；![image (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/17f1feec-0308-0225-6af1-f457a8d4eb5e.png)
     或いは「restart-merge」ボタンを押す![image (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2747384/5712fc01-a468-5b24-a290-2241955dc263.png)