次の方法で共有

デプロイ ジョブ

  • [アーティクル]

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

重要

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

YAML パイプラインでは、デプロイ ジョブと呼ばれる特別な種類のジョブに、デプロイ手順を配置することをお勧めします。 デプロイ ジョブは、環境に対して順番に実行される手順のコレクションです。 デプロイ ジョブと従来のジョブは、同じステージに存在できます。 Azure DevOps では、runOnce、ローリング、カナリア戦略がサポートされています。

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

  • デプロイ履歴: 監査用のデプロイの特定のリソースと状態まで、パイプライン全体のデプロイ履歴を取得します。
  • デプロイ戦略の適用: アプリケーションのロールアウト方法を定義します。

デプロイ ジョブでは、ソース リポジトリを自動的に複製しません。 checkout: self を使用して、ジョブ内のソース リポジトリをチェックアウトできます。

注意

この記事では、デプロイ ジョブを使用したデプロイに焦点を当てています。 パイプラインを使用して Azure にデプロイする方法については、Azure へのデプロイの概要に関する記事を参照してください。

スキーマ

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

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 属性に応じて、エージェント ジョブまたは サーバー ジョブ (将来はコンテナーまたは検証ジョブ) に解決されます。 既定では、ライフサイクル フックは deploymentジョブで指定された pool を継承します。

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

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

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

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

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

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

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

RunOnce デプロイ戦略

runOnce は最も簡単なデプロイ戦略です。ここで、すべてのライフサイクル フック (つまり preDeploy deploy、、 routeTraffic、) postRouteTrafficが 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 で実行するライフサイクル フック ジョブが作成されます。

preDeploy、deploy、routeTraffic、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 回実行) がサポートされ、deploy、routeTraffic、postRouteTraffic ライフサイクル フックを使用して反復処理されます。 次に、success または failure フックを使用して終了します。

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

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

例

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) が自動的に継承されます。 これは、ジョブの複数のステップで同じ接続の詳細が設定されている場合に便利です。

Note

プライベート AKS クラスターを使用している場合は、API サーバー エンドポイントがパブリック IP アドレスを介して公開されないため、クラスターの仮想ネットワークに接続されていることを確認してください。

Azure Pipelines では、クラスターの仮想ネットワークにアクセスできる VNET 内にセルフホステッド エージェントを設定することをお勧めします。 詳細については、 プライベート クラスター に接続するためのオプションを参照してください。

ローリング デプロイ戦略

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['<job-name>.<step-name>.<variable-name>']] (例: $[dependencies.JobA.outputs['JobA.StepA.VariableA']])
  • runOnce 戦略と resourceType の場合: $[dependencies.<job-name>.outputs['Deploy_<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

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

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
      resourceName: vmsfortesting
      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.myOutputVarTwo'] ]
      myOutputVarTwo: $[ dependencies.A2.outputs['Deploy_vmsfortesting.setvarStepTwo.myOutputVarTwo'] ]
    
    steps:
    - script: "echo $(myOutputVarTwo)"
      name: echovartwo

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

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)

デプロイ ジョブから変数を出力する場合は、stageDependencies 構文を使用して、次のステージ (たとえば) $[stageDependencies.<stage-name>.<job-name>.outputs[Deploy_<resource-name>.<step-name>.<variable-name>]]から変数を参照します。

stages:
- stage: StageA
  jobs:
    - deployment: A1
      environment: 
        name:  env1
        resourceName: DevEnvironmentV
        resourceType: virtualMachine
      strategy:
        runOnce:
          deploy:
            steps:
              - script: echo "##vso[task.setvariable variable=myVar;isOutput=true]true"
                name: setvarStep
              - script: |
                  echo "Value of myVar in the same Job : $(setVarStep.myVar)"
                displayName: 'Verify variable in StageA'
- stage: StageB
  dependsOn: StageA

  # Full Variables syntax for inter-stage jobs
  variables:
    myOutputVar: $[stageDependencies.StageA.A1.outputs['Deploy_DevEnvironmentV.setvarStep.myVar']]
  jobs:
  - deployment: B1
    pool:
      vmImage: 'ubuntu-latest'
    environment: envB
    strategy:                  
      runOnce:
        deploy:
          steps:
          - bash: echo $(myOutputVar)

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

よく寄せられる質問

"ジョブが保留中です..." というメッセージが表示されてパイプラインが停止しています。 どうしたらいいですか。

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

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

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