Mithilfe einer deklarativen oder geskripteten Pipeline in DevOps

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 3 Minuten Lesedauer
  • Wenn Sie eine Jenkins-Datei verwenden, werden Schritte automatisch und nicht manuell erstellt, zugeordnet und Orchestration-Aufgaben zugeordnet.

    Jenkinsfile ist eine Textdatei, die die Definition einer Jenkins -Pipeline enthält und in die Quellcodeverwaltung eingecheckt ist.

    Jede im Jenkinsfile konfigurierte Phase auf Stammebene wird als separate Orchestration-Aufgabe in DevOps erkannt, die einem einzelnen Schritt zugeordnet ist.

    Hinweis:
    Das Feld „Nachverfolgung“ für die Pipeline muss in DevOps auf „Wahr“ festgelegt werden, um Auftragsbenachrichtigungen von Jenkinszu erhalten. Alle aktiven Jenkins-Konfigurationen erhalten Auftragsbenachrichtigungen, wenn dieses Feld auf „Wahr“festgelegt ist.

    DevOps Jenkinsfile-Befehle

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

      wobei „ignoreErrors“ die Einstellung angibt, um den Fehlschlag der Aufgabe zu verhindern, wenn ein Fehler auftritt (wahr/falsch)

      Wobei changeRequestDetailsAbschlusscode- und Change-Anforderungsfelder aus der Pipeline angibt

      Aktiviert die Change-Steuerung für jede Phase auf Stammebene, die einem DevOps -Schritt zugeordnet ist.

    • snDevOpsArtifact

      Registriert Artefakte beim Konfigurieren von Artefakte und Pakete.

    • snDevOpsPackage

      Erstellt ein Paket für Artefakte, wenn Artefakte und Paketekonfiguriert wird.

    • snDevOpsGetChangeNumber

      Ruft die Nummer der Change-Anforderung in einer Jenkins-Pipeline basierend auf bestimmten Change-Details ab.

    • snDevOpsUpdateChangeInfo

      Aktualisiert die Details der Change-Anforderung, die einer Jenkins-Pipeline zugeordnet ist.

    • snDevOpsSecurityResult

      Konfiguriert Sicherheitsscans in jeder Phase der Pipeline, und die Scan-Details werden aus der entsprechenden Phase für DevOps Change-Geschwindigkeit abgerufen.

    Sie können die -Serverkonfiguration Jenkins in jedem dieser Schritte angeben, indem Sie das Attribut ConfigurationName in Ihrer -Pipeline übergeben. Wenn der Konfigurationsname in keinem Schritt angegeben wird, wird die Standardkonfiguration in diesem Schritt verwendet. Die Übergabe eines falschen Konfigurationsnamens führt zum Fehlschlagen des Schritts, es sei denn, die Option ServiceNow DevOps-Fehler ignorieren wird während der Konfiguration des Plugins Jenkins ausgewählt.

    Hinweis:
    Die Phasenzuordnung wird nur für Phasen auf der Stammebene unterstützt, nicht für geschachtelte oder parallele Phasen.

    Jenkins Ausschnittsgenerator für DevOps

    Sie können das Dienstprogramm Snippet Generator Jenkins verwenden, um einen Vorlagencode für die Orchestration-Aufgaben für geskriptete Pipelines zu generieren. Mit dem Dienstprogramm zur Generierung von Codeausschnitten können Sie Vorlagen für die folgenden Orchestration-Aufgaben erstellen.
    • SnDevOpsArtifact
    • SnDevOpsChange
    • SnDevOps-Paket
    • snDevOpsGetChangeNumber
    • snDevOpsUpdateChangeInfo
    • snDevOpsSecurityResult
    Um einen Schrittausschnitt zu generieren, navigieren Sie aus einer konfigurierten Pipeline zur Pipeline-Syntax, wählen Sie den Schritt aus der Liste Beispielschritt aus, und aktualisieren Sie die Werte für verschiedene Variablen im Schritt. Wählen Sie die Option Fehler ignorieren aus, um zu verhindern, dass der Auftrag fehlschlägt, wenn ein Fehler auftritt. Wählen Sie Pipeline-Skript generieren aus, um ein Snippet zu erstellen. Sie können den Ausschnitt kopieren und in eine Pipeline einfügen.
    Beispiel für ein Pipeline-Skript für die SnDevOpsChange-Aufgabe:
    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

    Unterstützung für parallele und untergeordnete Phasen

    Wenn eine Phase (oder ein Satz paralleler Phasen) in einer Pipelinephase geschachtelt ist, gelten folgende Regeln:

    • Jede Aktion aus der geschachtelten Phase wird als Teil der übergeordneten Phase auf Stammebene verarbeitet
    • Es wird nur eine Change-Anforderung erstellt (auf der übergeordneten Stammebene), auch wenn mehrere Phasen, die unter der übergeordneten Phase auf Stammebene geschachtelt sind, einen Change auslösen
    • Erstellte Orchestration-Aufgaben sind immer der übergeordneten Phase auf Stammebene zugeordnet (nicht der geschachtelten Phase).

    Unterphase

    In diesem Beispiel für eine Unterphase werden, wenn eine Change-Anforderung aus der Unterphase (PROD bereitstellen) erstellt wird, die Details der übergeordneten Phase auf Stammebene (Bereitstellen) in der Change-Anforderung verwendet, und Orchestration-Aufgaben werden ebenfalls dem übergeordneten Element zugeordnet Phase auf Stammebene (bereitstellen).

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

    Parallele Phase

    In diesem Beispiel für eine parallele Phase wird, wenn eine Change-Anforderung aus einer Unterphase (UAT-Test-1 und/oder UAT-Test mit statischem Code) erstellt wird, nur die erste Change-Anforderung erstellt (unter Verwendung der Details der übergeordneten Phase auf Stammebene, UAT unabhängig davon, ob beide Unterphasen (UAT-Test-1 und UAT-Test für statischen Code) ausgelöst werden.

    Es gibt keinen Hinweis darauf, welche parallele Phase den Change generiert hat, und Orchestration-Aufgaben sind der übergeordneten Phase auf Stammebene zugeordnet (UAT-Test).

    
    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
                  }
              }
          }
     }