Azure DevOps関連

目録

• 画面と機能
• DevOps reposで、pull request作成の時、自動的にdescription文字を追加（上限4000字まで）
• pipeline起動条件を設置（特定の動作・特定のブランチ）
• それぞれのbranchの為、特有のpull requestテンプレートを設置
• reposのpipelineが修正されたため、pipeline適用されたpull requestが「Build expired」になる場合

---

画面と機能

• タスク管理画面
  • プロジェクト - Boards - Sprints画面。azure devopsはアジャイルの推進型に向いている。
    • 左の「ガイド」でdevopsの各機能を選択、このタスク管理画面はBoardsのSprints機能
    • 真ん中のエリアはタスクを表示、左の白い背景の列は今sprint中の目標タスク、上の「New Work Item」で作成。左のグレー背景は目標タスクのサブタスク、目標タスク右下の緑「＋」ボタンで作成。タスクエリア上のタスク状態はサブタスクの進行状態を表示、これはカスタマイズできる。サブタスクの進行状態はタスクブロックの下「status」の右で表示、新作成のサブタスクは黙認「To do」状態。
    • タスク状態上のは「フィルター」、タスクが多い時、フィルターで情報洗い出す。
      
  • プロジェクト - Boards - Retrospectives画面。Sprint中の問題や助言をまとめる。大体keep、problem、try三つの方面に分けてまとめる、ユーザ入力したら匿名表示になる。
    
• wiki画面。プロジェクトのドキュメントをまとめる。内容編集の時、[[_TOC_]]を入れると、目次自動生成できる。
  
• repository画面。devopsにはgithubと似た様な倉庫ブランチ機能がある
  
• pipeline画面。CICD機能として、レポジトリ資材をサービス環境に反映するための自動化処理がある。
  

Devops reposで自動的にdescription文字を追加

• 倉庫のdefault branchのroot pathにpull_request_template.mdを追加、その中身がdescriptionのテンプレートとして、pull request作成度自動追加される。他の機能はオフィシャル説明 に記載されている
  • もし違うpull request先にそれぞれのテンプレートを用意したい場合、オフィシャル説明 の【Branch specific pull request templates】を参考

pipeline起動条件を設置

• azure Repos git種類の倉庫では、pull requestの作成をpipelineの起動条件にしたい場合、PRを受ける予定ブランチのbranch policiesで、起動したいpipelineを手動追加する。 オフィシャル説明、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を受け側のブランチを表す。
  詳しくはオフィシャル説明、SourceBranch部分を参考

• pipeline基礎的の文法、パラメータの処理

それぞれのbranchの為特有のpullrequestテンプレートを設置

DevOps倉庫で、違うブランチへpull request投げたとき、投げ先ブランチ名によってい、「Description」欄にブランチ名に合わせたテンプレート文を自動入力するため、倉庫に
<repository root>/pull_request_template/branches/のフォルダを作成、そして ブランチ名　.mdのファイルを追加すると、ブランチ特有のテンプレートが設置完了。
詳細はオフィシャル説明「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」ボタンを押す；
     或いは「restart-merge」ボタンを押す