DevOps Notes de version de Change Velocity

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.
- 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.
- Amélioration des conseils intégrés au produit pour une adoption efficace du libre-service
  - Amélioration de l’expérience utilisateur en ajoutant de la documentation ou de la navigation à la documentation externe à divers endroits de l’espace de travail.

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.

Nouveau :
- Amélioration du parcours vers l’automatisation complète du changement à l’aide de modèles
  - Conseils intégrés au produit pour exploiter les modèles de changement DevOps et créer facilement des changements DevOps sans interruption de votre processus de changement dans l’espace de travail de changement DevOps.
  - Accélérez votre processus de changement à l’aide d’un nouveau modèle de changement simplifié DevOps, qui ne contient pas l’état Évaluer. L’approbation de changement pour ce modèle est basée sur la politique de changement de modèle simplifié DevOps.
  - La politique d’approbation est manuelle par défaut pour les modèles de changement DevOps et DevOps simplifiés correspondants.
  - Le nouveau flux d’état d’exécution de mise à jour de DevOps de changement dans le modèle DevOps est maintenant utilisé pour envoyer un rappel à l’outil d’orchestration tiers.
- Données DevOps pour la traçabilité des changements dans l’Espace de travail pour l’exploitation des services (SOW)
  - Ajoutez et modifiez des données DevOps dans une demande de changement créée manuellement dans Espace de travail pour l’exploitation des services pour une expérience de demande de changement unifiée à la fois dans l’Espace de travail de changement DevOps et dans l’Espace de travail pour l’exploitation des services.
  - Affichez la carte de résumé DevOps dans l’onglet Vue d’ensemble de l’espace de travail SOW pour tous les états de changement (Nouveau, Évaluer, Autoriser, Planifier, Implémenter, Examiner et Fermer). Vous pouvez ajouter ou modifier des données sur la carte de résumé DevOps pour les demandes de changement DevOps créées manuellement.
- Remarque : cette fonctionnalité n’est disponible que pour la version Xanadu.
Sensibilisation au changement DevOps vers les gestionnaires des changements dans SOW Centre d’administration pour la configuration
- Les administrateurs ServiceNow peuvent désormais voir un lien de navigation vers l’espace de travail de changement DevOps s’il est installé, et le lien Obtenir une application qui leur permet d’installer DevOps Change Velocity (DCV) s’il n’est pas déjà installé (applicable uniquement pour ITSM Pro ou si DCV est disponible pour l’installation).
- Remarque : cette fonctionnalité n’est disponible que pour la version Xanadu.
- Sensibilisation au changement DevOps dans Adoption Blueprints
  - Un nouveau plan d’adoption, « Modernisez votre processus de gestion des changements », est désormais disponible dans Admin Center Adoption Blueprints et explique aux administrateurs ServiceNow comment ils peuvent adopter les options requises pour permettre à leur processus de changement d’évoluer de manière dynamique sans compromettre la stabilité et la gouvernance.
- Remarque : cette fonctionnalité n’est disponible que pour la version Xanadu.
Sensibilisation des administrateurs ServiceNow au changement DevOps dans la configuration de Gestion des changements
- La nouvelle configuration de Gestion des changements dans SOW Admin Center met en évidence les fonctionnalités qui peuvent être utilisées par les administrateurs et les gestionnaires de changements pour moderniser leur parcours de gestion des changements, telles que les modèles de changement, les scores de risque et de réussite, les politiques d’approbation et DevOps, qui sert ainsi de guichet unique pour les clients à la recherche de conseils sur la façon de moderniser le changement.
- Remarque : cette fonctionnalité n’est disponible que pour la version Xanadu.
Changé:
- Demande de changement DevOps : flux d’approbation manuelle Déclencher le changement
  - Le flux d’approbation manuelle de demande de changement DevOps ne se déclenche 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.
- Prendre en charge les réexécutions avec GitHub Actions
  - La réexécution des tâches ayant échoué dans les workflows GitHub Actions est désormais prise en charge avec la création de demandes de changement.
  - Les réexécutions de toute étape ayant échoué avant, après ou au moment de la création du changement sont prises en charge.
- API_KEY de support pour Jira Server : la méthode d’authentification API_KEY est désormais disponible pour Jira Server, ce qui l’aligne sur la prise en charge existante déjà disponible pour Jira Cloud.
- Conservez les détails des branches dans l’exécution du pipeline pour déterminer les validations à partir des artefacts et des packages.
  - Une nouvelle colonne est maintenant ajoutée à la table d’exécution du pipeline pour référencer la table de branches et activer le filtrage par branche afin de s’assurer que les validations correctes sont associées à un changement lorsque les utilisateurs travaillent simultanément sur plusieurs versions d’un artefact.
  - Amélioration de la logique de calcul de validation pour la version de l’artefact afin de filtrer par branche.
  - La logique d’association de validation pour les packages a été modifiée pour afficher toutes les validations déployées dans le cadre d’un package, y compris les validations des versions précédentes de l’artefact qui n’ont pas été déployées, mais uniquement sur la même branche
- 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.

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.
- Améliorations de l’espace de travail DevOps
  - Le module Outils comporte désormais trois groupes de listes : Tous, État et Aptitude.
  - Les fonctionnalités de résultats des tests et de qualité logicielle sont désormais disponibles dans le module Liste pour faciliter la navigation.
  - Vous pouvez créer vos propres listes dans la section « Mes listes ».
  - L’intégrité du système, les intégrations et les éléments avancés (anciennement appelés dépannage) sont désormais disponibles dans le module Administration.
- Améliorations de DevOps Insights
  - Utilisez le tableau de bord Aperçus dans l’espace de travail DevOps dans le cadre de Next Experience, avec des indicateurs/widgets plus récents et pertinents tels que le taux de réussite du déploiement et les déploiements échoués, ainsi que des garanties et un meilleur filtrage.
  - Les aperçus standard DevOps sur la plateforme ont été déconseillés pour tous les nouveaux utilisateurs DevOps.
  - Les utilisateurs de la plateforme (créateur d’enregistrement) sont maintenant redirigés vers l’espace de travail pour créer des outils ou des applications. Les utilisateurs de la version/héritée peuvent toujours accéder directement à l’URL de la plateforme pour créer des outils ou des applications dans la plateforme via les options « Créer une nouvelle (héritée) » et « Créer une application (héritée) ».

Nouveau :
- Intégration de GitLab avec le conteneur Docker
  - L’intégration de GitLab à ServiceNow DevOps a été simplifiée à l’aide du conteneur Docker qui est publié sur DockerHub. Cela prend en charge la création de CHG ServiceNow DevOps, l’intégration de SonarQube avec les pipelines GitLab et l’enregistrement des artefacts et la création de packages avec ServiceNow DevOps.
- 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.
- Amélioration de la journalisation et de la gestion des erreurs avec les extensions ServiceNow DevOps
  - Les extensions ServiceNow DevOps publiées pour GitHub Custom Actions, les plugins Jenkins et les extensions ADO ont désormais amélioré la journalisation et la gestion des erreurs pour faciliter le dépannage.
- 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 des erreurs modifiées pour les flux de demande de changement DevOps
  - Vous pouvez afficher les erreurs correspondant à une demande de changement dans les notes de travail de la demande de changement et dans les journaux de console de l’outil de pipeline lorsqu’une règle métier ou une politique de données entraîne un problème lors de la mise à jour d’un changement dans les flux d’approbation manuelle de demande de changement DevOps, d’approbation d’automatisation minimale de demande de changement DevOps ou d’approbation d’automatisation avancée de demande de changement DevOps.
- 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.
- Améliorations du traitement des notifications GitLab
  - L’évolutivité a été améliorée grâce à une gestion transparente des événements GitLab.
- 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 :
- Approbation de changement DevOps automatisée minimale.
- Prise en charge de Studio pour la vélocité de changement DevOps.
Changé:
- Renommez les flux de changement DevOps existants de manière appropriée.

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 changés
  - 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.

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. Modification de l’administration des outils, qui inclut la possibilité de mettre facilement à jour 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.

Changements:

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 et 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
Le tableau de bord des analyses DevOps peut désormais être filtré par application d’entreprise
Pour l’intégration Jenkins, la version Jenkins minimum prise en charge est 2.289.1

Fixe:

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 de manière aléatoire dans un état d’erreur.

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 actions de workflow exécutées sont mises 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 les artefacts ADO :

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.

Intégration DevOps de l’espace de travail :

L’intégration (connexion) d’un outil est difficile car elle implique plusieurs étapes déconnectées et peut impliquer plusieurs personas. Workspace vous guide tout au long du processus d’intégration pour activer les résultats de l’automatisation des changements. L’espace de travail dirige le libre-service. Avec cette version, vous pouvez facilement intégrer les outils Azure DevOps, Jira, GitHub et Jenkins.

Module Analyses DevOps dans l’espace de travail :

Mesures de flux qui montrent la valeur du travail fourni.

Temps de cycle, Distribution du débit, Temps de flux planifié à déployer et Montants des travaux en cours.

Nouvelles mesures d’accélération des changements axées sur le chemin vers l’automatisation.

Changements automatisés par rapport aux changements manuels, décisions de politique de changement appliquées, retour sur investissement.

Les fonctionnalités de filtrage mises à jour incluent le service, l’élément de configuration, les produits et la date.

Explorez les données collectées avec une nouvelle conception d’onglets pour rester dans l’espace de travail.

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

DevOps Notes de version de Change Velocity

Stocker les notes de version

DevOps Notes de version de Change Velocity

Historique de version