DevOps Notes de version de Data Model

Nouveau :
- Prise en charge d’analyses d’intégrité proactives
  - Détectez les anomalies et les problèmes dans votre instance de vélocité de changement DevOps à l’aide d’une série de vérifications proactives. Ces vérifications peuvent vous aider à identifier des problèmes qui ne sont pas évidents dans l’interface utilisateur du produit, mais qui peuvent facilement être détectés par des analyses de table. Elles sont de nature planifiée ou à la demande, en fonction du type de vérification.
- 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.

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.

Amélioration du modèle de données DevOps 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.

Changé:
- Amélioration du modèle de données DevOps pour prendre en charge les fonctionnalités de vélocité de changement DevOps suivantes :
  - Prise en charge de l’intégration d’outils d’orchestration personnalisés
  - Amélioration de la gestion des erreurs d’intégration et des garde-fous
  - Autoriser la création de demandes de changement même avec des erreurs dans la récupération de données DevOps
  - Prise en charge des demandes de fusion / extraction GitLab
  - Prise en charge de JFrog Artifactory pour GitHub Actions, Azure DevOps et GitLab
  - Prise en charge de Jira Cloud
  - Prendre en charge plusieurs configurations DevOps ServiceNow dans la même instance Jenkins
  - Améliorations des conteneurs Docker GitLab

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.

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éelles 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.
- 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.
- Changements de prise en charge multimodèle
  - 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.
Fixe:
- L’interface utilisateur du pipeline est restée à l’état de chargement permanent lorsqu’il y avait plus de 20 pipelines.
- Serveur Windows a rencontré un problème de compatibilité avec Jenkins.
- Les événements entrants sont restés à l’état En attente lorsque l’URL d’exécution de la tâche contenait une virgule (,) pour les pipelines multibranches Jenkins.
- Les outils étaient déconnectés même pour les outils avec des informations d’identification valides en raison de la limite de débit dans le système.
- La requête codée pour renvoyer l’URL d’exécution de tâche pour les pipelines Jenkins multibranches ne fonctionnait pas.
- La tâche d’orchestration associée à un pipeline n’était pas renommée lorsqu’un pipeline a été renommé dans ADO et redécouvert dans ServiceNow.
- Le groupe d’affectation n’était pas défini dans une demande de changement lorsqu’un modèle a été ajouté à une étape de changement et que le pipeline correspondant a été exécuté.
- Les événements entrants échouaient lors de la connexion à un référentiel privé GitHub à l’aide de GitHub Apps OAuth.
- Des noms d’étape incorrects étaient générés lors de l’utilisation de la stratégie Matrix pour créer des noms d’étapes dans le workflow GitHub.
- L’étape Sonar dans les pipelines de mise en production ADO ne fonctionnait pas pour les pipelines de demande d’extraction.
- La demande de rappel échouait pour les changements personnalisés dans Actions GitHub.
- Correctif de sécurité pour les webhooks ADO.
- La prise en charge de la grappe de Serveur MID pour l’alias de connexion de l’outil DevOps ne fonctionnait pas.

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.

Changé:
- 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 de 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.

Changé:

Messages d’erreur mis à jour
- Amélioration des messages d’erreur pour 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. Lors de la connexion d’un outil, une nouvelle vérification des autorisations permet d’afficher les autorisations disponibles à partir des informations d’identification au lieu des autorisations requises.
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
Prise en charge des exécutions de pipelines de demandes d’extraction (PR) GitHub/Jenkins
- Suivez et soutenez les exécutions de pipelines de demandes d’extraction pour l’outil d’orchestration Jenkins et les PR créées dans l’outil de codage GitHub. Intégrez les données de PR telles que l’ID de demande d’extraction, les validations, la branche d’origine, la branche de destination, l’auteur de la soumission, l’approbateur, les commentaires, l’heure de levée de la PR, l’heure d’approbation de la PR et l’heure de fusion/clôture de la PR de l’outil de codage GitHub au CHG DevOps créé pour l’exécution du pipeline correspondante dans l’outil d’orchestration Jenkins. En outre, joignez les données liées à la PR au CHG DevOps pour examiner qui a autorisé, validé, vérifié et approuvé le processus de fusion des PR.
Importer des données historiques pour les outils DevOps et la traçabilité des CHG - Gitlab
- Importez des données historiques pour les options Code et Orchestration en extrayant les données via le catalogue en libre-service d’intégration de l’application et une interrogation périodique.
- L’infrastructure d’importation permet d’intégrer des équipes en important des 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 des validations, des branches, des balises et des pipelines (CI/CD) à partir de GitLab.
SonarQube : prise en charge des nouvelles mesures de code
- Intégrer les mesures du nouveau code fournies par SonarQube en dehors des résultats globaux de l’analyse du code, en fonction de la configuration du nouveau code dans SonarQube. Les nouvelles mesures de code suivantes sont intégrées dans cette version : nouvelles vulnérabilités, nouvelle cote de maintenabilité, nouvelle cote de fiabilité, nouvelle cote de sécurité, nouveaux bogues, nouvelles odeurs de code, nouvelle dette technique et nouvelles lignes de code. Ceci est pris en charge pour les outils d’orchestration Jenkins, Azure DevOps et GitHub Actions.
Split.io Intégration de l’outil Feature Flag dans ServiceNow
- Cette intégration étend ServiceNow pour gérer le processus d’approbation des changements pour les marqueurs de fonctionnalités et les segments de Split.io. ServiceNow DevOps peut désormais gérer les mises à jour des marqueurs de fonctionnalités.
- Split.io prise en charge de l’intégration de l’outil de marqueur de fonctionnalité permet de détecter des espaces de travail, des environnements, des segments et des marqueurs de fonctionnalités. Vous pouvez définir les champs de demande CHG pour activer Split.io pour le contrôle CHG. Lors de l’approbation/du rejet d’une demande CHG, l’URL de rappel dans split.io pour la division ou le segment est appelée pour reprendre l’implémentation de la mise à jour de la division et du segment
Fixe:
- Le tableau de bord des analyses DevOps peut désormais être filtré par application d’entreprise.
  - Les artefacts portant le même nom mais avec des versions différentes sont considérés comme des doublons (même s’ils appartiennent à des référentiels différents).
  - Deux exécutions de pipeline ont été créées pour un pipeline de mise en production ADO lorsque le nom du projet ADO comporte des espaces et des caractères spéciaux.
  - DevOps : les tickets de changement ont des liens vers l’accueil du pipeline au lieu d’une exécution spécifique.
  - Azure DevOps
    - Les validations et les éléments de travail ne sont pas liés aux artefacts pour les pipelines qui ont des artefacts de publication dans la première étape ou la première tâche.
    - Azure DevOps : les détails de la validation importée affichent le nombre incorrect de fichiers modifiés
    - Les éléments de travail, les résumés de tests et les validations ne sont pas joints au changement dans ServiceNow lorsque le pipeline de mise en production s’enregistre avant le pipeline de version.
    - Message incorrect dans les détails du traitement des événements entrants lorsque le mappage de type de test est manquant.
  - Après l’importation historique des exécutions de pipeline qui sont annulées, l’état du pipeline s’affiche comme En cours dans l’interface utilisateur du pipeline
  - Les événements Jenkins Orchestration passent aléatoirement à l’état d’erreur.

Nouveau :
- 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.

Nouvelle fonctionnalité :

Ajout de la prise en charge du pipeline multibranche lors de l’enregistrement d’un ensemble de changements ou d’un instantané dans l’exécution du pipeline (nécessite Configuration DevOps)
- Nécessite un module d’extension Jenkins pour ServiceNow DevOps v1.35.2

Corrigé : Serveur MID affecté à l’alias de connexion non sélectionné lors de la création du changement.

Nouvelle
- 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 du système de base 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 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 : ajout de règles d’archivage aux données d’archivage automatique de plus de 9 mois (configurable, peut être configuré pour toutes les règles d’archivage à l’aide d’une seule propriété) Ajout de règles de destruction qui éliminent 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.
- Intégration en libre-service
  - Cette version inclut deux nouveaux éléments de catalogue de services pour activer un modèle en libre-service pour les équipes d’intégration à ServiceNow DevOps :
    - Intégration d’outils : permet aux équipes de créer une nouvelle instance d’outil ServiceNow DevOps, y compris la création, la connexion, la détection et la configuration d’outils. Une fois terminé, l’outil est prêt pour l’intégration de l’application.
    - Intégration de l’application : permet aux équipes de créer une nouvelle application ServiceNow DevOps (ou de configurer une application existante), y compris la découverte de l’étape du pipeline, le contrôle du suivi et (éventuellement) l’activation du contrôle des changements pour une étape.
- Avec ces deux éléments de catalogue, les équipes de développement peuvent configurer leurs projets à utiliser avec ServiceNow DevOps du début à la fin en quelques minutes, de manière totalement autonome et selon leur propre calendrier.
- Nouvelle application de vélocité de changement DevOps
  - Une nouvelle application « Vélocité de changement DevOps » a été introduite pour héberger la fonctionnalité d’accélération de changement DevOps existante. L’installation de la vélocité de changement DevOps installe ou met à niveau automatiquement toutes les dépendances de l’application ServiceNow DevOps, il n’est donc plus nécessaire de les installer individuellement. Parallèlement, l’application « DevOps » existante a été renommée « DevOps Data Model ». Il s’agit d’une mesure organisationnelle conçue pour améliorer l’expérience d’installation de l’application ; elle ne modifie en rien les fonctionnalités ServiceNow DevOps existantes.
- Activation du contrôle de changement automatique pour ADO et Jenkins
  - Lorsque le contrôle des changements DevOps a été activé dans un pipeline Azure DevOps ou Jenkins, le contrôle des changements est automatiquement activé pour l’étape correspondante dans ServiceNow. Cette amélioration fonctionne avec la fonctionnalité d’intégration en libre-service pour simplifier et rationaliser le processus d’intégration.

Nouvelle
- Étapes de redémarrage pour Azure DevOps : prenez en charge le pipeline et les redémarrages d’étapes/é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 à plusieurs branches 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.
  - Les exécutions de pipeline de mise en production créent 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 cassée dans IE11 Événements de pipeline multibranches Jenkins bloqués à l’état d’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 causant des erreurs incorrectes
- Événement entrant DevOps Motif d’attente et exécutions de pipeline incomplètes La création de changement DevOps échoue 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 des 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 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 : les étapes de pipeline DevOps sont désormais créées automatiquement lorsque le pipeline de l’outil d’orchestration s’exécute. Vous n’avez plus besoin de créer manuellement les étapes du pipeline et de les mapper à l’outil d’orchestration. Le changement doit toujours être configuré manuellement aux étapes souhaitées.

Nouveauté : les applications OAuth et GitHub sont désormais prises en charge avec l’intégration GitHub
Fixe:
- Correction du problème où le nom de l’étape sur l’exécution de l’étape est vide jusqu’à ce que toute l’exécution soit terminée.
- Amélioration des performances pour le traitement des validations Git
- Correction du problème où les enregistrements de validation Azure DevOps ne sont pas créés lorsque l’élément de travail associé n’est pas trouvé
- Correction de la gestion des exécutions de pipeline Azure DevOps avec des tests JUnit vides

Nouveau :
- Mises à jour de l’interface utilisateur du pipeline DevOps pour inclure des artefacts
  - Possibilité d’afficher les versions d’artefacts créées ou mises en production sur l’interface utilisateur du pipeline
  - Améliorations de l’accessibilité
- Amélioration des données de démonstration pour contenir des exemples d’interface utilisateur, d’outil et d’aperçu de pipeline
- Capacité à créer des outils d’orchestration qui utilisent la découverte basée sur les événements et les rappels génériques d’accélération des changements
- Intégrations d’outils de codage et d’orchestration GitLab via l’application d’intégration DevOps

Nouveau :
- Changement géré par le client : DevOps offre désormais une plus grande flexibilité dans la configuration des flux de demandes de changement, par exemple, la prise en charge de nouveaux types de changements.
- Amélioration de la gestion des notifications de pipeline Azure DevOps hors séquence.
- L’importation historique des éléments de travail Azure DevOps est désormais prise en charge.
Fixe:
- Les événements d’éléments de travail supprimés sont désormais gérés correctement pour Azure DevOps.
- La gestion des notifications de validation a été corrigée.
- L’interface utilisateur du pipeline a été mise à jour pour inclure de nouveaux états (annulés par l’utilisateur) dans les exécutions d’étapes.
- Correction d’un problème où seulement 200 enregistrements sont importés en raison de la propriété limite maximale.
- La note de création d’outil « La création d’outils peut prendre jusqu’à une minute » est maintenant traduisible.
- Ajout de la prise en charge des composants/contrôles fournis sans états et/ou propriétés (contenu extensible/réductible).
- Résolution d’un problème selon lequel la mise en page ne s’adapte pas aux changements de paramètres de taille du texte jusqu’à 200%.

Remarque :

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

Nouveau : améliorations apportées à l’interface utilisateur du pipeline

Nouveau : le cadre de travail d’intégration créé par l’utilisateur prend désormais en charge les actions de connexion et de détection.

Amélioration de la création d’outils

Il y a un nouveau bouton « Créer » qui va :
- Créer un outil DevOps, créer une connexion, un alias et des informations d’identification, puis se connecter automatiquement à l’outil
UI du pipeline d’application
- À partir des demandes de changement créées par DevOps, il existe un lien connexe permettant d’afficher l’interface utilisateur du pipeline pour cette exécution.
- À partir de l’exécution de l’application ou de l’étape, vous pouvez suivre le lien connexe jusqu’à la dernière exécution sur l’interface utilisateur du pipeline.

Nouveau :
- Une API REST qui permet à quiconque d’intégrer du code, des outils de planification et d’orchestration
- Les tâches Jenkins dans les dossiers peuvent maintenant être découvertes
- L’accélération du changement fonctionne sur Serveur MID

Le nom est passé de « Enterprise DevOps » à « DevOps ».

Améliorations de la convivialité et de la stabilité

Modélisation de pipeline configurable

Les pipelines de haut niveau permettent à plusieurs applications de faire partie d’un pipeline.
Modélisez les tâches Jenkins en étapes de pipeline au niveau de l’application (étape de l’application).
Suivez les relations de tâches en amont et en aval.

Accélération du changement

Créez des demandes de changement pour les exécutions de tâches qui sont sous contrôle des changements. Utilise les éléments de configuration définis à l’étape de l’application.
Le module d’extension Jenkins attendra que la demande de changement passe à l’état « Implémentation » avant d’exécuter l’exécution de la tâche Jenkins. Une fois la tâche exécutée, la demande de changement est mise à jour avec les détails de l’implémentation et fermée.

Aperçus

Les aperçus d’accélération du changement offrent une visibilité sur le processus de Gestion des changements et son efficacité.
Les aperçus de l’intégrité du système permettent aux administrateurs de maintenir le bon fonctionnement du pipeline.

Intégration ITBM Agile 2.0

Synchronisez automatiquement les produits, les épopées, les stories, les correctifs et les versions ITBM dans ServiceNow® DevOps.
Importation de données historiques.

Intégration Jira

Synchronisez automatiquement les projets, les épopées, les stories, les bugs, les tâches et les versions Jira dans ServiceNow® DevOps.
Importation de données historiques.

Intégration GitHub

Prise en charge de GitHub.com et sur site Enterprise GitHub.
Traitez les validations et les branches à l’aide de webhooks sur les référentiels sélectionnés.
Pousser automatiquement le webhook lors de la configuration du référentiel.
Vous pouvez également suivre les changements de fichiers.
Suivez les mesures de qualité du validateur et du référentiel.
Importation de données historiques.

Intégration Jenkins

Utilisez le module d’extension de notification Jenkins pour envoyer des mises à jour vers ServiceNow® DevOps.
Téléchargez et installez le ServiceNow® DevOps plugin pour Jenkins. Vous trouverez des instructions dans l’article de la base de connaissances.
Importez des tâches de pipeline Jenkins Freestyle et mappez-les aux ServiceNow® DevOps pipelines.
Stockez les résultats des tests Jenkins, y compris les tests JUnit et Selenium.
Module d’extension Jenkins fourni pour activer l’accélération du changement.

DevOps Notes de version de Data Model

Stocker les notes de version

DevOps Notes de version de Data Model

Historique de version