Seguridad mejorada de canalizaciones con variables de solo lectura

Con esta actualización, estamos mejorando la seguridad de las canalizaciones con variables de solo lectura. Además, ahora puede definir variables de salida en las tareas dentro de cualquier enlace de ciclo de vida de un trabajo de implementación y consumirlas en pasos y trabajos de bajada dentro de la misma fase.

Consulte la lista de características que se muestra a continuación para obtener más información.

Características

General:

• Restricción de la creación de la organización a través de la directiva de inquilinos de Azure AD

Azure Pipelines:

Nota

La instalación de .NET 4.6.2 o posterior es necesaria para que la tarea VSTest funcione correctamente en los agentes de compilación.

• Variables de solo lectura
• Compatibilidad con variables de salida en un trabajo de implementación
• Evitar la reversión de los cambios críticos
• Eliminación de imágenes anteriores en grupos hospedados de Azure Pipelines

General

Restricción de la creación de la organización a través de la directiva de inquilinos de Azure AD

Los administradores de Azure DevOps ahora pueden aprovechar una nueva directiva de Azure AD. Esta directiva le permitirá restringir la creación de nuevas organizaciones de Azure DevOps conectadas a Azure Active Directory de su empresa. Para más información sobre la directiva, consulte la documentación aquí.

Azure Pipelines

Variables de solo lectura

Las variables del sistema se documentaron como inmutables, pero en la práctica podrían sobrescribirlas una tarea y las tareas de bajada recogerían el nuevo valor. Con esta actualización, se ajusta la seguridad en torno a las variables de canalización para que las variables de tiempo de cola y del sistema sean de solo lectura. Además, puede hacer que una variable YAML sea de solo lectura marcando como se indica a continuación.

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

Compatibilidad con variables de salida en un trabajo de implementación

Ahora puede definir variables de salida en los enlaces de ciclo de vida de un trabajo de implementación y consumirlas en otros pasos y trabajos de bajada dentro de la misma fase.

Al ejecutar estrategias de implementación, puede acceder a variables de salida entre trabajos mediante la siguiente sintaxis.

• Para la estrategia runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para la estrategia de valores controlados: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para la estrategia gradual : $[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

Más información sobre cómo establecer una variable de salida de varios trabajos

Evitar la reversión de los cambios críticos

En las canalizaciones de versión clásicas, es habitual confiar en implementaciones programadas para actualizaciones periódicas. Pero, cuando tenga una corrección crítica, puede optar por iniciar una implementación manual fuera de banda. Al hacerlo, las versiones anteriores siguen estando programadas. Esto plantea un desafío, ya que la implementación manual se revertiría cuando las implementaciones se reanudaron según la programación. Muchos de ustedes informaron de este problema y ahora lo hemos corregido. Con la corrección, todas las implementaciones programadas anteriores en el entorno se cancelarían al iniciar manualmente una implementación. Esto solo es aplicable cuando la opción de puesta en cola está seleccionada como "Implementar más reciente y cancelar otras".

Eliminación de imágenes anteriores en grupos hospedados de Azure Pipelines

El 23 de marzo de 2020, quitaremos las siguientes imágenes de nuestros grupos hospedados de Azure Pipelines.

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

Al quitar estas imágenes, se seguirán implementando versiones de imagen más recientes de forma más eficaz.

Para más información sobre la eliminación de estas imágenes, consulte la entrada de blog eliminación de imágenes anteriores en grupos hospedados de Azure Pipelines .

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.

Gracias,

Vijay Machiraju