デプロイ ジョブ

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

重要

  • ジョブ名とステージ名にキーワードを含めることはできません (例: deployment)。
  • ステージ内の各ジョブには、一意の名前が必要です。

YAML パイプラインでは、デプロイ ジョブと呼ばれる特殊な種類の ジョブ にデプロイ 手順を配置することをお勧めします。 デプロイ ジョブは、環境に対して順番に実行されるステップのコレクションです。 デプロイ ジョブと従来の ジョブ は、同じステージに存在できます。

デプロイ ジョブには、次の利点があります。

  • デプロイ履歴: 監査用のデプロイの特定のリソースと状態まで、パイプライン全体のデプロイ履歴を取得します。

  • デプロイ戦略を適用する: アプリケーションのロールアウト方法を定義します。

    注意

    現在、 runOncerollingおよびカナリア 戦略のみがサポートされています。

デプロイ ジョブは、ソース リポジトリを自動的に複製しません。 ジョブ checkout: self内でソース リポジトリをチェックアウトできます。 デプロイ ジョブは、チェックアウト手順を 1 つだけサポートします。

スキーマ

デプロイ ジョブを指定するための完全な構文を次に示します。

jobs:
- deployment: string   # name of the deployment job, A-Z, a-z, 0-9, and underscore. The word "deploy" is a keyword and is unsupported as the deployment name.
  displayName: string  # friendly name to display in the UI
  pool:                # not required for virtual machine resources
    name: string       # Use only global level variables for defining a pool name. Stage/job level variables are not supported to define pool name.
    demands: string | [ string ]
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  dependsOn: string
  condition: string
  continueOnError: boolean                # 'true' if future jobs should run even if this job fails; defaults to 'false'
  container: containerReference # container to run this job inside
  services: { string: string | container } # container resources to run as a service container
  timeoutInMinutes: nonEmptyString        # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: nonEmptyString  # how much time to give 'run always even if cancelled tasks' before killing them
  variables: # several syntaxes, see specific section
  environment: string  # target environment name and optionally a resource name to record the deployment history; format: <environment-name>.<resource-name>
  strategy:
    runOnce:    #rolling, canary are the other strategies that are supported
      deploy:
        steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]

プロパティに使用 environment できる、より詳細な代替構文があります。

environment:
    name: string # Name of environment.
    resourceName: string # Name of resource.
    resourceId: string # Id of resource.
    resourceType: string # Type of environment resource.
    tags: string # List of tag filters.

仮想マシンの場合、プールを定義する必要はありません。 仮想マシン リソースを使用してデプロイ ジョブで定義した手順は、プール内のエージェントではなく、その仮想マシンに対して実行されます。 Kubernetes などの他のリソースの種類の場合は、そのマシンでタスクを実行できるようにプールを定義する必要があります。

デプロイ戦略

アプリケーションの更新プログラムをデプロイするときは、更新プログラムの配信に使用する手法が次のことを行う必要があります。

  • 初期化を有効にする。
  • 更新プログラムをデプロイする。
  • 更新されたバージョンにトラフィックをルーティングする。
  • トラフィックのルーティング後に更新されたバージョンをテストする。
  • エラーが発生した場合は、最新の既知の適切なバージョンに復元する手順を実行する。

これを実現するには、デプロイ中にステップを実行できるライフサイクル フックを使用します。 各ライフサイクル フックは、属性に応じて、エージェント ジョブまたは サーバー ジョブ (または将来はコンテナーまたは検証ジョブ) に pool 解決されます。 既定では、ライフサイクル フックはジョブによって指定されたフック pooldeployment 継承します。

デプロイ ジョブでは、$(Pipeline.Workspace) システム変数が使用されます。

ライフサイクル フックの説明

preDeploy: アプリケーションのデプロイが開始される前にリソースを初期化する手順を実行するために使用されます。

deploy: アプリケーションをデプロイする手順を実行するために使用します。 成果物のダウンロード タスクは、デプロイ ジョブのフックにのみ自動的に deploy 挿入されます。 成果物のダウンロードを停止するには、[パイプライン成果物のダウンロード] タスクを指定して、ダウンロードする特定の成果物を使用 - download: none または選択 します

routeTraffic: 更新されたバージョンへのトラフィックを処理するステップを実行するために使用されます。

postRouteTraffic: トラフィックがルーティングされた後に手順を実行するために使用されます。 通常、これらのタスクは、定義された間隔で、更新されたバージョンの正常性を監視します。

on: failure または on: success:ロールバック アクションまたはクリーンアップのステップを実行するために使用されます。

RunOnce 配置戦略

runOnceは最も単純なデプロイ戦略であり、すべてのライフサイクル フック (つまりpreDeploydeploy、" 、 " routeTrafficpostRouteTraffic) が 1 回実行されます。 その後、on:success または on:failure が実行されます。

strategy: 
    runOnce:
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

セルフホステッド エージェントを使用している場合は、ワークスペースのクリーン オプションを使用してデプロイ ワークスペースをクリーンアップできます。

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

ローリング デプロイ戦略

ローリング デプロイでは、前のバージョンのアプリケーションのインスタンスが、各イテレーションで固定された仮想マシン (ローリング セット) 上のアプリケーションの新しいバージョンのインスタンスに置き換えられます。

現時点では、VM リソースへのローリング戦略のみがサポートされています。

たとえば、ローリング デプロイは通常、仮想マシンの各セットのデプロイが完了するのを待ってから、次のデプロイ セットに進みます。 各イテレーションの後に正常性チェックを行うことができ、重大な問題が発生した場合は、ローリング デプロイを停止できます。

ローリング デプロイは、ノードの下strategy:にキーワードrolling:を指定することで構成できます。 変数は strategy.name 、戦略の名前を受け取るこの戦略ブロックで使用できます。 この場合、ローリングします。

strategy:
  rolling:
    maxParallel: [ number or percentage as x% ]
    preDeploy:        
      steps:
      - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
    deploy:          
      steps:
      ...
    routeTraffic:         
      steps:
      ...        
    postRouteTraffic:          
      steps:
      ...
    on:
      failure:         
        steps:
        ...
      success:          
        steps:
        ...

すべてのライフサイクル フックがサポートされ、ライフサイクル フック ジョブが各 VM で実行されるように作成されます。

preDeploydeployrouteTrafficおよび postRouteTraffic によって定義 maxParallelされたバッチ サイズごとに 1 回実行されます。 その後、on: success または on: failure が実行されます。

を使用 maxParallel: <# or % of VMs>すると、並列にデプロイする仮想マシン ターゲットの数/割合を制御できます。 これにより、アプリがこれらのマシンで実行され、デプロイが他のマシンで行われている間に要求を処理でき、全体的なダウンタイムが短縮されます。

注意

この機能には、いくつかの既知のギャップがあります。 たとえば、ステージを再試行すると、失敗したターゲットだけでなく、すべての VM でデプロイが再実行されます。

カナリア デプロイ戦略

カナリアデプロイ戦略は、新しいバージョンのアプリケーションのロールアウトに伴うリスクを軽減するのに役立つ高度なデプロイ戦略です。 この方法を使用すると、サーバーの小さなサブセットに対する変更を最初にロールアウトできます。 新バージョンへの信頼度が上がってきたら、インフラストラクチャ内のより多くのサーバーにリリースし、より多くのトラフィックをルーティングすることができます。

strategy: 
    canary:
      increments: [ number ]
      preDeploy:        
        pool: [ server | pool ] # See pool schema.        
        steps:
        - script: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
      deploy:          
        pool: [ server | pool ] # See pool schema.        
        steps:
        ...
      routeTraffic:         
        pool: [ server | pool ]         
        steps:
        ...        
      postRouteTraffic:          
        pool: [ server | pool ]        
        steps:
        ...
      on:
        failure:         
          pool: [ server | pool ]           
          steps:
          ...
        success:          
          pool: [ server | pool ]           
          steps:
          ...

カナリア デプロイ戦略では、preDeployライフサイクル フック (1 回実行) をサポートし、ライフサイクル フック 、routeTrafficおよびライフサイクル フックをdeploy使用してpostRouteTraffic反復処理します。 次に、いずれかのfailureフックを使用してsuccess終了します。

この戦略では、次の変数を使用できます。

strategy.name: 戦略の名前。 たとえば、カナリアです。
strategy.action: Kubernetes クラスターで実行されるアクション。 たとえば、デプロイ、昇格、拒否などです。
strategy.increment: 現在の対話で使用される増分値。 この変数は、ライフサイクル フックでのみdeployrouteTrafficpostRouteTraffic使用できます。

RunOnce 配置戦略

次の YAML スニペットの例では、デプロイ戦略を使用してデプロイ ジョブを簡単に runOnce 使用できます。 この例には、チェックアウト手順が含まれています。


jobs:
  # Track deployments on the environment.
- deployment: DeployWeb
  displayName: deploy Web App
  pool:
    vmImage: 'ubuntu-latest'
  # Creates an environment if it doesn't exist.
  environment: 'smarthotel-dev'
  strategy:
    # Default deployment strategy, more coming...
    runOnce:
      deploy:
        steps:
        - checkout: self 
        - script: echo my first deployment

このジョブを実行するたびに、デプロイ履歴が環境に smarthotel-dev 対して記録されます。

注意

  • 前の例に示すように、空のリソースを含む環境を作成し、それを抽象シェルとして使用してデプロイ履歴を記録することもできます。

次の例では、デプロイ ジョブのターゲットとして使用する環境とリソースの両方をパイプラインで参照する方法を示します。

jobs:
- deployment: DeployWeb
  displayName: deploy Web App
  pool:
    vmImage: 'ubuntu-latest'
  # Records deployment against bookings resource - Kubernetes namespace.
  environment: 'smarthotel-dev.bookings'
  strategy: 
    runOnce:
      deploy:
        steps:
          # No need to explicitly pass the connection details.
        - task: KubernetesManifest@0
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            namespace: $(k8sNamespace)
            manifests: |
              $(System.ArtifactsDirectory)/manifests/*
            imagePullSecrets: |
              $(imagePullSecret)
            containers: |
              $(containerRegistry)/$(imageRepository):$(tag)

この方法には、次の利点があります。

  • 環境内のすべてのリソースの履歴を記録するのではなく、環境内の特定のリソースのデプロイ履歴を記録します。
  • デプロイ ジョブの手順では、デプロイ ジョブが環境にリンクされているため、リソースの接続の詳細 (この場合は Kubernetes 名前空間smarthotel-dev.bookings) が自動的に継承されます。 これは、ジョブの複数のステップに対して同じ接続の詳細が設定されている場合に便利です。

ローリング デプロイ戦略

VM のローリング戦略では、各イテレーションで最大 5 つのターゲットが更新されます。 maxParallel によって、同時にデプロイできるターゲットの数が決まります。 選択するときは、デプロイされているターゲットを除いて、常に使用可能な状態にしておく必要があるターゲットの絶対数または割合を考慮します。 それはまた、デプロイの間に成功と失敗の条件を判断するためにも使用されます。

jobs: 
- deployment: VMDeploy
  displayName: web
  environment:
    name: smarthotel-dev
    resourceType: VirtualMachine
  strategy:
    rolling:
      maxParallel: 5  #for percentages, mention as x%
      preDeploy:
        steps:
        - download: current
          artifact: drop
        - script: echo initialize, cleanup, backup, install certs
      deploy:
        steps:
        - task: IISWebAppDeploymentOnMachineGroup@0
          displayName: 'Deploy application to Website'
          inputs:
            WebSiteName: 'Default Web Site'
            Package: '$(Pipeline.Workspace)/drop/**/*.zip'
      routeTraffic:
        steps:
        - script: echo routing traffic
      postRouteTraffic:
        steps:
        - script: echo health check post-route traffic
      on:
        failure:
          steps:
          - script: echo Restore from backup! This is on failure
        success:
          steps:
          - script: echo Notify! This is on success

カナリア デプロイ戦略

次の例では、AKS のカナリア戦略では、最初に 10% のポッドで変更をデプロイし、その後に 20% を続けて、実行中 postRouteTrafficの正常性を監視します。 すべてがうまくいけば、100%に昇格します。

jobs: 
- deployment: 
  environment: smarthotel-dev.bookings
  pool: 
    name: smarthotel-devPool
  strategy:                  
    canary:      
      increments: [10,20]  
      preDeploy:                                     
        steps:           
        - script: initialize, cleanup....   
      deploy:             
        steps: 
        - script: echo deploy updates... 
        - task: KubernetesManifest@0 
          inputs: 
            action: $(strategy.action)       
            namespace: 'default' 
            strategy: $(strategy.name) 
            percentage: $(strategy.increment) 
            manifests: 'manifest.yml' 
      postRouteTraffic: 
        pool: server 
        steps:           
        - script: echo monitor application health...   
      on: 
        failure: 
          steps: 
          - script: echo clean-up, rollback...   
        success: 
          steps: 
          - script: echo checks passed, notify... 

パイプライン デコレーターを使用してステップを自動的に挿入する

パイプライン デコレーター をデプロイ ジョブで使用すると、すべてのデプロイ ジョブのすべての ライフサイクル フック 実行にカスタム ステップ (脆弱性スキャナーなど) を自動的に挿入できます。 パイプライン デコレーターは組織内のすべてのパイプラインに適用できるため、これは安全なデプロイプラクティスの実施の一環として利用できます。

さらに、デプロイ ジョブは、定義されている場合、サービスサイドカーと共にコンテナー ジョブとして実行できます。

出力変数のサポート

デプロイ ジョブの ライフサイクル フック で出力変数を定義し、同じステージ内の他のダウンストリーム ステップとジョブで使用します。

ステージ間で変数を共有するには、 成果物 を 1 つのステージで出力してから、後続のステージで使用するか、変数で説明されている構文を stageDependencies 使用 します

デプロイ戦略の実行中は、次の構文を使用して、ジョブ間で出力変数にアクセスできます。

  • runOnce 戦略の場合: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']] (例: $[dependencies.JobA.outputs['Deploy.StepA.VariableA']])
  • runOnce 戦略と resourceType の場合: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']] (例: $[dependencies.JobA.outputs['Deploy_VM1.StepA.VariableA']])
  • カナリア戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • ローリング戦略の場合:$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]
# Set an output variable in a lifecycle hook of a deployment job executing canary strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # Creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

ジョブの場合は runOnce 、ライフサイクル フックの代わりにジョブの名前を指定します。

# Set an output variable in a lifecycle hook of a deployment job executing runOnce strategy.
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  environment: staging
  strategy:                  
    runOnce:
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job.
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

デプロイ ジョブで環境を定義する場合、出力変数の構文は、環境の定義方法によって異なります。 この例では、短縮表記を使用しenv2env1定義されたリソースの種類を持つ完全な構文を含みます。

stages:
- stage: StageA
  jobs:
  - deployment: A1
    pool:
      vmImage: 'ubuntu-latest'
    environment: env1
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
            name: setvarStep
          - bash: echo $(System.JobName)
  - deployment: A2
    pool:
      vmImage: 'ubuntu-latest'
    environment: 
      name: env2
      resourceType: virtualmachine
    strategy:                  
      runOnce:
        deploy:
          steps:
          - script: echo "##vso[task.setvariable variable=myOutputVarTwo;isOutput=true]this is the second deployment variable value"
            name: setvarStepTwo
  
  - job: B1
    dependsOn: A1
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A1.outputs['A1.setvarStep.myOutputVar'] ]
      
    steps:
    - script: "echo $(myVarFromDeploymentJob)"
      name: echovar
 
  - job: B2
    dependsOn: A2
    pool:
      vmImage: 'ubuntu-latest'
    variables:
      myVarFromDeploymentJob: $[ dependencies.A2.outputs['A2.setvarStepTwo.myOutputVar'] ]
      myOutputVarTwo: $[ dependencies.A2.outputs['Deploy_vmsfortesting.setvarStepTwo.myOutputVarTwo'] ]
    
    steps:
    - script: "echo $(myOutputVarTwo)"
      name: echovartwo

デプロイ ジョブから変数を出力する場合、次のジョブから変数を参照すると、変数を設定するか、ステージの条件として使用するかに応じて、異なる構文が使用されます。

stages:
- stage: StageA
  jobs:
  - job: A1
    steps:
      - pwsh: echo "##vso[task.setvariable variable=RunStageB;isOutput=true]true"
        name: setvarStep
      - bash: echo $(System.JobName)

- stage: StageB
  dependsOn: 
    - StageA
 
  # when referring to another stage, stage name is included in variable path
  condition: eq(dependencies.StageA.outputs['A1.setvarStep.RunStageB'], 'true')
  
  # Variables reference syntax differs slightly from inter-stage condition syntax
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['setvarStep.RunStageB']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

マルチジョブ出力変数を設定する方法の詳細

よく寄せられる質問

パイプラインが "ジョブが保留中です..." というメッセージでスタックしています。 どうしたらいいですか。

これは、2 つのジョブ間で名前の競合が発生した場合に発生する可能性があります。 同じステージ内のすべてのデプロイ ジョブに一意の名前があり、そのジョブ名とステージ名にキーワードが含まれていないことを確認します。 名前を変更しても問題が解決しない場合は、 パイプラインの実行のトラブルシューティングを確認してください。

デコレーターはデプロイ グループでサポートされていますか?

いいえ。 展開グループではデコレーターを使用できません。