Utiliser un pipeline déclaratif ou scripté dans DevOps
Lorsque vous utilisez un fichier Jenkinsfile, les étapes sont créées, mappées et associées aux tâches d'orchestration automatiquement plutôt que manuellement.
Jenkinsfile est un fichier texte qui contient la définition d'un pipeline Jenkins et qui est archivé dans le contrôle de source.
Chaque étape de niveau racine configurée dans Jenkinsfile est détectée en tant que tâche d'orchestration distincte dans DevOps qui est mappée sur une étape individuelle.
Commandes DevOps Jenkinsfile
- snDevOpsChange(ignoreErrors:{true/false},changeRequestDetails:{setCloseCode:{true/false},attributes:})
Où ignoreErrors spécifie le paramètre permettant d'empêcher l'échec de la tâche en cas d'erreur (true/false)
Où changeRequestDetails spécifie le code de fermeture et les champs de demande de changement du pipeline
Active le contrôle du changement pour chaque étape de niveau racine mappée sur une étape DevOps.
- snDevOpsArtifact
Enregistre les artefacts lors de la configuration de Artefacts et packages.
- snDevOpsPackage
Crée un package pour les artefacts lors de la configuration de Artefacts et packages.
- 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
Met à jour les détails de la demande de changement associés à un pipeline Jenkins.
- snDevOpsSecurityResult
Configure les analyses de sécurité à n'importe quelle étape du pipeline, et les détails de l'analyse sont extraits de l'étape correspondante et envoyés à Vélocité de changement DevOps.
Vous pouvez spécifier la configuration du serveur Jenkins 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 est utilisée dans cette étape. La transmission d'un nom de configuration incorrect entraîne l'échec de l'étape, sauf si l'option Ignorer les erreurs ServiceNow DevOps est sélectionnée lors de la configuration du module d'extension Jenkins.
Générateur d'extraits Jenkins pour 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: 60Prise en charge d'étapes parallèles et de sous-étapes
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 de niveau 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éploiement en production), les détails de l'étape de niveau racine parent (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 parent (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.
Rien n'indique l'étape parallèle à l'origine du 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
}
}
}
}