Partager via

Pools DevOps managés pour Azure DevOps (préversion)

Nous sommes heureux d’annoncer la préversion des pools DevOps managés, conçus pour aider les équipes de développement et d’ingénierie de plateforme à configurer et gérer rapidement des pools DevOps personnalisés.

En outre, nous avons amélioré les API d’estimation de l’utilisation du compteur pour GitHub Advanced Security, fournissant de nouvelles fonctionnalités qui vous aident à identifier les utilisateurs.

Pour plus d’informations, consultez les notes de publication.

Sécurité avancée GitHub pour Azure DevOps

Azure Pipelines

Sécurité avancée GitHub pour Azure DevOps

L’API d’utilisation du compteur de sécurité avancée renvoie désormais les identités des utilisateurs

Pour vous aider à identifier vos utilisateurs Advanced Security, les API d’estimation de l’utilisation du compteur retournent désormais l’identité Azure DevOps de chaque utilisateur, y compris leur nom d’affichage, CUID, identificateur de messagerie et de descripteur d’identité. Cette fonctionnalité est disponible au niveau de l’organisation, du projet et du référentiel. Pour utiliser ce nouveau point de terminaison, la syntaxe est similaire aux points de terminaison d’API d’utilisation de compteur existants, en ajoutant /details au point de terminaison :

  • Au niveau de l’organisation : GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Au niveau du projet : GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Au niveau du référentiel : GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

Analyse du code GitHub Advanced Security pour les projets C# et Java sans builds

L’analyse du code avec CodeQL implique l’exécution de requêtes sur des bases de données qui représentent le code dans votre référentiel pour une seule langue. Pour les langages compilés tels que C/C++, C#, Go, Java et Swift, cela nécessite généralement de générer le code en premier.

Toutefois, CodeQL, le moteur d’analyse statique derrière GitHub Advanced Security pour Azure DevOps, peut désormais analyser les projets C# et Java sans avoir besoin d’une build. Lorsque le mode de génération est défini sur « none », la base de données CodeQL est générée directement à partir de la base de code, en contournant l’étape de génération.

Pour toutes les langues compilées, le mode de génération par défaut est « manuel ». Toutefois, pour C# et Java, vous pouvez remplacer le mode de génération par « aucun ».

Vous pouvez configurer le mode de génération pendant la configuration d’AdvancedSecurity-Codeql-Init@1. Pour obtenir des instructions détaillées sur la configuration de l’analyse du code dans GitHub Advanced Security avec Azure DevOps, consultez Configurer l’analyse du code

Considération:

  • Si « aucun » est sélectionné et qu’un langage autre que les langages conformes pris en charge est C# ou Java, la tâche de pipeline peut ne pas fonctionner comme prévu.

  • Le mode de génération « none » fonctionne actuellement conjointement avec d’autres langages interprétés (par exemple, JavaScript, Python, Ruby).

  • Exemple valide : C# et JavaScript avec le mode de génération défini sur « none ». (JavaScript dans un langage interprété)

  • Exemple non valide : C#, JavaScript et Swift avec le mode de génération défini sur « none » (Swift n’est pas pris en charge en mode build « none »).

Capture d’écran de AdvancedSecurity-Codeql.

Azure Pipelines

Pools DevOps managés (préversion)

Les équipes d’ingénierie excellent lorsqu’elles peuvent se concentrer sur l’écriture de code pour développer des applications et des services pour leurs utilisateurs. Toutefois, dans la pratique, un temps important est souvent consacré à la gestion d’autres tâches, telles que la maintenance de l’infrastructure DevOps.

Nous sommes heureux d’annoncer la préversion publique des pools DevOps managés (MDP), une nouvelle fonctionnalité Azure DevOps conçue pour aider les équipes de développement et d’ingénierie de plateforme à déployer des pools DevOps personnalisés adaptés à leurs besoins uniques. MDP combine la flexibilité des agents Scale Set avec la facilité de maintenance associée aux agents hébergés par Microsoft, ce qui permet aux équipes d'établir la cohérence et les meilleures pratiques tout en optimisant les performances, la sécurité, la conformité et l’efficacité des coûts.

Les principaux avantages des pools DevOps managés sont les suivants :

  • Hébergé en votre nom : MDP est hébergé et géré par Microsoft, avec les machines virtuelles qui alimentent les agents créés et gérés dans les abonnements Azure appartenant à Microsoft.
  • Temps passé dans la gestion : MDP réduit considérablement le temps passé à gérer les agents, en particulier ceux basés sur l’infrastructure locale ou les systèmes gérés manuellement.
  • Pools spécifiques : En raison de la facilité avec laquelle de nouveaux pools peuvent être créés, les organisations peuvent facilement créer plusieurs pools spécifiques à l’équipe ou à la charge de travail.
  • Facturation DevOps : MDP permet d’optimiser la facture DevOps d’une équipe via de nombreuses fonctionnalités. Il permet aux équipes de trouver facilement un équilibre optimal entre la qualité de service/performances et le coût d’un pool.
  • Évolutif : MDP s'adapte à des milliers d'agents dans un pool unique.

Teams peut créer des pools avec des images de démarrage rapide qui contiennent le même logiciel présent dans les agents hébergés par Microsoft ou avec des images créées par l’équipe avec des conditions préalables propres à leur scénario.

En savoir plus sur les pools DevOps gérés en lisant notre billet de blog ou sa documentation.

Les tâches de pipelines Azure utilisent Le nœud 20

La plupart des tâches de pipeline utilisent Node comme exécuteur. Tâches des pipelines Azure qui utilisent NodeJS en tant qu'exécuteur utilisent désormais NodeJS 20. Les auteurs d’extensions de tâche doivent mettre à jour leurs tâches pour utiliser Node 20. Pour des conseils sur la mise à niveau, consultez Comment puis-je mettre à niveau ma tâche personnalisée vers la dernière version de Node ?.

Permission de créer un pipeline de construction

Pour augmenter la sécurité des pipelines, nous introduisons une nouvelle autorisation, Create build pipelineau niveau des pipelines.

Capture d’écran de l'autorisation de créer un pipeline de build.

Auparavant, l’autorisation Edit build pipeline était requise pour créer ou modifier un pipeline. Cela représentait un risque de sécurité, car il permettait à tous les utilisateurs de créer des pipelines pour modifier également les pipelines qu’ils n’ont pas créés. La prévention de cette situation a été longue.

Pour améliorer votre expérience de pipeline sans compromettre la sécurité, tous les utilisateurs et groupes disposant de l’autorisation Edit build pipeline reçoivent désormais également l’autorisation Create build pipeline .

Lorsqu’un pipeline est créé, son créateur reçoit l’autorisation Edit build pipeline .

Pour améliorer la sécurité des pipelines, vous pouvez choisir de supprimer l’autorisation Edit build pipeline des groupes d’utilisateurs tels que Contributeurs et Lecteurs. Cela garantit que, par défaut, seul le créateur du pipeline peut le modifier.

Note

L’autorisation Modifier le pipeline de build n’empêche pas d’autres utilisateurs de modifier un pipeline YAML ; elle protège uniquement les propriétés du pipeline contre la modification.

Pour les nouveaux projets, les utilisateurs et les groupes disposant de l’autorisation Edit build pipeline auront également l’autorisation Create build pipeline . Cela est susceptible de changer à l’avenir.

Vérification du verrouillage exclusif au niveau de l'étape

Certains cas d’usage nécessitent un pipeline pour accéder à une ressource spécifique une seule fois à un moment donné. Pour prendre en charge ce cas, nous avons la vérification du verrouillage exclusif.

Une situation similaire survient lorsqu'une seule exécution de pipeline doit accéder à une étape à un moment donné. Par exemple, si vous avez une étape qui se déploie sur un groupe de ressources Azure, vous pouvez empêcher plusieurs exécutions de pipeline de mettre à jour simultanément le même groupe de ressources. Pour l’instant, cela nécessite l’utilisation d’une ressource proxy, telle qu’un environnement, et la vérification du verrou exclusif sur cet environnement. Cette approche peut prendre du temps, ajouter de la complexité et augmenter les efforts de maintenance.

Dans ce sprint, nous introduisons la prise en charge de la spécification du verrou exclusif au niveau de l’étape. Si vous avez une étape avec un ID et spécifiez sa lockBehavior propriété, un verrou est automatiquement créé pour cette étape. Le sequential comportement reste cohérent pour les verrous au niveau des ressources et au niveau de l'étape. Toutefois, le runLatest comportement diffère, car il annule uniquement les runLatest builds pour la même branche, et non pour toutes les branches du pipeline.

Informations sur les modèles dans les exécutions du pipeline

Nous avons mis à jour l’API REST Pipeline Runs - Get avec des informations sur les modèles qui ont été étendus et inclus dans une exécution de pipeline.

Par exemple, considérez que vous disposez du code de pipeline YAML suivant :

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

La nouvelle API REST possède les nouvelles propriétés suivantes :

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Étapes de pipeline YAML déclenchées manuellement

Nous recevons fréquemment des demandes concernant les étapes de pipeline YAML déclenchées manuellement. Ces éléments sont utiles lorsque vous souhaitez un pipeline unifié, mais ne souhaitez pas toujours qu’il s’exécute jusqu'à son terme.

Par exemple, votre pipeline peut inclure des étapes pour la construction, les tests, le déploiement dans un environnement de préproduction et le déploiement en production. Vous pourriez vouloir que toutes les étapes s’exécutent automatiquement, sauf pour le déploiement en production, que vous préférez déclencher manuellement lorsqu’il est prêt.

Avec ce sprint, nous ajoutons la prise en charge des étapes de pipeline YAML déclenchées manuellement. Pour utiliser cette fonctionnalité, vous devez ajouter la trigger: manual propriété à une étape.

Prenons l’exemple de pipeline YAML suivant :

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Lorsque vous exécutez ce pipeline, l’expérience est la suivante :

Capture d’écran des étapes de pipeline YAML déclenchées manuellement.

Les étapes déclenchées manuellement n’ont aucune dépendance et peuvent être exécutées à tout moment. L'exécution du pipeline se termine lorsqu'il ne reste que des étapes déclenchées manuellement.

Étapes suivantes

Note

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éder à Azure DevOps

Comment fournir des commentaires

Nous aimerions entendre ce que vous pensez de ces fonctionnalités. Utilisez le menu d’aide pour signaler un problème ou fournir une suggestion.

Faire une suggestion

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

Merci

Silviu Andrica

  • Last updated on