Partager via

Nouvelle préversion publique de Boards Hubs

  • Article

New Boards Hubs est désormais disponible en préversion publique. La plateforme web a été mise à jour pour fournir une nouvelle conception moderne, des reflows réactifs, une conformité de l’accessibilité et des performances de page améliorées.

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

Général

Azure Boards

Azure Pipelines

Général

L’audit est désormais une fonctionnalité d’adhésion pour votre organization

L’audit est désormais devenu une fonctionnalité d’adhésion sur Azure DevOps. Si votre organization n’utilise pas activement l’audit aujourd’hui (c’est-à-dire qu’il a visité les journaux d’audit au moins deux fois au cours des 90 derniers jours ou qu’il a configuré un flux d’audit), vous devez activer explicitement la fonctionnalité d’audit pour que votre organization commence à le faire. Une fois activé, les événements d’audit sont inclus dans le journal d’audit de votre organization. Pour les organisations qui sont des utilisateurs actifs de l’audit, la fonctionnalité reste Activée.

Vous pouvez activer l’audit sur votre organization à partir de la page paramètres de votre organisation.

Dans la barre latérale droite, vous verrez Stratégies sous l’en-tête Sécurité. En supposant que votre organization est soutenu par Azure Active Directory, vous devez voir que l’une des stratégies de sécurité disponibles à activer est Les événements d’audit du journal. Les organisations soutenues par MSA n’auront plus à leur disposition les fonctionnalités d’audit.

Événements d'audit

Activez simplement cette stratégie et l’audit doit maintenant être disponible (si elle n’apparaît pas immédiatement, actualisez la page et elle doit être disponible). Si vous ne souhaitez plus recevoir d’événements d’audit, basculez le bouton sur Désactivé. Lorsque le bouton est désactivé, la page Audit n’apparaît plus dans la barre latérale et la page Journaux d’audit n’est plus disponible. Tous les flux d’audit configurés cesseront de recevoir des événements.

Les utilisateurs invités verront uniquement les données utilisateur publiques

Lorsque la stratégie d’accès des invités externes est désactivée et que la stratégie Autoriser les projets publics est activée, les utilisateurs invités ne peuvent voir que les données d’utilisateur publiques, telles que le nom d’affichage, etc., pour les membres de projets publics. Il s’agit de la même expérience accordée pour les utilisateurs anonymes. Cela s’applique à toutes les données personnelles disponibles via l’expérience web (par exemple, dans le sélecteur d’identité qui s’affiche lorsqu’un utilisateur tente de mention un autre utilisateur ou d’attribuer des éléments professionnels) et à toutes les données personnelles disponibles via nos API REST.

Azure Boards

Nouveaux hubs boards désormais disponibles en préversion publique

Depuis plusieurs mois, notre équipe se concentre sur la modernisation de l’expérience utilisateur pour les hubs Azure Boards. L’interface utilisateur a été mise à jour pour fournir une interface utilisateur plus rapide, une cohérence avec d’autres parties du produit et une accessibilité améliorée. L’équipe est heureuse d’annoncer enfin la préversion publique de la nouvelle expérience Azure Boards.

La fonctionnalité reste la même, mais vous pouvez vous attendre à ce qui suit :

  • Conception moderne
  • Reflows réactifs
  • performances améliorées
  • Conformité de l’accessibilité

Pour accepter la préversion publique, dans la section Fonctionnalités d’aperçu, activez la fonctionnalité nommée New Boards Hubs sur Activé.

Gif pour la démonstration opt-in à la préversion publique.

Si, pour une raison quelconque, les hubs New Boards vous causent un problème de blocage, vous pouvez désactiver la préversion. Mais essayez la nouvelle expérience et envoyez-nous vos commentaires. Veillez à nous faire savoir si quelque chose manque ou ne fonctionne pas comme prévu.

Azure Pipelines

Les modèles de pipelines YAML étendus peuvent désormais être transmis des informations de contexte pour les étapes, les travaux et les déploiements

Avec cette mise à jour, nous ajoutons une nouvelle templateContext propriété pour jobles composants de pipeline YAML , deploymentet stage destinés à être utilisés conjointement avec des modèles.

Voici un scénario d’utilisation templateContext:

  • Vous utilisez des modèles pour réduire la duplication de code ou pour améliorer la sécurité de vos pipelines

  • Votre modèle prend comme paramètre une liste de stages, jobsou deployments

  • Le modèle traite la liste d’entrées et effectue certaines transformations sur chacune des étapes, travaux ou déploiements. Par exemple, il définit l’environnement dans lequel chaque travail s’exécute ou ajoute des étapes supplémentaires pour appliquer la conformité

  • Le traitement nécessite que des informations supplémentaires soient transmises par l’auteur du pipeline dans le modèle pour chaque étape, tâche ou déploiement dans la liste

Intéressons-nous à un exemple. Supposons que vous créez un pipeline qui exécute des tests de bout en bout pour la validation des demandes de tirage. Votre objectif est de tester un seul composant de votre système, mais, comme vous envisagez d’exécuter des tests de bout en bout, vous avez besoin d’un environnement où davantage de composants du système sont disponibles et vous devez spécifier leur comportement.

Vous réalisez que d’autres équipes auront des besoins similaires. Vous décidez donc d’extraire les étapes de configuration de l’environnement dans un modèle. Son code ressemble à ce qui suit :

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

Pour chaque travail du testSet paramètre, le modèle définit la réponse des composants du système spécifiés par ${{ testJob.templateContext.requiredComponents }} pour renvoyer ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Ensuite, vous pouvez créer votre propre pipeline qui s’étend testing-template.yml comme dans l’exemple suivant.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Ce pipeline exécute deux tests, un positif et un négatif. Les deux tests nécessitent que le dimensionsapi composant soit disponible. Le positive_test travail attend le dimensionsapi code HTTP 200 de retour, tandis qu’il s’attend à ce qu’il negative_test retourne le code HTTP 500.

Date de mise hors service mise à jour pour les images hébergées windows 2016

Nous avons déplacé la date de mise hors service des images Windows 2016 du 1er avril au 30 juin. Bien que la plupart des clients qui utilisent cette image aient mis à jour leurs pipelines, certains clients utilisent encore cette image. Pour vérifier si votre organization utilise Windows 2016, suivez ces instructions pour identifier les pipelines à l’aide d’images dépréciées.

Pour aider les clients à identifier les pipelines, nous continuerons à effectuer des brownouts. Il s’agit de périodes de 24 heures pendant lesquelles l’image ne sera pas disponible, ce qui entraîne l’échec des travaux de pipeline qui s’exécutent pendant cette période. Les brownouts se produisent sur :

  • Lundi 18 avril
  • Mardi 26 avril
  • Mercredi 4 mai
  • Jeudi 12 mai
  • Vendredi 20 mai
  • Lundi 23 mai
  • Mardi 31 mai
  • Mercredi 8 juin
  • Jeudi 16 juin
  • Vendredi 24 juin
  • Lundi 27 juin

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

Comment fournir des commentaires

Nous aimerions savoir 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,

Aaron Hallberg