Utiliser un pipeline déclaratif ou scripté dans DevOps

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 4 minutes de lecture
  • Lorsque vous utilisez un fichier Jenkins, les étapes sont créées, mappées et associées aux tâches d’orchestration automatiquement et non manuellement.

    Jenkinsfile est un fichier texte qui contient la définition d’un Jenkins pipeline et qui est archivé dans le contrôle de source.

    Chaque étape de niveau racine configurée dans le fichier Jenkins est détectée en tant que tâche d’orchestration distincte dans DevOps laquelle elle est mappée à une étape individuelle.

    Remarque :
    Le champ Suivre du pipeline doit être défini sur Vrai dans DevOps pour recevoir des notifications de tâches de Jenkins. Toutes les configurations Jenkins actives reçoivent des notifications de tâche lorsque ce champ est défini sur Vrai.

    DevOps Commandes Jenkinsfile

    • snDevOpsChange(ignoreErrors :{true/false},changeRequestDetails :{setCloseCode :{true/false},attributes :})

      Where ignoreErrors spécifie le paramètre permettant d’empêcher l’échec de la tâche en cas d’erreur (vrai/faux)

      changeRequestDetails spécifie le code de fermeture et les champs de demande de changement à partir du pipeline

      Active le contrôle des changements pour chaque étape de niveau racine mappée à une DevOps étape.

    • artefact snDevOpsArtifact

      Enregistre les artefacts lors de la configuration Artefacts et packagesd'.

    • snDevOpsPackage

      Crée un package pour les artefacts lors de la configuration Artefacts et packagesde .

    • snDevOpsGetChangeNumber

      Récupère le numéro de demande de changement dans un pipeline Jenkins en fonction des détails d’un changement spécifique.

    • snDevOpsUpdateChangeInfo (en anglais seulement)

      Met à jour les détails de la demande de changement associée à un pipeline Jenkins.

    • snDevOpsSecurityResult

      Configure les analyses de sécurité à n’importe quelle étape du pipeline et les détails de l’analyse sont récupérés à partir de l’étape correspondante vers la vélocité de changement DevOps.

    Vous pouvez spécifier la Jenkins configuration du serveur au cours de l’une de ces étapes en transmettant l’attribut configurationName dans votre pipeline. Si le nom de la configuration n’est spécifié dans aucune étape, la configuration par défaut sera utilisée dans cette étape. Le passage d’un nom de configuration incorrect entraînera l’échec de l’étape, sauf si l’option Ignorer les erreurs DevOps ServiceNow est sélectionnée lors de la configuration du module d’extension Jenkins .

    Remarque :
    Le mappage d’étapes n’est pris en charge que pour les étapes au niveau racine, et non pour les étapes imbriquées ou parallèles.

    Jenkins Générateur d’extraits pour DevOps

    Vous pouvez utiliser l’utilitaire Générateur d’extraits Jenkins pour générer un code de modèle pour les tâches d’orchestration des pipelines scriptés. Vous pouvez utiliser l’utilitaire de génération d’extraits pour créer un modèle pour les tâches d’orchestration suivantes.
    • SnDevOpsArtifact
    • Changement snDevOpsChange
    • Package SnDevOpsPackage
    • snDevOpsGetChangeNumber
    • snDevOpsUpdateChangeInfo (en anglais seulement)
    • snDevOpsSecurityResult
    Pour générer un extrait d’étape, accédez à la syntaxe du pipeline à partir d’un pipeline configuré, sélectionnez l’étape dans la liste Exemple d’étape , puis mettez à jour les valeurs des différentes variables de l’étape. Sélectionnez l’option Ignorer l’erreur pour empêcher l’échec de la tâche en cas d’erreur. Sélectionnez Générer un script de pipeline pour créer un extrait. Vous pouvez copier et coller l’extrait dans un pipeline.
    Exemple de script de pipeline pour la tâche SnDevOpsChange :
    snDevOpsChange changeCreationTimeOut: 3600, changeRequestDetails: '{ "attributes": { "short_description": "Test description", "priority": "1", "start_date": "2021-02-05 08:00:00", "end_date": "2022-04-05 08:00:00", "justification": "test justification", "description": "test description", "cab_required": true, "comments": "This update for work notes is from jenkins file", "work_notes": "test work notes", "assignment_group": "a715cd759f2002002920bde8132e7018" }, "setCloseCode": false, "autoCloseChange": true }', changeStepTimeOut: 18000, configurationName: 'Jenkins1', pollingInterval: 60

    Prise en charge en parallèle et en sous-étape

    Lorsqu’une étape (ou un ensemble d’étapes parallèles) est imbriquée dans une étape de pipeline, les règles suivantes s’appliquent :

    • Toute action de l’étape imbriquée est traitée dans le cadre de l’étape de niveau racine parent
    • Une seule demande de changement est créée (au niveau racine parent), même si plusieurs étapes imbriquées sous l’étape racine parent déclenchent un changement
    • Les tâches d’orchestration créées sont toujours associées à l’étape de niveau racine parent (et non à l’étape imbriquée)

    Sous-étape

    Dans cet exemple de sous-étape, si une demande de changement est créée à partir de la sous-étape (déployer PROD), les détails de l’étape de niveau racine parente (déployer) sont utilisés dans la demande de changement, et les tâches d’orchestration sont également associées à l’étape de niveau racine parente (déployer).

    
    stage("deploy") {
             stages{
                 stage('deploy UAT') {
                    when{
                       branch 'dev'
                    }
                stage('deploy PROD') {
                   when {
                      branch 'master'
                   }
                    steps{
                      
                      snDevOpsChange()              
                    }
                }
            }

    Étape parallèle

    Dans cet exemple d’étape parallèle, si une demande de changement est créée à partir d’une sous-étape (test UAT 1 et/ou test de code statique UAT), seule la première demande de changement est créée (à l’aide des détails de l’étape de niveau racine parent, test UAT), que les deux sous-étapes (test UAT 1 et test de code statique UAT) soient déclenchées ou non.

    Il n’y a aucune indication de quelle étape parallèle a généré le changement, et les tâches d’orchestration sont associées à l’étape de niveau racine parent (test UAT).

    
    stage('UAT test') {
          parallel {
              stage('UAT test-1') {
                  steps {
                      snDevOpsChange()
                      // 'UAT test-1' tasks
                  }
                    post {
                      success {
                        // post success tasks. E.g.: junit '**/target/surefire-reports/*.xml'
                      }
                  }
              }
              stage('UAT static code test') {
                  steps {
                      snDevOpsChange()
                      // 'UAT static code test' tasks
                  }
              }
          }
     }