Validations de conformité et de sécurité du pipeline - Sprint 141 Update

En juin de cette année, nous avons déployé la première itération de notre nouveau modèle de navigation. Nous avons passé l’été à améliorer cette expérience en fonction des commentaires que vous avez fournis. Merci ! L’étape suivante consiste à passer du nouveau modèle en préversion à la navigation du produit. Veuillez lire notre billet de blog décrivant les changements récents ainsi que notre calendrier pour l’intégration du nouveau modèle à toutes les organisations.

Nous comprenons l’importance de la recherche et rétablissons la zone de recherche développée sur l’en-tête de produit. En outre, vous pouvez maintenant appeler la zone de recherche en cliquant simplement sur « / » sur n’importe quelle page de service dans Azure DevOps. Cette fonctionnalité a été hiérarchisée en fonction d’une suggestion vocale de l’utilisateur.

Voici la zone de recherche par défaut :

Zone de recherche par défaut

Une fois que vous tapez un « / », la zone de recherche développée s’affiche :

Zone de recherche développée

Azure Pipelines

Azure Policy validations de conformité et de sécurité dans les pipelines

Nous voulons garantir la stabilité et la sécurité des logiciels dès le début du processus de développement tout en regroupant le développement, la sécurité et les opérations. Pour ce faire, nous avons ajouté la prise en charge de Azure Policy.

Azure Policy permet de gérer et d’éviter des problèmes informatiques avec des définitions de stratégies qui appliquent des règles et des effets pour vos ressources. Lorsque vous utilisez Azure Policy, les ressources restent conformes aux normes et aux contrats de niveau de service de votre entreprise.

Pour nous conformer aux instructions de conformité et de sécurité dans le cadre du processus de mise en production, nous avons amélioré notre expérience de déploiement de groupe de ressources Azure. À présent, nous échouons à la tâche de déploiement du groupe de ressources Azure avec des erreurs de stratégie pertinentes en cas de violations lors du déploiement de modèles ARM.

Azure Policy

En outre, nous avons ajouté Azure Policy modèle de définition de mise en production. Cela permet aux utilisateurs de créer des stratégies Azure et d’affecter ces stratégies à des ressources, des abonnements ou des groupes d’administration à partir de la définition de mise en production elle-même.

modèle Azure Policy

Livraison continue simplifiée aux machines virtuelles Azure

Dans cette version, nous avons ajouté un nouvel Assistant pour simplifier le processus de configuration de la livraison continue vers Azure Machines Virtuelles. Une fois que vous avez spécifié un organization Azure DevOps et un groupe de déploiement pour inscrire la machine virtuelle, un pipeline de mise en production est automatiquement créé avec un exemple d’étape de script. Si vous devez provisionner des ressources Azure supplémentaires, exécuter des scripts, mettre à niveau votre application ou exécuter des tests de validation supplémentaires, vous pouvez facilement personnaliser ce pipeline de mise en production.

Intégration continue vers machines virtuelles Azure

La tâche Xcode prend en charge Xcode 10 nouvellement publié

Coïncidant avec la version d’Apple de Xcode 10, vous pouvez maintenant définir vos projets pour générer ou être testés spécifiquement avec Xcode 10. Votre pipeline peut également exécuter des travaux en parallèle avec une matrice de versions de Xcode. Vous pouvez utiliser le pool d’agents macOS hébergé par Microsoft pour exécuter ces builds. Consultez les instructions relatives à l’utilisation de Xcode dans Azure Pipelines.

Xcode 10

Améliorations des performances lors de la mise en file d’attente d’une build

Lorsque vous utilisez un agent hébergé, vous obtenez une nouvelle machine virtuelle pour chaque travail. Cela fournit une couche supplémentaire de sécurité et de contrôle. Vous n’avez jamais à vous soucier d’une build précédente qui laisse autour des sorties ou fait quelque chose de malveillant sur la machine. Toutefois, les activités de démarrage pour la première fois signifiaient auparavant des retards entre le moment où vous cliquez sur Mettre en file d’attente une build et le moment où le pipeline est en cours d’exécution. Nous avons examiné et corrigé un grand nombre de ces retards, et nous constatons maintenant une accélération de 5 fois dans la file d’attente jusqu’au début dans les pools hébergés. Vous pouvez maintenant démarrer vos builds plus rapidement, ce qui signifie que vous pouvez itérer plus rapidement.

Créer une connexion de service Azure avec un principal de service qui s’authentifie avec un certificat

Vous pouvez maintenant définir une connexion de service Azure dans Azure Pipelines ou Team Foundation Server (TFS) avec un principal de service et un certificat pour l’authentification. La connexion de service Azure prenant désormais en charge le principal de service qui s’authentifie avec un certificat, vous pouvez désormais déployer sur Azure Stack configuré avec AD FS. Pour créer un principal de service avec l’authentification par certificat, reportez-vous à l’article sur la création d’un principal de service qui s’authentifie avec un certificat.

Se connecter avec le principal de service

Afficher l’analytique des tests dans les pipelines

Le suivi de la qualité des tests au fil du temps et l’amélioration de la documentation des tests sont essentiels au maintien d’un pipeline sain. La fonctionnalité d’analyse de test fournit une visibilité en quasi temps réel de vos données de test pour les builds et les pipelines de mise en production. Elle permet d’améliorer l’efficacité de votre pipeline en identifiant les problèmes de qualité répétitifs et à impact élevé.

Vous pouvez regrouper les résultats des tests selon différents éléments, identifier les tests clés pour votre branche ou vos fichiers de test, ou explorer un test spécifique pour afficher les tendances et comprendre les problèmes de qualité tels que la flakiness.

Consultez l’analyse des tests pour les builds et les mises en production, préversion ci-dessous :

Analyse des tests

Pour plus d’informations, consultez notre documentation.

Azure Repos

Modifier la branche cible d’une demande de tirage

Pour la plupart des équipes, presque toutes les demandes de tirage ciblent la même branche, par master exemple ou develop. Toutefois, dans le cas où vous devez cibler une autre branche, il est facile d’oublier de modifier la branche cible par défaut. Avec la nouvelle fonctionnalité permettant de modifier la branche cible d’une demande de tirage active, il s’agit désormais d’une action simple. Cliquez simplement sur l’icône de crayon près du nom de la branche cible dans l’en-tête de la demande de tirage.

Modifier la branche cible

Au-delà de la simple correction des erreurs, la fonctionnalité de modification des branches cibles permet également de « recibler » facilement une demande de tirage lorsque la branche cible a été fusionnée ou supprimée. Prenons l’exemple d’un scénario dans lequel vous avez une demande de tirage ciblant une branche de fonctionnalité qui contient certaines fonctionnalités dont vos modifications dépendent. Vous souhaitez passer en revue vos modifications dépendantes de manière isolée des autres modifications dans le branche de fonctionnalité, de sorte que vous ciblez features/new-featureinitialement . Les réviseurs peuvent ensuite voir uniquement vos modifications et laisser les commentaires appropriés.

Maintenant, réfléchissez à ce qui se passerait si le branche de fonctionnalité avait également une demande de tirage active et était fusionné dans master avant vos modifications ? Auparavant, vous devrez abandonner vos modifications et créer une nouvelle demande de tirage dans master, ou fusionner votre demande de tirage dans features/new-feature, puis créer une autre demande de tirage de à master.features/new-feature Avec cette nouvelle action pour mettre à jour la branche cible, vous pouvez simplement modifier la branche cible de la demande de tirage en features/new-featuremaster, en conservant l’ensemble du contexte et des commentaires. La modification de la branche cible crée même une nouvelle mise à jour de la demande de tirage qui facilite l’analyse des différences précédentes avant le changement de branche cible.

Mise à jour de la branche cible

Protéger les dépôts Git avec les paramètres de compatibilité multiplateforme

Étant donné que Git est une technologie multiplateforme, il est possible pour les fichiers ou les répertoires de trouver leur chemin vers un système de fichiers où ils peuvent être incompatibles sur une plateforme spécifique. Vous trouverez plus d’informations sur ces incompatibilités dans notre documentation.

Pour aider les équipes à protéger leur dépôt et ses développeurs, nous avons ajouté de nouveaux paramètres de dépôt pour bloquer les push contenant des commits avec des fichiers/répertoires incompatibles avec une ou plusieurs plateformes de système d’exploitation. En savoir plus sur ces paramètres.

Administration

Prendre en charge les utilisateurs AAD dans les comptes MSA

Azure DevOps prend désormais en charge les utilisateurs AzureAD (AAD) qui accèdent aux organisations qui sont soutenues par MSA. Pour les administrateurs, cela signifie que si votre organization Azure DevOps utilise des contrats MSA pour les utilisateurs d’entreprise, vous pouvez désormais permettre aux nouveaux employés d’accéder à l’aide de leurs informations d’identification AAD au lieu de créer une nouvelle identité MSA uniquement pour une utilisation avec Azure DevOps.

Nous pensons toujours que la meilleure expérience consiste pour les utilisateurs d’entreprise à connecter Azure DevOps à AAD, mais nous avons appris plus tôt cette année que les administrateurs avaient besoin de plus de temps pour effectuer cette conversion. En autorisant les utilisateurs AAD à accéder aux organisations soutenues par MSA, les nouveaux utilisateurs pourront accéder à Azure DevOps une fois qu’Azure DevOps aura empêché la création de nouveaux utilisateurs MSA avec des noms de domaine personnalisés soutenus par AzureAD à la fin du mois.

Pour les organisations qui utilisent déjà des identités AAD avec Azure DevOps, cette fonctionnalité ne s’applique pas. Pour les organisations qui utilisent actuellement des identités MSA, notez que tous les utilisateurs existants peuvent continuer à se connecter avec leurs identités MSA comme ils le font aujourd’hui. Cela s’applique uniquement aux utilisateurs ajoutés à l’avenir (qui ne peuvent potentiellement pas créer de MSA avec leur adresse e-mail d’entreprise).

Voici un exemple de scénario où cette expérience peut être utile : Dorothy est la propriétaire d'organisation Azure DevOps pour son entreprise, Fabrikam. Elle et son équipe de 10 membres de l’équipe se connectent à Azure DevOps avec des identités MSA qui utilisent leur adresse e-mail d’entreprise, par exemple Dorothy@fabrikam.com. Sam est un nouveau membre de l’équipe qui a rejoint l’entreprise aujourd’hui. Dorothy l’invite à azure DevOps en utilisant son e-mail, sam@fabrikam.com. Lorsqu’il clique sur le lien joindre maintenant dans l’e-mail, il peut se connecter à Azure DevOps avec la même identité AAD que celle qui lui a été donnée pour accéder à son courrier électronique avec Microsoft 365. Cela permet à Sam de collaborer avec ses 11 collègues et à Dorothy la liberté de connecter ses organization Azure DevOps à AAD lorsqu’elle est prête.

Pour plus d’informations, consultez notre billet de blog .

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu de commentaires 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,

Gopinath Chigakkagari (Twitter)

Partager via