Mithilfe einer deklarativen oder geskripteten Pipeline in DevOps
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.
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.
Jenkins Ausschnittsgenerator für DevOps
- SnDevOpsArtifact
- SnDevOpsChange
- SnDevOps-Paket
- snDevOpsGetChangeNumber
- snDevOpsUpdateChangeInfo
- snDevOpsSecurityResult
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: 60Unterstü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
}
}
}
}