Using a declarative or scripted pipeline in DevOps
Summarize
Summary of Using a declarative or scripted pipeline in DevOps
This content explains how ServiceNow DevOps integrates with Jenkins pipelines using Jenkinsfiles to automate orchestration tasks. By defining pipelines declaratively or script-based in a Jenkinsfile, each root-level stage automatically maps to individual orchestration steps in DevOps, streamlining pipeline management and change control.
Show less
Setting the Track field to True in DevOps enables job notifications from Jenkins configurations, ensuring synchronization between Jenkins and DevOps.
Key Features
- Jenkinsfile Integration: Jenkinsfiles checked into source control define pipelines, with root-level stages discovered as separate orchestration tasks in DevOps.
- DevOps Jenkinsfile Commands: Specialized commands enable change control, artifact registration, package creation, change request retrieval and updates, and security scan reporting within Jenkins pipelines, including:
snDevOpsChangefor managing change requests with error handling and closure settings.snDevOpsArtifactandsnDevOpsPackagefor artifact and package management.snDevOpsGetChangeNumberandsnDevOpsUpdateChangeInfofor change request tracking and information updates.snDevOpsSecurityResultto incorporate security scan results into DevOps Change Velocity.
- Jenkins Server Configuration: Each command accepts a configuration name to specify the Jenkins server; if omitted, the default configuration is used. Incorrect names cause failures unless errors are ignored via plugin settings.
- Stage Mapping Limitations: Only root-level stages are supported for mapping; nested or parallel stages do not map individually.
- Jenkins Snippet Generator: A utility within Jenkins helps generate pipeline script snippets for DevOps orchestration tasks, simplifying pipeline creation and customization.
Parallel and Sub-stage Support
When stages are nested or parallel within root-level stages, DevOps processes all nested actions under the parent root-level stage:
- Only one change request is created per parent root-level stage, even if multiple nested or parallel sub-stages trigger changes.
- Orchestration tasks associate with the parent root-level stage, not with individual nested or parallel sub-stages.
- For example, in nested "deploy" stages or parallel "UAT test" stages, change requests and tasks reflect the parent stage context, consolidating change management and reporting.
Practical Impact for ServiceNow Customers
By using Jenkinsfiles integrated with ServiceNow DevOps, customers can automate pipeline orchestration, improve traceability of change requests, and embed security and artifact management directly in their CI/CD processes. The ability to generate pipeline scripts with the Jenkins Snippet Generator accelerates pipeline development and ensures consistency.
Understanding stage mapping behavior ensures accurate change control and task association, particularly when using nested or parallel stages in Jenkins pipelines. Setting the Track field properly guarantees real-time job notifications and synchronization between Jenkins and DevOps.
When you use a Jenkinsfile, steps are created, mapped, and associated to orchestration tasks automatically instead of manually.
Jenkinsfile is a text file that contains the definition of a Jenkins pipeline and is checked into source control.
Each root-level stage configured in the Jenkinsfile is discovered as a separate orchestration task in DevOps that is mapped to an individual step.
DevOps Jenkinsfile commands
- snDevOpsChange(ignoreErrors:{true/false},changeRequestDetails:{setCloseCode:{true/false},attributes:})
Where ignoreErrors specifies the setting to prevent job failure if there is an error (true/false)
Where changeRequestDetails specifies closure code and change request fields from within the pipeline
Enables change control for each root-level stage that is mapped to a DevOps step.
- snDevOpsArtifact
Registers artifacts when configuring Artifacts and packages.
- snDevOpsPackage
Creates a package for artifacts when configuring Artifacts and packages.
- snDevOpsGetChangeNumber
Retrieves the change request number in a Jenkins pipeline based on specific change details.
- snDevOpsUpdateChangeInfo
Updates the change request details associated with a Jenkins pipeline.
- snDevOpsSecurityResult
Configures security scans on any stage of the pipeline and the scan details are retrieved from the corresponding stage to DevOps Change Velocity.
You can specify the Jenkins server configuration in any of these steps by passing the configurationName attribute in your pipeline. If the configuration name is not specified in any step, the default configuration will be used in that step. Passing an incorrect configuration name will result in the step to fail unless the Ignore ServiceNow DevOps errors option is selected while configuring the Jenkins plugin.
Jenkins snippet generator for DevOps
- SnDevOpsArtifact
- SnDevOpsChange
- SnDevOpsPackage
- 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: 60Parallel and sub-stage support
When a stage (or set of parallel stages) is nested within a pipeline stage, these rules apply:
- Any action from the nested stage is processed as part of the parent root-level stage
- Only one change request is created (at the parent root level) even if multiple stages nested under the parent root-level stage trigger a change
- Orchestration tasks created are always associated with the parent root-level stage (not the nested stage)
Sub stage
In this sub-stage example, if a change request gets created from the sub stage (deploy PROD), the details of the parent root-level stage (deploy) are used in the change request, and orchestration tasks are also associated with the parent root-level stage (deploy).
stage("deploy") {
stages{
stage('deploy UAT') {
when{
branch 'dev'
}
stage('deploy PROD') {
when {
branch 'master'
}
steps{
snDevOpsChange()
}
}
}
Parallel stage
In this parallel stage example, if a change request is created from a sub stage (UAT test-1 and/or UAT static code test), only the first change request is created (using the details of the parent root-level stage, UAT test) regardless of whether both sub stages (UAT test-1 and UAT static code test) get triggered.
There is no indication of which parallel stage generated the change, and orchestration tasks are associated with the parent root-level stage (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
}
}
}
}