snDevOpsConfig

Konfigurationsdatenänderungen in einem Schritt hochladen, validieren und veröffentlichen.

Diese Aktion kombiniert die Aktionen snDevOpsConfigUpload, snDevOpsConfigGetSnapshots und snDevOpsConfigRegisterPipeline in einer Aktion, anstatt jede Aktion einzeln ausführen zu müssen.

Eingabevariablen

configFile	Gibt die Konfigurationsdatendatei an, die in die Komponente oder den bereitstellbaren Pfad im Datenmodell hochgeladen werden soll.
applicationName	Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen werden.
Ziel	Gibt das Datenmodellziel an, in das Konfigurationsdaten hochgeladen werden (z. B. Komponente, Sammlung, bereitstellbares Element).
collectionName	(Optional) Name der Sammlung, in die hochgeladen werden soll (erforderlich, wenn Ziel eine Sammlung ist).
bereitstellbarerName	(Optional) Name des bereitstellbaren Elements, in das hochgeladen werden soll (erforderlich, wenn das Ziel bereitstellbar ist).
namePath	Gibt den Namenspfad im Datenmodell an, wohin Konfigurationsdaten hochgeladen werden. Hinweis: Beim Hochladen in einen vars-Ordner müssen Sie den Namenspfad mit „vars/“ beginnen, um den Variablenordnerpfad anzugeben.
dataFormat	Gibt das Datenformat der Konfigurationsdatei an (z.  B. JSON, YAML, XMLusw.)
autoCommit	Gibt an, ob Konfigurationsdaten nach dem Hochladen committet werden sollen (wahr/falsch). Der Standardwert ist „true“.
autoValidate	Gibt an, ob Konfigurationsdaten während des Commits validiert werden sollen (wahr/falsch). Der Standardwert ist „true“.
autoPublish	Gibt an, ob die Konfigurationsdaten nach der Validierung veröffentlicht werden sollen (wahr/falsch). Der Standardwert ist „true“.
changesetNumber	(Optional) Gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist. Wenn nicht angegeben, wird ein neues Changeset erstellt. Hinweis: Wird nur für Szenarien mit mehreren Uploads verwendet.
markierenFehlgeschlagen	(Optional) Führen Sie für die Pipeline einen Fehler aus, falls der Validierungsversuch (aufgrund eines Back-End-Problems) fehlgeschlagen ist.
showResults	(Optional) Validierungsergebnisse im Protokoll der Jenkins -Auftragskonsole anzeigen.
ContinueWithLatest	(Optional) Gibt an, ob der neueste Snapshot gemäß der Kombination aus „aplicioName“, „deployableName“ und„changesetNumber“ zurückgegeben werden soll, wenn keine Snapshots generiert werden (wahr/falsch). Die Standardeinstellung ist „false“.

Ausgabe

• Bei Erfolg ein Snapshot oder eine Reihe von Snapshots.
• Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.

Beispiel

• Eingabe:

  
  snapshotObj = snDevOpsConfig(
       applicationName: "PaymentDemo",
       configFile: "config/application/Collection/Collection2/*.json",
       target: "collection",
       collectionName: "release-1.0",
       namePath: "settings/infrastructure/database",
       dataFormat: "json",
       autoCommit: 'true',
       autoValidate: 'true',
       autoPublish: 'true',
       continueWithLatest: 'true',
       markFailed: 'true',
       showResults: 'false'
  )
  
  echo"*************************\n ${snapshotObj}"

• Ausgabe

Beispiel: Sammlung

Hinweis:

Beim Hochladen in eine Sammlung ist das Argument „collectionName“ erforderlich.

snDevOpsConfig(
     applicationName: 'PaymentDemo',
     target: 'collection',
     collectionName: 'release-1.0',
     namePath: 'web-api-v1.0',
     configFile: 'k8s/helm/*.yml',
     dataFormat: 'yaml',
     autoCommit: 'true',
     autoValidate: 'true',
     autoPublish: 'true'
)

Beispiel: bereitstellbar

Hinweis:

Beim Hochladen in ein bereitstellbares Element ist das Argument „deployableName“ erforderlich.

snDevOpsConfig(
     applicationName: 'PaymentDemo',
     target: 'deployable',
     deployableName: 'Production',
     namePath: 'web-api-v1.0',
     configFile: 'k8s/helm/*.yml',
     dataFormat: 'yaml',
     autoCommit: 'true',
     autoValidate: 'true',
     autoPublish: 'true'
)

Mehrere Uploads in einem Commit

Um Konfigurationsdaten von verschiedenen Speicherorten hochzuladen oder einen Datensatz mit mehreren Zielen (z. B. eine Komponente, ein bereitstellbares Element) hochzuladen, die als einzelner Commit in Ihrem Datenmodell verfolgt werden, können Sie die Aktion snDevOpsConfigUpload so oft wie nötig für aufrufen Laden Sie den ersten Satz von Uploads herunter, und rufen Sie dann die snDevOpsConfig -Aktion für den endgültigen Upload auf.

Hier ist ein Beispiel.

• Erstellen Sie beim ersten Upload eine Variable (z. B. $changeset), und weisen Sie ihr den Rückgabewert des Schritts zu, damit er in nachfolgenden Uploads wiederverwendet werden kann​.

  1 - XML-Datei in Komponente hochladen:

  
  $changeset = snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'component',
       namePath: 'paymentService-v1.0',
       configFile: 'infra/v1/config.xml',
       dataFormat: 'xml',
       autoCommit: 'false',
       autoValidate: 'false',
       autoPublish: 'false'
  )

• Verwenden Sie bei nachfolgenden Uploads (und dem finalen Upload) die Variable als Eingabe​.

  2 – JSON-Datei in Ordner „vars“ des bereitstellbaren Elements hochladen:

  
  snDevOpsConfig(
       applicationName: 'PaymentDemo',
       target: 'deployable',
       deployableName: 'Production',
       namePath: 'vars/dbSettings',
       configFile: 'infra/prod/dbConfig.json',
       dataFormat: 'json',
       changesetNumber: ”${changeset}”,
       autoCommit: 'false',
       autoValidate: 'false',
       autoPublish: 'false',
       continueWithLatest: 'true'
  )

Laden Sie mehrere Datenformate hoch

Um Konfigurationsdaten in anderen Dateiformaten hochzuladen, können Sie die Aktion snDevOpsConfig mit diesen Spezifikationen aufrufen.

• Stellen Sie sicher, dass das Argument „configFile“ einen Platzhalter im Pfad verwendet.
• Geben Sie das Argument „dataFormat“ nicht an.

Hier ist ein Beispiel.

• Angenommen, wir haben diese Konfigurationsdateien.

  

• So laden Sie die Konfigurationsdateien mit snDevOpsConfighoch.

  
  snDevOpsConfig(
       applicationName: 'PaymentDemo',
       target: 'component',
       namePath: 'paymentService-v1.0',
       configFile: 'infra/v1/*',
       autoCommit: 'true',
       autoValidate: 'true',
       autoPublish: 'true'
  )

snDevOpsConfigUpload

Mit dieser Aktion wird eine Konfigurationsdatei an einen bestimmten Speicherort in einem Anwendungsdatenmodell hochgeladen.

Es soll iterativ für alle Konfigurationsdateien verwendet werden, die während der Pipeline-Ausführung in das Anwendungsdatenmodell hochgeladen werden sollen.

Eingabevariablen

configFile	Gibt die Konfigurationsdatendatei an, die in die Komponente oder den bereitstellbaren Pfad im Datenmodell hochgeladen werden soll.
applicationName	Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen werden.
Ziel	Gibt das Datenmodellziel an, in das Konfigurationsdaten hochgeladen werden (z. B. Komponente, Sammlung, bereitstellbares Element).
collectionName	(Optional) Name der Sammlung, in die hochgeladen werden soll (erforderlich, wenn Ziel eine Sammlung ist).
bereitstellbarerName	Name des bereitstellbaren Elements, in das hochgeladen werden soll (erforderlich, wenn das Ziel bereitstellbar ist).
namePath	Gibt den Namenspfad im Datenmodell an, wohin Konfigurationsdaten hochgeladen werden. Hinweis: Beim Hochladen in einen vars-Ordner müssen Sie den Namenspfad mit „vars/“ beginnen, um den Variablenordnerpfad anzugeben.
dataFormat	Gibt das Datenformat der Konfigurationsdatei an (z.  B. JSON, YAML, XMLusw.)
konvertierenPfad	(Optional) Gibt an, ob die Verzeichnisstruktur der Konfigurationsdateien (in Bezug auf den Arbeitsbereich) erhalten und das Verzeichnis innerhalb des Datenmodells in Pfade konvertiert werden soll.
changesetNumber	(Optional) Gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist. Wenn nicht angegeben, wird ein neues Changeset erstellt. Hinweis: Wird nur für Szenarien mit mehreren Uploads verwendet.
autoCommit	Gibt an, ob Konfigurationsdaten nach dem Hochladen committet werden sollen (wahr/falsch). Die Standardeinstellung ist „false“.
autoValidate	Gibt an, ob Konfigurationsdaten während des Commits validiert werden sollen (wahr/falsch). Die Standardeinstellung ist „false“.

Ausgabevariable

changesetNumber

(Optional) Gibt das (offene) Changeset an, dem diese Upload-Aktivität zugeordnet ist. Wenn keine Changeset-Nummer angegeben wird, wird ein neues Changeset erstellt.

Beispiel

• Eingabe:

  Hier ist ein Beispiel für die Aktion snDevOpsConfigUpload. Zur Veranschaulichung weisen wir die Antwort einer Variablen zu, changeSetId, die für Debugging-Szenarien in unserem Konsolenprotokoll wiedergegeben werden kann.

  
  changeSetId = snDevOpsConfigUpload(
       applicationName: "PaymentDemo",
       target: 'component',
       namePath: "web-api-v1.0",
       configFile: "k8s/helm/values.yml",
       dataFormat: "json",
       autoCommit: 'true',
       autoValidate: 'true'
  )
  
  echo "Changeset: $changeSetId created"

• Ausgabe:

  Zusätzlich zu den Daten, die in unser Datenmodell in DevOps Confighochgeladen werden, würde die Ausgabe in etwa so aussehen (Verwenden des BlueOcean-Plugins, um die Konsolenausgabe zu visualisieren).

  

Beispiel – Mehrere Uploads (Komponente)

Sie können die Upload-Aktion mehrmals aufrufen, um Konfigurationsdaten in verschiedenen Dateiformaten von verschiedenen Speicherorten hochzuladen, während die Uploads Teil eines Changesets bleiben.

• Benennen Sie die Aktion beim ersten Upload, damit die Ausgabevariable changesetNumber in nachfolgenden Uploads wiederverwendet werden kann.
  Upload der YAML-Datei:

  
  $changeset = snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'component',
       namePath: 'wep-api-v1.0',
       configFile: 'k8s/helm/values.yml',
       dataFormat: 'yaml',
       autoCommit: 'false',
       autoValidate: 'false'
  )

• Verweisen Sie in nachfolgenden Uploads auf die Ausgabevariable changesetNumber des ersten Uploads als Eingabevariable.
  Upload von 3 JSON-Dateien:

  
  snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'component',
       namePath: 'wep-api-v1.0',
       configFile: 'infra/*.json',
       dataFormat: 'json',
       autoCommit: 'false',
       autoValidate: 'false',
       changesetNumber: ”${changeset}”
  )

• Im letzten Aufruf wird nicht nur die Ausgabevariable changesetNumber aus dem ersten Upload als Eingabevariable referenziert, sondern auch autoCommit und autoValidate auf truefestgelegt.
  Upload der INI-Datei:

  
  snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'component',
       namePath: 'wep-api-v1.0',
       configFile: 'featureToggles/set1.ini',
       dataFormat: 'ini',
       autoCommit: 'true',
       autoValidate: 'true',
       changesetNumber: ”${changeset}”
  )

Beispiel – Mehrere Uploads (Sammlung und Variablen)

Sie können die Upload-Aktion mehrmals aufrufen, um Konfigurationsdaten in verschiedenen Dateiformaten von verschiedenen Speicherorten hochzuladen, während die Uploads Teil eines Changesets bleiben.

• Erstellen Sie beim ersten Upload eine Variable (z. B. $changeset), und weisen Sie ihr den Rückgabewert des Schritts zu, damit er in nachfolgenden Uploads wiederverwendet werden kann.
  XML-Dateiupload:

  
  $changeset = snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'collection',
       collectionName: 'release-v1.0',
       namePath: 'v1-common-configs',
       configFile: 'infra/v1/config.xml',
       dataFormat: 'xml',
       autoCommit: 'false',
       autoValidate: 'false'
  )

• Verwenden Sie in nachfolgenden Uploads die Variable als Eingabe.
  Upload der JSON-Datei:

  
  snDevOpsConfigUpload(
       applicationName: 'PaymentDemo',
       target: 'deployable',
       deployableName: 'Production',
       namePath: 'vars/dbSettings',
       configFile: 'infra/prod/dbConfig.json',
       dataFormat: 'json',
       autoCommit: 'true',
       autoValidate: 'true',
       changesetNumber: ”${changeset}”
  )

Hinweis:

Zum Hochladen in einen Variablenordner muss „uploadTarget“ auf „deployable“festgelegt werden, und für „deployableName“ und „changesetNumber“ müssen die richtigen Werte festgelegt sein.

snDevOpsConfigGetSnapshots

Diese Aktion soll in verschiedenen Szenarien verwendet werden:

• Rufen Sie alle Snapshots für alle betroffenen bereitstellbaren Elemente ab.

  Wenn Konfigurationsdateien in ein Anwendungsdatenmodell hochgeladen werden, erstellt das System Snapshots für alle bereitstellbaren Elemente, die vom Upload betroffen sind. Wenn Sie dem CI-Flow folgen und davon ausgehen, dass für den letzten Upload-Aufruf die Validierung aktiviert war, besteht der nächste Schritt darin, die Liste der Snapshots zu durchlaufen und sicherzustellen, dass alle die Validierung bestanden haben.

• Ruft einen bestimmten Snapshot ab.

  Nach dem CD-Flow wird ein bestimmter Snapshot abgerufen, damit er veröffentlicht und dann zur Verwendung nachgelagert exportiert werden kann (z. B. um eine Infrastruktur oder Anwendung bereitzustellen).

• Rufen Sie die neuesten Snapshots für ein bereitstellbares Element einer Anwendung ab, falls ein Upload keine Snapshots generiert.

  Ein Satz von Konfigurationsdaten ist für die Bereitstellung in einer Umgebung für eine Kombination aus Anwendung, bereitstellbarem Element und Changeset verfügbar, wenn keine Konfigurationsänderungen vorgenommen werden.

• Zeigen Sie die Ergebnisse der Richtlinienvalidierung in einer Pipelineausführung an.

  Zeigen Sie die Ergebnisse der Richtlinienvalidierung als Testergebnisse auf der Ergebnisseite des Jenkins-Build-Tests an, einschließlich konform mit Ausnahme, wenn Sie einen Snapshot abrufen.

Eingabedefinitionen

applicationName	Gibt die Anwendung an, in die Konfigurationsdaten hochgeladen oder aus der Daten exportiert werden sollen.
bereitstellbarerName	(Optional) Gibt das bereitstellbare Element für die Anwendung an, für die die neuesten Snapshot-Daten abgerufen werden sollen.
changesetNumber	(Optional) Gibt die Changeset-ID für den Satz von Konfigurationsänderungen an, an denen der Benutzer interessiert ist.
istValidiert	(Optional) Gibt an, ob nur Snapshots zurückgegeben werden sollen, die übergeben wurden, oder nur Snapshots, die mit Ausnahme übergeben wurden (wahr/falsch). Der Standardwert ist „true“.
ContinueWithLatest	(Optional) Gibt an, ob der neueste Snapshot gemäß der Kombination aus „aplicioName“, „deployableName“ und„changesetNumber“ zurückgegeben werden soll, wenn keine Snapshots generiert werden (wahr/falsch). Die Standardeinstellung ist „false“.

Ausgabe

• Bei Erfolg ein Snapshot oder eine Reihe von Snapshots.
• Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.

Beispiel

• Spezifischer Snapshot (angegeben):

  
  $snapshots = snDevOpsConfigGetSnapshots(
       applicationName: 'PaymentDemo',
       deployableName: 'Production',
       changesetNumber: 'Chset-16',
       isValidated: 'true',
       continueWithLatest: 'true'
  )

• Letzter validierter Snapshot (gibt den neuesten Snapshot für die Kombination aus Anwendung und bereitstellbarem Element zurück):

  
  $snapshots = snDevOpsConfigGetSnapshots(
       applicationName: 'PaymentDemo',
       deployableName: 'Production',
       isValidated: 'true'
  )

• Alle Changeset-Snapshots (gibt alle Snapshots für die Kombination aus Anwendung und bereitstellbarem Element zurück):

  
  $snapshots = snDevOpsConfigGetSnapshots(
       applicationName: 'PaymentDemo',
       changesetNumber: 'Chset-16'
  )

• Zeigen Sie die Ergebnisse der Richtlinienvalidierung in einer Pipelineausführung an.
  1. Weisen Sie dem Pfad der Datei, die die Snapshot-Validierungsergebnisse enthält, die während der Aktion snDevOpsConfigGetSnapshots generiert wurden, eine Variable zu.
  2. Rufen Sie die JUnit-Aktion auf, um die Snapshot-Validierungsergebnisse in den Testabschnitt der Pipeline-Ausführung zu laden.

  
  stage('Validate') {
      steps {
  	script {
             changeSetResults = snDevOpsConfigGetSnapshots( … )
             if (!changeSetResults) {
                echo "No snapshots were created"
             } else {
  	       def changeSetResultsObject = readJSON text: changeSetResults
  
  	       changeSetResultsObject.each {
                    snapshotName = it.name
                    snapshotObject = it
  	       }
  	       // STEP 1
  		validationResultsPath = "${snapshotName}_${currentBuild.projectName}_${currentBuild.number}.xml"
  	    }
  	}
      }
  }
  
  post {
      always {
          // STEP 2
          junit testResults: "${validationResultsPath}", skipPublishingChecks: true
      }
  }
  

snDevOpsConfigPublish

Diese Aktion veröffentlicht einen Snapshot für die angegebene Anwendung und das bereitstellbare Element. Von hier aus kann der Snapshot durch den Exportprozess verwendet werden.

Eingabedefinitionen

applicationName	Gibt die Anwendung an, aus der Konfigurationsdaten veröffentlicht werden sollen.
bereitstellbarerName	Gibt das bereitstellbare Element für die Anwendung an, aus der Konfigurationsdaten veröffentlicht werden sollen.
snapshotName	Gibt den Namen des zu veröffentlichenden Snapshots an.

Ausgabe

• Bei Erfolg „wahr“.
• Andernfalls „falsch“.

Beispiel

snDevOpsConfigPublish(
     applicationName: 'PaymentDemo',
     deployableName: 'Production',
     snapshotName: 'Production-v23.dpl',
)

snDevOpsConfigExport

Mit dieser Aktion wird ein Snapshot für die angegebene Anwendung und das bereitstellbare Element exportiert.

Der Anwender sollte den Exporter, relevante Exporter-Argumente, das Exportformat (z. B. YAML, JSON) und den Ausgabespeicherort für die exportierten Konfigurationsdaten angeben.

Von hier aus können die Konfigurationsdaten direkt als Eingabe für ein nachfolgendes Bereitstellungs- oder Bereitstellungstool in der Pipeline verwendet werden.

Eingabeargumente

applicationName	Gibt die Anwendung an, aus der Daten exportiert werden sollen.
bereitstellbarerName	Gibt das bereitstellbare Konfigurationselement für die Anwendung an, aus der Daten exportiert werden sollen.
snapshotName	(Optional) Gibt den Snapshot an, aus dem Daten exportiert werden sollen. Wenn kein Snapshot angegeben ist, wird der neueste Snapshot für das bereitstellbare Element verwendet.
exporterName	Gibt den Exporter an, der auf den Snapshot angewendet werden soll (z. B. UniqueCDIs).
exporterArgs	(Optional) Gibt Argumente an, die zusammen mit dem Exporter verwendet werden sollen.
exportFormat	Gibt das Format für den Export der Snapshot-Daten an (z. B. INI, YAML, PROPS).
fileName	Gibt die Datei an, in die Daten exportiert werden sollen (vermutlich im Arbeitsbereich). Wenn kein Dateiname angegeben ist, wird standardmäßig eine Verkettung von Anwendungsname und bereitstellbarem Namen (einschließlich Dateierweiterung) verwendet.

Ausgabe

• Bei Erfolg „wahr“.
• Andernfalls „falsch“.

Beispiel

snDevOpsConfigExport(
     applicationName: 'PaymentDemo',
     deployableName: 'Production',
     snapshotName: 'Production-v23.dpl',
     exporterFormat: 'yaml',
     exporterName: 'returnAllData-now',
     exporterArgs: '',
     fileName: 'exported_file-Production-20220302.yml'
)

snDevOpsConfigRegisterPipeline

Diese Aktion bindet ein Changeset und/oder einen Snapshot an die Pipeline, sodass sie während der Pipeline-Ausführung nachverfolgt werden können. In DevOps Change-Geschwindigkeitwird dies in der Pipeline-UI angezeigt.

Unter Ihren DevOps Change-Prozess beschleunigen finden Sie weitere Informationen zur Funktion DevOps Change-Beschleunigung.

Eingabeargumente

applicationName	Gibt den Namen der Anwendung an.
changesetNumber	(Optional) Gibt den Changeset an, der der Pipeline-Ausführung zugeordnet werden soll. Hinweis: Geben Sie entweder „changesetNumber“ oder „snapshotName“ an, aber nicht beide.
snapshotName	(Optional) Gibt den Namen des Snapshots an, der der Pipeline-Ausführung zugeordnet werden soll. Hinweis: Geben Sie entweder „changesetNumber“ oder „snapshotName“ an, aber nicht beide.

Ausgabe

• Bei Erfolg „wahr“.
• Andernfalls „falsch“.

Beispiel

• Eingabe:

  Hier ist ein Beispiel für die Aktion snDevOpsConfigRegisterPipeline. Zur Veranschaulichung weisen wir die Antwort einer Variablen zu, changeSetRegResult, die für Debugging-Szenarien in unserem Konsolenprotokoll wiedergegeben werden kann.

  
  changeSetRegResult = snDevOpsConfigRegisterPipeline(
       applicationName: "PaymentDemo",
       changesetNumber: "Chset-122"
  )
  
  echo "Pipeline registration result: ${changeSetRegResult}"

• Ausgabe:

  Zusätzlich zu den Daten, die in unser Datenmodell in DevOps Confighochgeladen werden, würde die Ausgabe in etwa so aussehen (Verwenden des BlueOcean-Plugins, um die Konsolenausgabe zu visualisieren).

  

snDevOpsConfigValidate

Validiert die Konfigurationsdaten anhand der Richtlinien Ihrer Organisation.

Eingabeargumente

applicationName	Zu validierende Anwendung.
bereitstellbarerName	Bereitstellbar für die Anwendung zur Validierung.
snapshotName	(Optional) Name des zu validierenden Snapshots.
markierenFehlgeschlagen	(Optional) Führen Sie für die Pipeline einen Fehler aus, falls der Validierungsversuch (aufgrund eines Back-End-Problems) fehlgeschlagen ist.
showResults	(Optional) Validierungsergebnisse im Protokoll der Jenkins -Auftragskonsole anzeigen.

Ausgabe

• Bei Erfolg keine Ausgabe.
• Bei einem Fehler wird eine API-/Back-End-Fehlermeldung angezeigt.

Beispiel

• Spezifischer Snapshot (angegeben):

  
  snDevOpsConfigValidate(
       applicationName: 'PaymentDemo',
       deployableName: 'Production',
       snapshotName: 'Production-v23.dpl',
  )

• Aktueller Snapshot (ruft den neuesten Snapshot für die Kombination aus Anwendung und bereitstellbarem Element ab und validiert ihn):

  
  $changeset = snDevOpsConfigValidate(
       applicationName: 'PaymentDemo',
       deployableName: 'Production'
  )

snDevOpsChange

Erstellt eine Change-Anforderung und hängt einen Snapshot als Referenz an.

Unter Ihren DevOps Change-Prozess beschleunigen finden Sie weitere Informationen zur Funktion DevOps Change-Beschleunigung.

Eingabeargumente

applicationName	Gibt den Namen der Anwendung an.
snapshotName	Gibt den Namen des Snapshots an, der dem Change Request zugeordnet werden soll.

Beispiel

snDevOpsChange(
     applicationName: 'PaymentDemo',
     snapshotName: 'Production-v23.dpl'
)

Beispiel für Jenkins-Pipeline

pipeline {
    environment {
        buildArtifactsPath = "build_artifacts/${currentBuild.number}"
        validationResultsPath = ""
    }

    agent any

    stages {
        // Initialize pipeline
        stage('Initialize') {
            steps {
                script {
                    // DevOps Config application related information
                    appName = 'PaymentDemo'
                    deployableName = 'Production'
                    componentName = "web-api-v1.0"
                    collectionName = "release-1.0"
                    // Configuration file information
                    exportFormat = 'yaml'
                    configFilePath = "k8s/helm/values.yml"
                    // Exporter related information
                    exporterName = 'returnAllData-nowPreview' 
                    exporterArgs = ''
                    // Jenkins variables declared to be used in pipeline
                    exportFileName = "${buildArtifactsPath}/export_file-${appName}-${deployableName}-${currentBuild.number}.${exportFormat}"
                    changeSetId = ""
                    snapshotName = ""
                    snapshotObject = ""
                    isSnapshotValidateionRequired = false
                    isSnapshotPublisingRequired = false
                }
            }
        }
            
        // Validate configuration data changes
        stage('Validate') {
            parallel {
                stage('Config') {
                    stages('Config Steps') {
                        // Upload configuration data to DevOps Config
                        stage('Upload, Validate, & Publish') {
                            steps {
                                sh "echo uploading and auto-validating configuration file: ${configFilePath}"
                                script {
                                    changeSetResults = snDevOpsConfig(
                                        applicationName: "${appName}",
                                        target: 'component',
                                        namePath: "${componentName}",
                                        configFile: "${configFilePath}",
                                        dataFormat: "${configFileFormat}",
                                        autoCommit: 'true',
                                        autoValidate: 'true',
                                        autoPublish: 'true',
                                        isValidated: 'true',
                                        continueWithLatest: 'true',
                                        markFailed: 'true'
                                    )

                                    echo "Snapshots generated, validated, and published: ${changeSetResults}"

                                    def changeSetResultsObject = readJSON text: changeSetResults

                                    changeSetResultsObject.each {
                                        snapshotName = it.name
                                        snapshotObject = it
                                    }

                                    validationResultsPath = "${snapshotName}_${currentBuild.projectName}_${currentBuild.number}*.xml"
                                }
                            }
                        }
                        // Export published snapshot to be used by downstream deployment tools
                        stage('Export') {
                            steps {
                                script {
                                    // create build artifacts dir to store export file
                                    sh "mkdir -p ${buildArtifactsPath}"
                                    
                                    exportResponse = snDevOpsConfigExport(
                                        applicationName: "${appName}",
                                        snapshotName: "${snapshotObject.name}",
                                        deployableName: "${deployableName}",
                                        exporterFormat: "${exportFormat}",
                                        fileName: "${exportFileName}",
                                        exporterName: "${exporterName}",
                                        exporterArgs: "${exporterArgs}"
                                    )
                                }
                            }
                        }
                    }
                }
            }
        }
        
        // Create change request and attach snapshot for reference
        stage('Change Management') {
            steps {
                script {
                    // Trigger change request
                    snDevOpsChange(
                        applicationName: "${appName}",
                        snapshotName: "${snapshotName}"
                    )
                }     
            }
        }
    }
    // NOTE: attach snapshot validation results to run (if the snapshot fails validation)
    post {
        always {
            // attach policy validation results
            junit testResults: "${validationResultsPath}", skipPublishingChecks: true
        }
    }
}