Segurança de pipelines aprimorada com variáveis somente leitura

Com essa atualização, estamos melhorando a segurança de pipelines com variáveis somente leitura. Além disso, agora você pode definir variáveis de saída em suas tarefas dentro de qualquer gancho de ciclo de vida de um trabalho de implantação e consumi-lo em etapas e trabalhos downstream dentro do mesmo estágio.

Confira a lista Recursos abaixo para obter detalhes.

Recursos

Geral:

• Restringir a criação da organização por meio de Azure AD política de locatário

Azure Pipelines:

Observação

A instalação do .NET 4.6.2 ou superior é necessária para que a tarefa VSTest funcione corretamente em agentes de build.

• Variáveis somente leitura
• Suporte para variáveis de saída em um trabalho de implantação
• Evitar a reversão de alterações críticas
• Removendo imagens mais antigas em pools hospedados no Azure Pipelines

Geral

Restringir a criação da organização por meio de Azure AD política de locatário

Os administradores do Azure DevOps agora podem aproveitar uma nova política de Azure AD. Essa política permitirá que você restrinja a criação de novas organizações do Azure DevOps conectadas ao Azure Active Directory da sua empresa. Para saber mais sobre a política, consulte a documentação aqui.

Azure Pipelines

Variáveis somente leitura

As variáveis do sistema foram documentadas como imutáveis, mas, na prática, elas poderiam ser substituídas por uma tarefa e as tarefas downstream captariam o novo valor. Com essa atualização, reforçamos a segurança em torno de variáveis de pipeline para tornar as variáveis de tempo de fila e sistema somente leitura. Além disso, você pode criar uma variável YAML somente leitura marcando-a da seguinte maneira.

variables:
- name: myVar
  value: myValue
  readonly: true

Suporte para variáveis de saída em um trabalho de implantação

Agora você pode definir variáveis de saída nos ganchos de ciclo de vida de um trabalho de implantação e consumi-las em outras etapas downstream e trabalhos dentro do mesmo estágio.

Ao executar estratégias de implantação, você pode acessar variáveis de saída entre trabalhos usando a sintaxe a seguir.

• Para a estratégia runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para estratégia canary: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para a estratégia sem interrupção : $[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:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: 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

Saiba mais sobre como definir uma variável de saída de vários trabalhos

Evitar a reversão de alterações críticas

Em pipelines de lançamento clássicos, é comum confiar em implantações agendadas para atualizações regulares. Mas, quando você tiver uma correção crítica, poderá optar por iniciar uma implantação manual fora de banda. Ao fazer isso, as versões mais antigas continuam agendadas. Isso representava um desafio, pois a implantação manual seria revertida quando as implantações fossem retomadas de acordo com o agendamento. Muitos de vocês relataram esse problema e agora o corrigimos. Com a correção, todas as implantações agendadas mais antigas no ambiente seriam canceladas quando você iniciasse manualmente uma implantação. Isso só é aplicável quando a opção de fila é selecionada como "Implantar mais recente e cancelar outras pessoas".

Removendo imagens mais antigas em pools hospedados no Azure Pipelines

Em 23 de março de 2020, removeremos as imagens a seguir de nossos pools hospedados no Azure Pipelines.

• Windows Server 2012 R2 com Visual Studio 2015 (vs2015-win2012r2)
• Mac OS High Sierra 10.13 (macOS-10.13)
• Windows Server Core 1803 (win1803)

Ao remover essas imagens, continuaremos a distribuir versões de imagem mais recentes com mais eficiência.

Para saber mais sobre a remoção dessas imagens, marcar a remoção de imagens mais antigas na postagem de blog de pools hospedados do Azure Pipelines.

Próximas etapas

Observação

Esses recursos serão lançados nas próximas duas a três semanas.

Vá até o Azure DevOps e dê uma olhada.

Ir para o Azure DevOps

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

Você também pode receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigada,

Vijay Machiraju