DevOps Notes de version des intégrations

Nouveau :
- Intégrer l’outil de harnais dans ServiceNow
  - Intégrez l’outil d’orchestration Harness à la vélocité de changement DevOps. Cette intégration vous permet de connecter, de détecter, d’importer, de traiter des événements en temps réel et d’intégrer un CI/CD au changement dans les pipelines ServiceNow for Harness.
Changé:
- Intégration simplifiée des outils d’orchestration qui ne sont pas pris en charge dans le système de base
  - Le cadre de travail générique simplifié vous offre une solution facile à utiliser pour intégrer des outils d’orchestration personnalisés à la vélocité de changement ServiceNow DevOps, nécessitant une connaissance minimale de la plateforme. Il réduit la complexité de l’intégration en réduisant la quantité de codage personnalisé nécessaire et en simplifiant le processus global pour les clients et les partenaires. En rationalisant l’intégration de nouveaux outils d’orchestration, le cadre de travail permet une adoption plus rapide, une mise à l’échelle plus fluide et l’intégration d’équipes supplémentaires. Cela vous permet de rencontrer moins de défis d’intégration, d’accélérer le processus d’adoption par les utilisateurs et de réduire les frictions pendant la transition. Ce cadre de travail générique prend en charge l’intégration de tout outil d’orchestration qui n’est pas pris en charge nativement par ServiceNow dans le système de base.
- Champs personnalisés pour l’intégration de l’outil de planification
  - Apportez des champs personnalisés supplémentaires pour les éléments de travail et bénéficiez ainsi d’une configurabilité améliorée des outils de planification pris en charge dans le système de base par Vélocité de changement DevOps.
- Calcul du délai amélioré
  - Le calcul du délai prend désormais en compte les artefacts/packages enregistrés dans le cadre de l’exécution du pipeline et est calculé en fonction des validations qui lui sont associées.

Nouveau :
- Authentification OAuth 2.0 pour Azure DevOps (ADO)
  - Utilisez l’authentification OAuth 2.0 pour connecter votre outil Azure DevOps à la vélocité de changement DevOps, garantissant ainsi une méthode d’authentification plus sécurisée.
- Authentification OAuth 2.0 pour Jira Cloud
  - Utilisez l’authentification OAuth 2.0 pour connecter votre outil Jira Cloud à la vélocité de changement DevOps, garantissant ainsi une méthode d’authentification plus sécurisée.
Changé:
- Solution de conteneur Docker généralisée pour prendre en charge n’importe quel outil d’orchestration
  - Utilisez la solution de conteneur Docker généralisée et extensible pour intégrer n’importe quel outil d’orchestration à la vélocité de changement DevOps afin d’invoquer des actions de pipeline telles que la création de demandes de changement et la collecte de données DevOps pertinentes sans avoir à recourir à des modules d’extension ou des modules d’extension spécifiques à l’outil.
- Intégration simplifiée des outils de planification qui ne sont pas pris en charge dans le système de base
  - Intégrez des outils de planification qui ne sont pas pris en charge dans le système de base à l’aide de règles de transformateur. GitLab Issues est désormais disponible en tant qu’outil de planification et est conçu en tirant parti de cette nouvelle approche, afin que vous puissiez détecter des plans, importer des éléments de travail et configurer des webhooks pour les éléments de travail (problèmes) dans GitLab.
- Amélioration de l’expérience de création de changements DevOps manuels en permettant l’association directe d’éléments de travail
  - Ajoutez des données d’éléments de travail dans une demande de changement DevOps créée manuellement dans Espace de travail pour l’exploitation des services pour ITSM.

Intégrations DevOps améliorées pour prendre en charge les fonctionnalités de vélocité de changement DevOps suivantes :
- Changé:
  - Amélioration du parcours vers l’automatisation complète du changement à l’aide de modèles.
  - Prise en charge des réexécutions avec GitHub Action.
  - Prise en charge API_KEY pour le serveur Jira.
  - Conservez les détails des branches dans l’exécution du pipeline pour déterminer les validations à partir des artefacts et des packages.
- Enlevé:
  - Pour rendre le flux Changement - Implémentation DevOps du modèle DevOps plus adapté aux changements DevOps, les tâches de changement ne sont plus créées automatiquement.
  - Le flux d’approbation d’automatisation minimale de demande de changement DevOps et les flux d’approbation d’automatisation avancée de demande de changement DevOps ne se déclenchent pas pour les demandes de changement DevOps dont le modèle est un modèle de changement DevOps du système de base (DevOpsorDevOpssimplifié) afin d’éviter les conflits et les erreurs.
- Remarque : pour des informations détaillées sur les fonctionnalités, consultez les notes de mise à jour de DevOps Change Velocity.

Nouveau :
- Prise en charge de l’intégration de l’outil d’orchestration personnalisé
  - Intégrez la vélocité de changement DevOps à tout outil d’orchestration qui n’est pas pris en charge dans le système de base.
- Amélioration de la gestion des erreurs d’intégration et des garde-fous
  - Affichez des messages d’erreur améliorés qui vous aident à trouver la cause première d’un problème lors de l’intégration (connexion, détection, configuration ou importation) d’un outil.
- Création d’une demande de changement avec des erreurs lors de la récupération de données DevOps
  - Activez la création de demandes de changement même s’il y a une erreur lors de la récupération des données DevOps dans un pipeline.
- Prise en charge des demandes de fusion / extraction GitLab
  - Gérez les demandes d’extraction des pipelines GitLab pour le code source GitLab de ServiceNow DevOps.
- Prise en charge de JFrog Artifactory pour GitHub Actions, Azure DevOps et GitLab
  - Importez les données d’artefact publiées dans JFrog Artifactory pour les exécutions de pipelines GitHub Actions, Azure DevOps et GitLab.
- Plusieurs configurations ServiceNow DevOps dans la même instance Jenkins
  - Configurez plusieurs connexions ServiceNow DevOps dans un serveur Jenkins.
Changé:
- Prise en charge de Jira Cloud
  - Intégrez Jira Cloud à la vélocité de changement DevOps en plus de Jira sur site.
- Améliorations des conteneurs Docker GitLab
  - Récupérez et mettez à jour les détails de la demande de changement associés à un pipeline GitLab et publiez les résultats des tests unitaires. La mise à jour automatique du code de fermeture, en fonction de l’état global d’exécution du pipeline pour les pipelines GitLab simples, est également prise en charge.

Nouveau :
- Intégration des problèmes GitHub
  - GitHub prend désormais en charge l’aptitude Plan avec l’intégration des problèmes GitHub en plus des fonctionnalités de code et d’orchestration. Les problèmes GitHub du dépôt peuvent également être détectés et liés aux validations GitHub et conservés dans le CHG ServiceNow DevOps, qui peut être utilisé pour les décisions de politique d’accélération du CHG ServiceNow DevOps.
- Divers types de tests unitaires pris en charge pour les actions GitHub
  - Publiez automatiquement les résultats des tests de divers rapports des outils de test unitaires tels que NUnit, pytest, jest, JUnit, XUnit sans aucun appel d’API personnalisé à publier dans le CHG ServiceNow DevOps.
- Expérience d’automatisation des changements guidée
  - De meilleurs conseils intégrés au produit sont désormais fournis sur les différentes façons d’exploiter les changements DevOps et sur la manière d’adopter facilement les changements DevOps sans perturber complètement votre processus de changement. Un exécution pas à pas vous guide pour automatiser la création de changements DevOps. Vous pouvez vérifier l’état de connexion d’un outil lors de la sélection d’un pipeline sur l’exécution pas à pas et vous êtes également alerté avant de passer à l’étape suivante. Deux nouveaux flux de transition d’état : Changement - DevOps - Nouveau et Changement - Calendrier DevOps, pour le modèle de changement DevOps sont introduits pour déplacer et suivre les changements à travers ces états. Le script DevOpsChangeRelationshipHelper a été introduit pour récupérer les données associées à une demande de changement en fonction du type de relation spécifié.
- Gestion de la limitation de débit d’Azure DevOps et de GitHub API
  - Lorsque les limites de débit d’Azure DevOps ou de l’API GitHub sont dépassées, la vélocité de changement DevOps reporte le traitement des nouveaux événements jusqu’à ce que la limitation GitHub se soit calmée pour gérer de gros volumes de données.
- Prendre en charge la pagination dans Détecter les demandes d’importation pour les pipelines, les dépôts et les plans pour Azure DevOps et GitHub
  - Les données sont maintenant récupérées à partir d’outils tiers par lots (de manière paginée). Cela vous aidera à évoluer en intégrant de nombreuses équipes disposant de gros volumes de données.
  - Suppression des rôles d’administrateur de connexion et de concepteur de flux pour les administrateurs DevOps et propriétaires de l’outil
    - La visibilité et les capacités de modification des administrateurs DevOps et des propriétaires d’outils ont été limitées par la suppression des rôles Concepteur de flux et Administrateur de connexion pour ces utilisateurs.
- Modifications apportées aux artefacts et aux packages
  - L’expérience globale en matière d’adoption, d’implémentation et de gestion des erreurs pour les artefacts et les packages a été améliorée. L’API d’enregistrement des artefacts et des packages, pour Jenkins et ADO, fournit désormais un message clair dans la réponse concernant le statut. Les utilisateurs peuvent voir si la version de l’artefact est déjà présente, intermédiaire ou créée, et peuvent également voir le motif en cas de rejet. Un message clair est disponible sur la console, ainsi qu’un lien permettant d’accéder à la page de l’artefact. L’API DevOpsDPRHelper prend désormais les exécutions de pipeline comme entrée pour obtenir des données sur les vulnérabilités, les résultats des tests et la couverture du code. L’expérience de dépannage a été améliorée par l’ajout d’une colonne de description expliquant pourquoi une version ou un package d’artefact est en attente. Un nouveau module de liste comprenant des listes d’artefacts, de packages et de packages en attente a été créé pour faciliter l’accès à ces informations dans l’espace de travail de changement DevOps.
- Améliorations du traitement des notifications GitLab
  - L’évolutivité a été améliorée grâce à une gestion transparente des événements GitLab. Un préfiltrage a été introduit sur les événements entrants pour réduire le nombre d’événements de flux et d’appels d’API. La prise en charge de la limitation des limites de taux a été activée pour les flux de détection et d’importation, ainsi que pour les événements webhook. Les flux secondaires GitLab tels que GitLab CI Notification ont été repensés pour réduire les interférences dans le suivi de l’état d’attente, ce qui a optimisé le nombre d’appels REST effectués pour récupérer les informations du projet.
- Changements de l’intégration de SonarQube
  - L’état de la porte de qualité globale SonarQube pour le résumé de l’analyse est désormais pris en charge et l’intégration de SonarQube avec les pipelines GitLab est également prise en charge à l’aide du conteneur Docker ServiceNow DevOps Gitlab.
- Supprimé : la dépendance du spoke GitHub a été supprimée.

Nouveau :
- Mise à jour automatique du code de fermeture en fonction de l’état d’exécution global du pipeline
  - Le changement créé à partir d’un pipeline est maintenant automatiquement fermé et mis à jour avec les notes de fermeture et l’heure de début et de fin réelle en fonction de l’état d’achèvement global du pipeline. Ceci est contrôlé par un marqueur de configuration qui peut être transmis en tant qu’attribut dans l’étape de création CHG ou via la configuration au niveau du pipeline dans Vélocité de changement DevOps.
- État de la connexion et de la configuration de l’outil
  - Pour Jenkins, GitHub et Azure DevOps, les indicateurs d’état de connexion et de configuration sont mis à jour. Vous pouvez également tester facilement les connexions de l’outil. L’état global de l’outil est maintenant mis à jour sur Connecté, Déconnecté, À surveiller, en fonction de l’état de la connexion, des informations d’identification de l’outil, de la vérification des autorisations et de l’état de configuration du Webhook.
- Prise en charge de l’organisation GitHub
  - L’organisation GitHub est désormais prise en charge avec l’outil GitHub connecté via l’authentification de base ou l’application GitHub à l’aide du code d’autorisation, avec des privilèges d’adhésion mis à jour en conséquence dans l’outil GitHub. Et l’application GitHub utilisant JWT prend en charge une organisation par outil, mais avec plusieurs connexions d’outils, plusieurs organisations peuvent être prises en charge.
- Divers types de tests unitaires pris en charge pour Azure DevOps (ADO)
  - Publiez automatiquement les résultats des tests de divers rapports d’outils de test tels que NUnit, pytest, jest, JUnit, XUnit sans aucun appel d’API personnalisé à publier dans le DevOps CHG.
- Prise en charge de la demande d’extraction (PR) / demande de fusion pour Azure DevOps (ADO)
  - Les exécutions de pipelines de demandes d’extraction ADO sont désormais suivies dans DevOps Change Velocity et les métadonnées suivantes sont publiées dans le CHG, ID de demande d’extraction, Validations, Branche d’origine, Branche de destination, Soumis par, Approbateur, Commentaires, Heure de levée de PR, Heure d’approbation de PR, Heure de fusion/fermeture de PR.
- Gestion de la limitation du débit de l’API GitHub
  - Lorsque les limites de débit de l’API GitHub sont dépassées, la vélocité de changement DevOps reporte le traitement des nouveaux événements jusqu’à ce que la limitation GitHub soit terminée. Cela augmentera les performances globales pour de grands volumes de données.
- Prise en charge de Checkmarx
  - Connectez Checkmarx intégré à vos pipelines de CI/CD à la vélocité de changement DevOps pour récupérer les résultats de l’analyse de sécurité. Cela vous aide à déterminer la vulnérabilité de votre code. Les analyses CheckMarx configurées sur GitHub Actions, Jenkins et les pipelines Azure DevOps sont prises en charge dans le système de base. Vous pouvez afficher les résultats de l’analyse de sécurité dans la liste connexe d’une demande de changement ou dans l’exécution des tâches du pipeline dans votre instance ServiceNow ou dans l’interface utilisateur du pipeline. Vous pouvez utiliser les résultats de la sécurité pour définir les politiques de changement et les conditions pour l’automatisation des changements. Checkmarx One et Checkmarx SAST sont tous deux pris en charge.
- Prise en charge multimodèle> >changements
  - Migrez tous vos pipelines existants pour utiliser des modèles à l’aide du catalogue de migration de pipeline DevOps vers les modèles de changement. En outre, vous pouvez transmettre les modèles de changement par nom à partir de vos pipelines d’outils d’orchestration.

Nouveau :

Nouveau :
- Cadre de travail de sécurité
  - Un nouveau cadre de travail d’intégration et un nouveau modèle de données ont été ajoutés spécifiquement pour les outils de sécurité des applications. Il s’agit d’un cadre de travail extensible qui vous permet également de créer des intégrations personnalisées avec n’importe quel outil de sécurité des applications.
- Prise en charge de Veracode
  - Connectez Veracode intégré à vos pipelines de CI/CD à la vélocité de changement DevOps pour récupérer les résultats de l’analyse de sécurité. Cela vous aide à déterminer la vulnérabilité de votre code. Les analyses Veracode configurées sur GitHub Actions, Jenkins et les pipelines Azure DevOps sont prises en charge dans le système de base. Vous pouvez afficher les résultats de l’analyse de sécurité dans la liste connexe d’une demande de changement ou dans l’exécution des tâches du pipeline dans votre instance ServiceNow ou dans l’interface utilisateur du pipeline. Vous pouvez utiliser les résultats de la sécurité pour définir les politiques de changement et les conditions pour l’automatisation des changements.
- Prise en charge multimodale
  - Le changement multimodal est une nouvelle fonctionnalité de gestion des changements qui offre une plus grande flexibilité dans la définition de modèles ou de processus de changement pour refléter les pratiques de développement modernes. DevOps prend en charge cette nouvelle fonctionnalité à l’aide de laquelle vous pouvez créer des modèles de changement avec des états et des règles qui déterminent les transitions entre les états pour fournir des modèles de changement « adaptés aux besoins » avec une suite de flux et d’actions de flux succincts intégrées dans Flow Designer. Grâce aux modèles de changement DevOps, les équipes de changement peuvent désormais effectuer une transition sélective vers un large éventail de modèles entièrement optimisés pour leurs cas d’utilisation spécifiques
- Authentification par jeton sécurisé pour l’utilisateur d’intégration
  - Azure DevOps, Jenkins et GitHub Actions prennent désormais en charge l’authentification basée sur des jetons pour l’utilisateur d’intégration. Jenkins prend en charge l’authentification de base et l’authentification par jeton pour le rendre compatible avec DevOps Config.
- Exécuter des validations pour GitHub Actions et Azure DevOps
  - Augmentez la traçabilité en capturant la liste complète des validations d’exécution pour un changement dans GitHub Actions et Azure DevOps.
- Changements de l’espace de travail pour l’intégration et les aperçus
  - Cela inclut la validation de l’installation de l’extension ServiceNow DevOps dans Azure DevOps avant de configurer les webhooks, l’importation automatique des étapes du pipeline lors de la configuration de l’automatisation des changements, les icônes d’informations pour les widgets Analyses DevOps et de meilleurs visuels pour les widgets de score de mesure de flux et d’accélération pour les analyses DevOps.
- Journalisation des transitions d’états des changements dans l’outil d’orchestration et les détails de la condition de politique
  - Les informations de changement, telles que le numéro du changement, l’état, le groupe d’affectation, les approbateurs, la date de début/fin prévue s’affichent dans les journaux de console des pipelines Azure DevOps et des workflows d’action GitHub, tandis que le pipeline ou le workflow est en attente d’approbation de changement. L’application ServiceNow DevOps est interrogée à intervalles réguliers et, s’il y a une différence dans les informations de changement, elle est journalisée directement dans les journaux de la console, ce qui réduit les sauts vers l’instance ServiceNow. Les détails de la condition de politique, qui a échoué, sont également consignés dans la console de l’outil d’orchestration.
- Obtenir et mettre à jour les détails de la demande de changement DevOps
  - Obtenez et mettez à jour les détails de la demande de changement associés à un pipeline Azure DevOps et à un workflow d’action GitHub, à l’aide de l’extension ServiceNow DevOps d’Azure DevOps et de la place de marché GitHub Action. Ces extensions ou actions personnalisées peuvent être utilisées pour obtenir le changement, le mettre à jour et le fermer si nécessaire, en transmettant les attributs nécessaires.
- Portails de déploiement d’actions GitHub
  - ServiceNow DevOps Change Velocity prend désormais en charge les portails de déploiement d’actions GitHub pour ses environnements. En intégrant cette fonctionnalité à ServiceNow DevOps, les développeurs peuvent appliquer des portails de qualité sur chaque environnement de déploiement dans GitHub Actions et obtenir les détails du changement à partir des journaux de la console Règle de protection du déploiement de GitHub Actions, ainsi que la progression des états de changement comme approuvé ou rejeté.
- Configurer les webhooks manuellement
  - Vous pouvez désormais choisir de configurer les webhooks manuellement plutôt que de les configurer automatiquement à partir de la vélocité de changement ServiceNow DevOps. Vous pouvez utiliser cette fonctionnalité pour accéder au jeton et au sysid. À l’aide de ces informations, l’administrateur de l’outil au sein de votre organisation peut configurer les webhooks manuellement. Il n’est accessible que pour les rôles d’administrateur DevOps et de propriétaire de l’outil.
- Connexion et informations d’identification ServiceNow DevOps
  - La configuration initiale de la vélocité de changement ServiceNow DevOps par les administrateurs ServiceNow a été simplifiée. Il n’est plus nécessaire de configurer l’utilisateur d’intégration avec les informations d’identification de l’authentification de base. La configuration de l’alias CreateDevOpsTool a été supprimée.
- Gestion optimale des événements ServiceNow DevOps pour améliorer les performances
  - ServiceNow DevOps filtre les événements ignorables avant qu’ils ne déclenchent une exécution de flux. Cela améliorera les performances de la gestion des événements et la bande passante d’exécution de Flow Designer pour les événements importants, améliorant ainsi le délai de réponse global. Cela permet également aux administrateurs DevOps d’ajouter des webhooks d’outils avec une portée plus large sans affecter les performances du système.
Corrections majeures.

Changements:

Prise en charge de l’organisation Azure DevOps
- Connectez un outil à Azure DevOps directement au niveau de l’organisation. Les projets au sein de l’organisation sont détectés automatiquement. Vous pouvez configurer des webhooks pour plusieurs projets à la fois et mettre facilement à jour les informations d’identification au niveau de l’organisation. Il n’est donc plus nécessaire de connecter un outil par projet ADO.
Accès au groupe pour les outils et les applications
- Contrôlez l’accès aux outils et aux applications en ajoutant des groupes d’utilisateurs au champ Géré par. Les utilisateurs appartenant aux groupes ajoutés ne peuvent accéder qu’à cet outil ou à cette application, et ne peuvent les modifier que si leurs rôles le permettent. Un nouveau rôle, propriétaire de l’outil DevOps, a été introduit. Les utilisateurs disposant de ce rôle peuvent uniquement connecter des outils et n’auront pas accès à des options d’administration DevOps supplémentaires telles que les propriétés système.
Récupérer automatiquement les étapes du pipeline lors de l’association à une application
- Lors de l’association d’un pipeline à une application, les étapes du pipeline sont également récupérées pendant l’importation. Il n’est plus nécessaire d’exécuter un pipeline une seule fois pour que les étapes soient mappées dans ServiceNow DevOps.
Messages d’erreur mis à jour
- Des messages d’erreur améliorés sont affichés dans les événements entrants et les demandes d’importation pour aider à trouver la cause première d’un problème pour les notifications en temps réel. Les messages d’erreur identifient les problèmes actifs pertinents, mettent en évidence des problèmes spécifiques et expliquent comment les atténuer.
Notification d’expiration des informations d’identification
- Les administrateurs et les propriétaires d’outils sont informés lorsque les informations d’identification de l’outil expirent ou sont sur le point d’expirer. Ils seront alertés par e-mail, tâche universelle, icône de notification en forme de cloche et message sur l’enregistrement de l’outil. Cela permet d’éviter toute perte de données.
Dernier événement reçu
- Alertez les administrateurs DevOps lors de la dernière réception d’événements pour les avertir de tout problème éventuel pouvant survenir avec la connexion de leur outil. Le champ Dernier événement reçu de l’enregistrement de l’outil facilite le dépannage des problèmes de connexion. Vous pouvez définir le nombre de jours d’affichage des alertes d’avertissement ou critiques dans le champ Dernier événement reçu de l’enregistrement de l’outil lorsque les événements n’ont pas été reçus.
Journalisation de l’état du changement pendant que le pipeline est en attente de la décision de reprise de l’exécution
- Les informations sur le changement, telles que le numéro du changement, l’état, le groupe d’affectation, les approbateurs et la date de début/fin planifiée s’affichent dans les journaux de console des actions Jenkins et GitHub, tandis que le pipeline/workflow est en attente d’approbation des changements. L’application ServiceNow DevOps est interrogée à intervalles réguliers et, s’il y a une différence dans les informations de changement, elle est journalisée directement dans les journaux de la console, ce qui réduit les sauts vers l’instance ServiceNow.

Fixe:

GitHub : l’action de détection échoue si un référentiel déjà détecté est supprimé de GitHub.
L’utilisateur disposant du rôle « sn_devops.viewer » du changement DevOps est en mesure de voir le lien de l’espace de travail Configuration DevOps.
SonarQube/SonarCloud : dans une demande de changement, l’enregistrement du résumé de la qualité logicielle non-administrateur est remplacé par l’enregistrement suivant au lieu de créer un nouvel enregistrement de résumé.
La création d’un changement échoue si des politiques de données sont présentes sur les attributs de changement.
Impossible de modifier la vue par défaut de la liste connexe Demande de changement lorsque la vélocité de changement DevOps est installée.
Azure DevOps : lorsque le type d’étape n’est pas déploiement produit, les listes connexes Élément de travail et Validations pour le changement affichent des entrées incorrectes.
Jira : des éléments de travail en double sont créés si un problème est mis à jour immédiatement après sa création.
L’utilisateur disposant du rôle de visionneur DevOps ne peut pas accéder aux analyses de KPI pour tous les widgets Insights de l’espace de travail.
Si une validation est traitée dans DevOps, supprimée dans DevOps, puis revalidée à partir de GitHub, les détails du validateur pour la validation ne sont pas conservés.
# incorrect de tests affichés dans le widget Activité de l’application au cours des 30 derniers jours.

Modifié
- Amélioration de la gestion des erreurs et des garde-fous : amélioration des messages d’erreur pour aider à trouver la cause première d’un problème lors de l’intégration (connexion, détection, configuration ou importation) d’un outil. Les messages d’erreur identifient les problèmes actifs pertinents, mettent en évidence des problèmes spécifiques et expliquent comment les atténuer.
- Changements apportés à l’espace de travail de changement DevOps :
  - Configuration initiale simplifiée du système pour les administrateurs ServiceNow, qui inclut l’état de la configuration, une meilleure identification du périmètre nécessaire, la possibilité de définir de nouveaux mots de passe pour le compte utilisé pour configurer l’alias d’informations d’identification, une validation supplémentaire, etc.
  - Extension du rôle de propriétaire d’application, qui comprend la possibilité de modifier les étapes du pipeline pour affecter des services d’application ou de configurer l’automatisation des changements. Les propriétaires d’applications peuvent également cliquer sur Détecter pour trouver des outils permettant d’associer de nouveaux objets nécessaires pour leur application DevOps. Mise à jour de l’administration des outils, qui inclut la possibilité de mettre à jour facilement les informations d’identification pour chaque outil et de vérifier les autorisations pour les informations d’identification données.
- Intégration Rally : connectez-vous à l’outil de planification Broadcom Rally pour importer des objets de planification Rally tels que des épopées, des stories, des bogues et des tâches dans les données DevOps en tant qu’éléments de travail. L’intégration Rally prend en charge la découverte d’éléments de travail, la configuration de webhooks pour envoyer des données en temps réel et l’importation de données historiques. Les éléments de travail Rally peuvent être associés à des validations utilisées pour accélérer les demandes de changement.
- Authentification GitHub OAuth JWT : l’authentification sécurisée de la connexion de l’outil GitHub est désormais prise en charge à l’aide d’OAuth JWT (jetons Web JSON). L’authentification OAuth-JWT à l’aide d’une clé privée générée dans GitHub est désormais prise en charge.
- Obtenir et mettre à jour les détails de la demande de changement DevOps : obtenez et mettez à jour les détails de la demande de changement associés à un pipeline Jenkins en exécutant les scripts snDevOpsGetChangeNumber et snDevOpsUpdateChangeInfo respectivement dans le pipeline Jenkins.
- Mesures d’accélération DevOps : désormais également affichées dans l’espace de travail Gestion des portefeuilles numériques par application d’entreprise.
Fixe
- L’application Analyses DevOps 1.36 ajoute des ACL, ce qui masque les CI de service d’entreprise et d’application d’entreprise dans la CMDB.
- L’abonnement DevOps n’ajoute pas les utilisateurs ayant un rôle affecté via un groupe d’affectation à la table Participants.
- Le champ Propriétaire n’est pas renseigné lorsque l’application est créée via l’intégration de l’application.
- La découverte Jenkins échoue avec un grand nombre de pipelines/tâches.
- Lorsque le nom du pipeline est le même dans tous les outils (par exemple, Gitlab, Jenkins), les exécutions de pipeline d’un outil sont mappées à un autre outil.
- Les détails de branche sont manquants pour la validation en raison d’une condition de concurrence lorsque les événements de balise et de branche sont traités simultanément.
- La case « Voulez-vous configurer ? » est manquante sur le portail de services pendant l’intégration de l’application.
- Le traitement des validations en bloc GitHub conserve plus de validations que nécessaire.
- Pour un pipeline Azure DevOps (ADO) avec une seule étape et la réception du changement activées, le CR est créé avec une date de début effective postérieure à la date de fin effective.
- La détection Gitlab renseigne uniquement les 100 premiers (valeur définie dans la propriété import.coding_tool.repos.per_page) référentiels et pipelines.
- Le nom de classe CI « Package » créé à partir du package DevOps est en conflit avec le package du système d’exploitation CI CMDB.

Nouvelle
- Amélioration des messages d’erreur pour vous aider à trouver la cause première d’un problème lors de la connexion à un outil. Les messages d’erreur identifient les problèmes actifs pertinents, mettent en évidence des problèmes spécifiques et expliquent comment les atténuer.
- Vous pouvez désormais spécifier un serveur MID particulier directement sur la page de l’espace de travail de changement DevOps lors de la connexion à un outil.

Intégration des actions GitHub :

GitHub est un outil de codage qui est maintenant mis à jour pour prendre en charge l’aptitude d’orchestration des actions GitHub dans ServiceNow DevOps. Vous utilisez les actions personnalisées ServiceNow DevOps (publiées sur GitHub Actions Marketplace) pour intégrer les pipelines GitHub Actions et les environnements GitHub.
Pour mettre à jour le modèle de données, l’intégration des actions GitHub nécessite que GitHub soit connecté et configuré et que les pipelines soient détectés. Les workflows GitHub Actions sont mis en pause et reprennent à l’aide d’actions personnalisées

Les actions personnalisées suivantes sont publiées dans le référentiel GitHub :

Changement ServiceNow DevOps
Rapport de test ServiceNow DevOps
ServiceNow DevOps Sonar
ServiceNow DevOps : enregistrer l’artefact
Enregistrer le package ServiceNow DevOps

Importation et interrogation historiques pour Azure DevOps Artifacts :

Importez des données historiques pour les artefacts ADO à l’aide du catalogue en libre-service d’intégration d’application et d’interrogations périodiques pour extraire les données. Le cadre de travail d’importation permet d’intégrer des équipes en récupérant les données DevOps dans l’instance sans avoir à modifier le pipeline ou à configurer des webhooks. Les données importées fournissent des informations sur les causes premières d’une traçabilité complète des changements, ce qui permet d’identifier les causes premières et les domaines d’amélioration.

Politique d’approbation des changements prête à l’emploi Entrées de risque et motifs de rejet :

La politique d’approbation des changements par défaut DevOps améliore la politique d’automatisation et d’approbation des changements. Les conditions de politique s’exécutent sur les données DevOps collectées pour un rejet automatique, une approbation automatique ou un report pour approbation manuelle. Les données peuvent être des mesures sur les validations, la couverture du code, les résultats des tests, les résultats d’analyse Sonar, les entrées de risque, etc. La politique d’approbation de changement est configurable. Pour aider les utilisateurs à prendre rapidement des mesures correctives, les motifs du rejet sont consignés dans les notes de travail du CHG.

Générateur d’extraits Jenkins :

Le module d’extension Jenkins pour ServiceNow DevOps peut générer des étapes de pipeline scriptées DevOps. Cela aide les développeurs à adopter rapidement les fonctionnalités de ServiceNow DevOps et à modifier facilement les pipelines.

Modifié
- Politique d’approbation des changements prête à l’emploi : la politique d’approbation des changements DevOps par défaut prête à l’emploi est implémentée pour mettre à jour la politique d’automatisation et d’approbation des changements. Les conditions de politique sont appliquées aux données DevOps collectées pour un rejet automatique ou une approbation automatique ou un report pour approbation manuelle. Les données DevOps peuvent être des mesures sur les validations, la couverture de code, les résultats des tests, les résultats d’analyse Sonar, entre autres. La politique d’approbation de changement est configurable.
- Importer des données historiques pour les outils DevOps : Azure DevOps : importez des données historiques pour toutes les options (Code, Plan et Orchestration) à l’aide du catalogue en libre-service d’intégration d’application et d’interrogations périodiques pour extraire les données. Le cadre de travail d’importation permet d’intégrer des équipes en récupérant les données DevOps dans l’instance sans avoir à modifier le pipeline ou à configurer des webhooks. Les données importées fournissent des informations sur les causes premières d’une traçabilité complète des changements. À partir de la version 1.34, vous pouvez importer les données et configurer un mécanisme d’interrogation pour Azure DevOps.
- jFrog - Intégration Jenkins Artifactory : intégrez Jenkins et jFrog Artifactory dans ServiceNow DevOps et utilisez ces données pour la traçabilité et la liaison des pipelines CI/CD dans ServiceNow. Associez les pipelines de version (CI) aux artefacts créés et publiés sur jFrog, et associez les pipelines de déploiement (CD) aux packages téléchargés à partir des référentiels jFrog à déployer. La liaison de ces pipelines CI/CD aux artefacts et leur association au changement crée le lien entre la validation et les artefacts créés et déployés pour la traçabilité des changements.
Fixe
- Intégration GitLab : les très grands nombres de build GitLab sont enregistrés en tant que nombres extrêmement élevés dans build_number colonne de la table d’exécution des tâches
- Bug de sécurité

Modifié
- Traçabilité des changements
  - La traçabilité des changements est un moyen non invasif d’utiliser les données DevOps pour accélérer les changements manuels. Cela permet d’accélérer le délai de rentabilisation sur le chemin de l’automatisation complète des changements. Avec cette version, vous pouvez associer des versions d’artefacts, des numéros de version ou une version de mise en production à une demande de changement créée manuellement qui extrait les données DevOps telles que les éléments de travail, les validations et les tests.
  - L’implémentation ne nécessite pas de modifications du pipeline pour inclure les tâches de changement ServiceNow DevOps. Ainsi, avec les données DevOps associées, vous avez une visibilité complète de ce qui a été déployé en production pour accélérer vos changements manuels.
- Prise en charge de l’importation et de l’interrogation pour JIRA, GitHub et Jenkins
  - L’importation via le catalogue en libre-service d’intégration d’application et l’interrogation périodique pour extraire des données pour toutes les options (Code, Plan et Orchestration) vous aidera à intégrer facilement des équipes en transférant rapidement des données DevOps dans ServiceNow sans avoir à modifier le pipeline ou à configurer des webhooks. Les données importées vous fourniront des informations sur les causes premières d’une traçabilité complète des changements. Cette version couvre l’infrastructure d’importation pour JIRA, GitHub et Jenkins et le mécanisme d’interrogation configurable.
  - Les dépendances de spoke d’application suivantes sont ajoutées pour prendre en charge la fonctionnalité
    - Spoke Jenkins V2 – 1.1.2
    - Spoke Jira – 3.1.1
    - Spoke GitHub – 2.2.2
- Tableau de bord et notifications d’intégrité du système
  - Le tableau de bord d’intégrité du système fournit un moyen de surveiller ou de résoudre les problèmes liés aux données qui entrent de vos outils DevOps connectés à ServiceNow DevOps. Il s’agit d’un moyen pour les administrateurs DevOps d’avoir une meilleure visibilité sur les événements entrants traitant les données reçues à partir de divers outils qui ont été configurés dans DevOps. Il existe également un moyen simple de vérifier le dernier état de la connectivité de l’outil.
  - Des notifications par e-mail peuvent être envoyées à un groupe qui fournira des informations hebdomadaires sur des statistiques clés telles que les exécutions de pipelines, les demandes de changement et les données d’événements entrants. Cela permet aux administrateurs DevOps d’être informés de manière proactive s’il y a des changements possibles dans l’aide globale de leur système DevOps.
Fixe
- Azure DevOps
  - Si plusieurs validations sont traitées en même milliseconde, des référentiels en double sont créés
  - Outil ADO créé Enregistre les informations d’identification en texte clair
- Les notifications GitLab sont bloquées dans l’état d’attente et d’erreur lorsque le Serveur MID est activé et arrêté par intermittence
- L’interface utilisateur du pipeline ne se charge pas pour les pipelines ayant un grand nombre d’exécutions de pipelines
- Les règles de relation DevOps sont exécutées pour les demandes de changement avec une catégorie non DevOps
- Échec de l’enregistrement de l’artefact pour la tâche de style libre après la mise à niveau vers la version 1.32
- Bug de sécurité

Nouvelle
- Prise en charge de Jenkins pour les étapes parallèles : ServiceNow DevOps assure désormais le suivi des étapes qui s’exécutent en parallèle/imbriquées dans les pipelines Jenkins. Les étapes parallèles seront restituées avec précision dans l’interface utilisateur du pipeline et les demandes de changement automatisées ne seront créées qu’une fois les étapes parallèles qui la précèdent terminées.
- Azure DevOps : fonctionnalité de traitement en bloc activée pour l’aptitude d’orchestration de l’outil ADO afin d’optimiser le traitement des événements.
- Politiques d’archivage des tables
  - Règles d’archivage ajoutées à l’archivage automatique des données de plus de 9 mois (configurable, peut être configuré pour toutes les règles d’archivage à l’aide d’une seule propriété).
  - Des règles de destruction sont ajoutées, ce qui purge les données archivées de plus de 3 ans.
  - Les règles d’archivage et de destruction ci-dessus sont appliquées aux tables composées de données : PipelineExecution, StepExecution, TaskExecution et toutes les tables connexes.
Fixe
- Agile Development 2.0 : lorsqu’un utilisateur disposant de rôles scrum_product_owner et scrum_story_creator crée une user story, l’élément de travail correspondant n’est pas créé dans DevOps.
- Jenkins : les pipelines à plusieurs branches avec configuration BitBucket ont une valeur d’exécution de tâche vide Les exécutions de pipelines sont créées même si le suivi n’est PAS activé pour le pipeline à plusieurs branches et le pipeline imbriqué Après avoir recréé l’outil Jenkins, des événements entrants sont créés même si les pipelines ne sont pas détectés ou suivis.
- Azure DevOps : pour un projet personnalisé (pas un projet Agile) : lorsque l’élément de travail ADO est supprimé, des erreurs d’événements entrants avec le code d’erreur 400 ne mettent donc pas à jour l’état de l’élément de travail DevOps correspondant sur Supprimé.
- Le marqueur Reçu de changement pour un enregistrement d’étape de pipeline n’est pas mis à jour lorsque la charge utile d’app-onboarding est publiée

Nouvelle
- Prise en charge des étapes parallèles dans Azure DevOps
  - ServiceNow DevOps suit désormais les étapes qui s’exécutent en parallèle dans les pipelines de mise en production Azure DevOps. Les étapes parallèles seront restituées avec précision dans l’interface utilisateur du pipeline et les demandes de changement automatisées ne seront créées qu’une fois les étapes parallèles qui la précèdent terminées.
  - Remarque : la prise en charge des étapes parallèles est limitée aux pipelines de mise en production Azure DevOps ; Les pipelines de version continueront d’être suivis et rendus en série dans ServiceNow DevOps.
- Renvoyer le numéro de la demande de changement dans Jenkins
  - Lorsqu’une tâche ou un pipeline Jenkins est configuré pour le contrôle des changements, cette fonctionnalité entraîne l’extraction du numéro de changement du changement nouvellement créé dans le fichier journal de version. Ces informations aident le propriétaire du pipeline à comprendre pourquoi son pipeline est en pause et lui permettent de suivre l’état du changement, s’il le souhaite. La sortie du journal est uniquement informative et la changeInfo existante est recommandée pour récupérer par programmation les détails et les informations d’état d’une demande de changement DevOps en attente.
- Prise en charge des URL héritées Azure DevOps
  - ServiceNow DevOps prend désormais en charge l’utilisation de l’URL héritée (visualstudio.com) dans les projets Azure DevOps. L’URL héritée peut désormais être utilisée de manière interchangeable avec la nouvelle URL (azure.com).

Nouvelle
- Étapes de redémarrage pour Azure DevOps : pipeline de support et redémarrages d’étapes/d’étapes qui vous permettent de tracer correctement les informations, car l’exécution du pipeline est la même
- OAuth GitLab : prend en charge OAuth car il est plus sécurisé que l’authentification de base pour empêcher les actions malveillantes et la visibilité injustifiée
Fixe
- Module d’extension Jenkins pour ServiceNow DevOps
  - Vulnérabilités de sécurité liées aux dépendances du module d’extension Jenkins. (Remarque : à partir de DevOps 1.30, la version de base minimale du serveur Jenkins doit être 2.204.6 pour corriger les vulnérabilités)
  - Notification bloquée à l’état d’attente pour les pipelines multibranches qui ont un nom de branche avec des caractères spéciaux (par exemple, scratch/dev !@@&mybranch)
- Azure DevOps
  - Pipeline de version : les versions de l’artefact ne sont pas affichées dans la liste connexe Demande de changement lorsque le package et le changement sont créés à la même étape.
  - Le champ Validé à est changé lorsque la balise est créée en une validation historique
  - Exécutions de pipelines de mise en production Créer un package avec le même nom à chaque exécution
  - Problèmes de performances sur l’exécution du pipeline DevOps, les tables de résumé des tests et de rappel.
  - Par intermittence, des éléments de travail en double sont créés dans DevOps lorsque l’élément de travail est créé à partir du module d’extension Agile 2.0 ServiceNow.
  - Résultats des tests qui ne sont pas affichés dans le pipeline de déploiement lorsqu’ils sont générés à partir de plusieurs pipelines de version.
Changé : à partir de DevOps 1.30, la version de base minimale du serveur Jenkins doit être 2.204.6 pour corriger les vulnérabilités.

Changements de fonctionnalités :
- Module d’extension Jenkins pour ServiceNow DevOps
  - Module d’extension de Jenkins Marketplace : intégration facile en installant directement à partir de Jenkins Marketplace. Principalement pour éliminer TOUTES les frictions pour que les équipes de développement puissent s’auto-intégrer et utiliser la solution
  - Amélioration des niveaux de journal : Logger est essentiel pour diagnostiquer ou déboguer un problème. Cependant, l’activation d’une journalisation excessive peut rapidement inonder votre système et mettre fin aux serveurs. Les équipes de développement auront désormais la possibilité de définir les niveaux de journal comme vous le souhaitez pour retracer la cause première exacte d’un problème
  - Réduction des appels d’informations de pipeline excessifs : pour réduire le nombre d’appels de Jenkins à ServiceNow pour savoir si un pipeline est suivi ou non à chaque déclenchement d’une version Jenkins, un nouveau marqueur « Forcer la vérification du suivi » a été introduit dans la configuration Jenkins. Lorsque cette option est désactivée, un fichier contenant les informations de suivi et de test du pipeline est créé et est utilisé pour déterminer quels pipelines sont suivis sur ServiceNow pour envoyer des notifications. Chaque fois qu’un marqueur de suivi de pipeline ou des informations de test sont mis à jour sur l’application ServiceNow par l’utilisateur, ServiceNow effectue un appel d’API REST POST à Jenkins pour mettre à jour le fichier de suivi de pipeline
- Demande de changement sur la catégorisation : lorsqu’une demande de changement est automatiquement créée, elle dispose de la catégorie = DevOps. Les valeurs de catégorie que vous avez aujourd’hui dénotent un type de changement, comme Matériel, Logiciel, Réseau, etc. Alors que la valeur « DevOps » ressemble davantage à la source du changement. Il peut y avoir des cas où un changement est sourcé par DevOps et est de type Matériel ou Logiciel. De plus, la liste des catégories pourrait déjà être utilisée à des fins différentes et utiliser des valeurs comme, par exemple, non-production, etc. L’équipe DevOps aura désormais la possibilité d’identifier de manière unique qu’un enregistrement de changement est un « enregistrement de changement DevOps ».
- Amélioration des performances du débit de traitement des événements entrants
Correctifs:
- ADO Les exécutions de pipelines et de tâches s’affichent lors du suivi d’un pipeline spécifique au niveau de l’outil, mais le suivi n’est pas activé pour le pipeline
- Les commentaires d’approbation et de rejet automatiques de la demande de changement ne sont pas définis dans l’enregistrement de la table sysapproval_approver
Module d’extension Jenkins pour ServiceNow DevOps : 1.29

Nouveau :
- Les événements entrants présentant des erreurs avec certains types d’exceptions seront automatiquement réessayés par une tâche planifiée. Les types d’exception, le nombre de nouvelles tentatives et l’âge des événements entrants erronés à traiter sont configurables dans les propriétés DevOps
- Intégration Jenkins Sécurité améliorée, vous pouvez maintenant utiliser la clé API pour créer vers l’outil Jenkins dans ServiceNow DevOps Le motif du rejet/de l’annulation de la demande de changement est renvoyé au pipeline Jenkins respectif afin que vous sachiez pourquoi le changement a été rejeté/annulé.
Fixe:
- Les événements push de code et de balise Push échouent pour une validation vide qui n’a aucune modification de fichier
- GitHub : erreur 404 : l’importation ne fonctionne pas au niveau du référentiel : lorsque l’URL de l’outil a un « / » à la fin L’artefact n’est pas lié à l’exécution de la tâche lorsque le nom du pipeline contient le nom de la branche
- GitHub Enterprise : impossible de configurer un référentiel en raison d’un webHookResourcePath incorrect La mise en page de la page d’interface utilisateur de pipeline est rompue dans IE11 Événements de pipeline multibranches Jenkins bloqués à l’état En attente lorsque le nom de branche a « / » et a des tests Junit Le pipeline à plusieurs branches avec un espace ne fonctionne pas
- Azure DevOps :
  - La demande d’importation de plan DevOps pour Azure DevOps échoue avec un gros backlog (par exemple, >2 000 éléments de travail)
  - La notification entrante échoue pour une mise en production qui inclut un artefact Azure
  - Lorsque les informations d’identification changent/expirent après la création de l’outil, l’état des demandes d’importation pour l’action de détection est réussi et non défini sur erreur Dans une exécution de pipeline unique, la validation de rétablissement est conservée avant la validation initiale, ce qui ne supprime pas la validation de rétablissement des validations d’exécution
- Module d’extension Jenkins pour ServiceNow DevOps : 1,28

Changé:
- Cadre de qualité logicielle : modèle de données mis à jour spécifiquement pour la qualité du code et les outils de sécurité. Un framework extensible qui permet à quiconque de créer des intégrations personnalisées à n’importe quel outil de qualité du code et de sécurité.
- Prise en charge de SonarQube : prise en charge prête à l’emploi pour Azure DevOps et Jenkins. Chaque fois qu’une analyse est déclenchée à partir du pipeline, les résultats de l’analyse sont capturés dans ServiceNow DevOps qui est nécessaire pour déterminer le risque de changement
- Autorisez la définition de champs de changement via l’API. Cela remplace toutes les configurations d’étape précédemment définies. La fonctionnalité actuelle reste intacte, la seule différence étant que les champs peuvent désormais être définis à partir de l’API.
- Module d’extension Jenkins pour ServiceNow DevOps : 1.27

Fixe:
- Condition de concurrence entraînant un événement entrant DevOps incorrect, un motif d’attente et des exécutions de pipeline incomplètes
- Échec de la création de changement DevOps avec le module d’extension Change Management hérité
- Lorsque l’e-mail du push GitHub est vide, le validateur et l’e-mail du validateur ne sont pas renseignés dans DevOps
- Pour BitBucket, les mises à jour des balises DevOps ne sont pas traitées

Changé:
- Créez dynamiquement des alias de connexion (sous un alias parent), ce qui évite à un administrateur système de créer des alias de connexion séparément lors de la création de l’outil DevOps. Cette fonctionnalité utilise la fonctionnalité « Alias enfants » de la plateforme et est disponible depuis Paris. L’application DevOps est fournie avec des alias parents et des modèles de configuration correspondants (auth. de base, clé API et OAuth [code d’autorisation]) qui peuvent ensuite être utilisés pour créer une connexion et des informations d’identification sous l’alias enfant créé.
Fixe:
- L’interface utilisateur du pipeline est interrompue lorsque toutes les exécutions de tâches sont ignorées
- L’intégration de l’outil de test attend que le toolID dans les paramètres de requête soit un ID d’outil d’orchestration Les mises à jour de balises DevOps ne sont pas traitées
- Il n’existe aucune gestion par défaut pour les états Azure non pris en charge tels que SucceededWithIssues Filtrer l’API de validation pour extraire uniquement les validations pour Jenkins
- Les informations de branche ne sont pas mises à jour pour les validations lors de la fusion de code
Compatibilité des modules d’extension et des extensions :
- Module d’extension Jenkins pour ServiceNow DevOps (1.24.0) https://marketplace.visualstudio.com/items?itemName=ServiceNow.vss-services-servicenow-devops version : 1.24.0

Changé:
- Azure DevOps : outil d’intégration ADO simplifié en permettant aux clients de choisir uniquement des pipelines spécifiques à suivre
- Vous pouvez maintenant définir des conditions d’archivage/de purge pour la table Événements entrants afin de gérer de gros volumes de données DevOps
Fixe:
- Azure DevOps : lorsque les noms de tâches à différentes étapes sont identiques, l’artefact/package n’est pas lié à l’exécution de la tâche
- Azure DevOps : pour une porte de mise en production avec déclenchement manuel uniquement sur une étape, le pipeline de mise en production crée deux enregistrements d’exécution de pipeline
- La génération d’artefacts inclut des validations de différentes branches pour les exécutions échouées dans le pipeline multibranche
- Les scripts DevOps Flow Designer doivent s’exécuter en tant qu'« Utilisateur qui lance la session » au lieu de « Utilisateur système »

Changé:
- Changements de l’API du pipeline de demande de changement : définissez des attributs de demande de changement supplémentaires lors de la création de la demande de changement à partir des pipelines Jenkins et Azure DevOpsDéfinissez le marqueur du pipeline afin que ServiceNow DevOps ne ferme pas la demande de changement.
- Les balises de référentiel GitLab et Azure DevOps sont désormais prises en charge dans ServiceNow DevOps
- Peut désormais traiter les validations en bloc depuis GitLab
- « Version » est maintenant un champ facultatif dans la charge utile du plan
Fixe:
- L’interface utilisateur du pipeline affiche une page blanche pour le pipeline qui crée la version de l’artefact à la même étape que le changement
- Dans une demande de changement, l’utilisateur ayant uniquement le rôle de visionneur DevOps peut voir toutes les validations dans le système au lieu des validations incluses dans l’artefact
- La demande de changement n’est pas créée lorsque le validateur des validations est vide
- La demande de changement n’est pas créée si l’étape en amont est « ignorée »
- Pour Azure DevOps et GitLab, les validations inversées dans une validation de fusion s’affichent dans la liste connexe des validations d’une demande de changement

Changements de fonctionnalités :
- L’importation et la catégorisation automatiques des tests GitLab JUnit pendant l’exécution du pipeline sont désormais prises en charge.
Correctifs:
- Les validations volumineuses sont désormais prises en charge avec Azure DevOps.
- Le changement du pipeline Jenkins sous DevOps reprend automatiquement après le redémarrage du serveur Jenkins.
- Deux enregistrements d’exécution de pipeline sont créés si le contrôle des changements est activé à la première étape d’un pipeline freestyle.
- L’événement entrant génère une erreur lors du traitement de l’élément de travail pour l’outil ADO avec un projet dont le nom contient un espace.
- Lorsque plusieurs pipelines ADO (tous avec des tests) sont exécutés en parallèle, les événements entrants restent bloqués à l’état d’attente avec des exceptions.
- La charge utile de l’application d’intégration n’est pas stockée dans le champ chiffré. Les notifications d’achèvement d’étape entrante d’Azure DevOps ne sont pas traitées correctement, ce qui entraîne un délai d’expiration.
- Les cas d’utilisation de nouvelle tentative des portes de mise en production Azure échouent avec les changements de reçu de changement.
- Le nom d’utilisateur/mot de passe de configuration globale de l’outil Jenkins est stocké sous forme de textes bruts dans config.xml.
- Le pipeline Jenkins échoue si le pipeline n’a pas été détecté.

Nouveau : plusieurs éléments de travail pour une validation sont désormais pris en charge et sont liés à la validation dans ServiceNow DevOps. De plus,:
- La syntaxe de l’élément de travail dans le message de validation peut être personnalisée pour refléter les processus de votre organisation.
- La sélection des éléments de travail via l’interface utilisateur Azure DevOps lors de la validation est désormais prise en charge.

Nouveau :
- Vous pouvez désormais supprimer de nombreux objets DevOps tels que les outils, les référentiels et les pipelines. Consultez la documentation du produit pour connaître la liste complète et les restrictions.
- Vous pouvez maintenant obtenir le numéro de changement créé dans un pipeline pour poursuivre l’interaction avec la demande de changement à partir du pipeline.
Enlevé:
- Le champ Élément de configuration d’un outil a été supprimé.
- Sous la sélection Utiliser le serveur MID, les deux champs (Application Serveur MID, Option Serveur MID) ont été supprimés.

Pour les correctifs suivants, installez le module d’extension Jenkins pour ServiceNow DevOps (1.20.2).

Fixe:
- Correctif de sécurité
- Si le pipeline n’a pas été détecté, le comportement du module d’extension Jenkins peut échouer
- Lorsque Jenkins est redémarré, les déploiements reprennent sans approbation de changement

Nouveau :
- Enregistrement des changements : les étapes du pipeline peuvent désormais être configurées pour créer des reçus de changement, qui incluent toutes les données du pipeline, mais ne nécessitent pas d’approbation pour poursuivre dans le pipeline.
- Améliorations des outils de test : les tests JUnit et Selenium peuvent désormais être catégorisés automatiquement et des types de tests supplémentaires peuvent être configurés pour la catégorisation automatique.
- Étapes Jenkins ignorées : lorsque des étapes sont ignorées, en raison de conditions de branche, l’interface utilisateur du pipeline ne les affiche pas.

Nouveau :
- Les étapes de pipeline DevOps sont désormais créées automatiquement lorsque le pipeline Jenkins s’exécute. Vous n’avez plus besoin de créer manuellement les étapes du pipeline dans ServiceNow ou de configurer les notifications dans Jenkins. Le changement est toujours configuré manuellement sur les étapes souhaitées dans Jenkins et dans ServiceNow DevOps.
- DevOps a augmenté la résilience des données en ajoutant de nouvelles tentatives à la plupart des communications d’outils à partir des flux ServiceNow. Vous pouvez modifier la configuration des nouvelles tentatives pour qu’elle corresponde à vos besoins.

Corrigé : Cette version est une version de correction. Il corrige un problème de compatibilité avec la fonction de changement.

Nouveau :
- Prise en charge du pipeline de mise en production Azure DevOps
  - Inclut la prise en charge de l’extension ServiceNow DevOps Release Gate ou de l’utilisation de l’appel d’API Invoke Rest comme porte de pré-déploiement.
Impacts de la mise à niveau et dépannage :
- Si vous disposez déjà d’une connexion à l’outil ADO, vous devrez mettre à jour l’URL de la version ADO dans l’alias de connexion et d’informations d’identification.

Nouveau : nouvelle intégration plus légère d’Azure DevOps élimine la nécessité d’ajouter des notifications de tâche de début et de fin aux pipelines ADO. Les modifications de pipeline ne sont désormais nécessaires que pour les artefacts et les changements de pipeline.
Fixe:
- Ajout de la prise en charge des validations par lots dans les notifications GitLab.
- Correction de la gestion des tentatives de connexion Azure DevOps effectuées avec une URL ou des informations d’identification non valides.
- Correction du problème d’heure de début/fin d’exécution du pipeline dans Azure DevOps.

Nouveau :
- Intégration de l’outil de codage GitLab
  - Découvrir les référentiels qui vous appartiennent, dont vous êtes membre ou qui effectuent une recherche par mot clé
  - Configuration manuelle des webhooks
- Intégration de l’outil d’orchestration GitLab
  - Prise en charge des types de pipeline de base
  - Configuration manuelle des webhooks

Nouveau : prise en charge de l’importation historique des éléments de travail ADO.
Correction : Correction d’un problème pour les tâches freestyle sous les dossiers dans Jenkins où l’exécution en amont n’est pas définie pour les tâches enfants.

Remarque :

Cette version de l’application ne peut être installée que sur les instances exécutant New York ou une version ultérieure.

DevOps Notes de version des intégrations

Stocker les notes de version

DevOps Notes de version des intégrations

Historique de version