Partager via

Amélioration de la sécurité des pipelines avec des variables en lecture seule

  • Article

Avec cette mise à jour, nous améliorons la sécurité des pipelines avec des variables en lecture seule. En outre, vous pouvez désormais définir des variables de sortie dans vos tâches dans n’importe quel hook de cycle de vie d’un travail de déploiement et les utiliser dans les étapes en aval et les travaux au sein de la même étape.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Fonctionnalités

Général :

Azure Pipelines :

Notes

L’installation de .NET 4.6.2 ou version ultérieure est nécessaire pour que la tâche VSTest fonctionne correctement sur les agents de build.

Général

Restreindre la création de organization via une stratégie de locataire Azure AD

Les administrateurs Azure DevOps peuvent désormais tirer parti d’une nouvelle stratégie Azure AD. Cette stratégie vous permet de limiter la création d’organisations Azure DevOps connectées à Azure Active Directory de votre entreprise. Pour en savoir plus sur la stratégie, consultez la documentation ici.

Azure Pipelines

Variables en lecture seule

Les variables système ont été documentées comme étant immuables, mais dans la pratique, elles peuvent être remplacées par une tâche et les tâches en aval récupèrent la nouvelle valeur. Avec cette mise à jour, nous renforforons la sécurité autour des variables de pipeline pour rendre les variables système et de mise en file d’attente en lecture seule. En outre, vous pouvez rendre une variable YAML en lecture seule en la marquant comme suit.

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

Prise en charge des variables de sortie dans un travail de déploiement

Vous pouvez maintenant définir des variables de sortie dans les hooks de cycle de vie d’un travail de déploiement et les consommer dans d’autres étapes et travaux en aval au sein de la même étape.

Lors de l’exécution de stratégies de déploiement, vous pouvez accéder aux variables de sortie entre les travaux à l’aide de la syntaxe suivante.

  • Pour la stratégie runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
  • Pour une stratégie avec contrôle de validité : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
  • Pour la stratégie propagée : $[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

En savoir plus sur la définition d’une variable de sortie multi-travaux

Éviter la restauration des modifications critiques

Dans les pipelines de mise en production classiques, il est courant de s’appuyer sur des déploiements planifiés pour les mises à jour régulières. Toutefois, lorsque vous avez un correctif critique, vous pouvez choisir de démarrer un déploiement manuel hors bande. Dans ce cas, les versions antérieures continuent de rester planifiées. Cela a posé un problème, car le déploiement manuel serait restauré lorsque les déploiements ont repris conformément à la planification. Beaucoup d’entre vous ont signalé ce problème et nous l’avons maintenant résolu. Avec le correctif, tous les anciens déploiements planifiés dans l’environnement sont annulés lorsque vous démarrez manuellement un déploiement. Cela s’applique uniquement lorsque l’option de mise en file d’attente est sélectionnée comme « Déployer le plus récent et annuler les autres ».

Suppression d’images plus anciennes dans les pools hébergés Azure Pipelines

Le 23 mars 2020, nous supprimerons les images suivantes de nos pools hébergés Azure Pipelines.

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

En supprimant ces images, nous continuerons à déployer des versions d’image plus récentes plus efficacement.

Pour en savoir plus sur la suppression de ces images, case activée le billet de blog suppression d’images plus anciennes dans les pools hébergés Azure Pipelines.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accédez à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Faire une suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Vijay Machiraju