Relancer des étapes spécifiques (si possible et pertinent)

La relance d'étapes : une fonctionnalité pour accélérer le débogage

Lorsqu'un pipeline Jenkins échoue, en particulier s'il est long et composé de nombreuses étapes (stages), devoir relancer l'intégralité du processus pour tester une correction peut s'avérer coûteux en temps et en ressources. Idéalement, on souhaiterait pouvoir reprendre l'exécution à partir de l'étape qui a échoué, ou juste avant, une fois la correction apportée. Jenkins, notamment avec son interface utilisateur Blue Ocean et pour les pipelines déclaratifs, offre des possibilités dans ce sens.

La capacité de relancer des étapes spécifiques est une aide précieuse au débogage. Elle permet d'itérer plus rapidement sur une solution sans avoir à attendre que toutes les étapes précédentes, potentiellement longues mais réussies, s'exécutent à nouveau. Cependant, cette fonctionnalité a ses limites et n'est pas toujours la solution appropriée.

Cette section explore quand et comment utiliser la relance d'étapes, ses avantages, et les scénarios où elle est la plus pertinente.

Relancer un stage échoué avec Blue Ocean

L'interface Blue Ocean de Jenkins, conçue pour offrir une meilleure visualisation des pipelines, facilite grandement la relance de stages échoués pour les pipelines déclaratifs (et certains pipelines scriptés structurés de manière similaire). Lorsqu'un stage échoue, Blue Ocean l'indique clairement dans sa représentation graphique du pipeline.

Si vous ouvrez la vue détaillée de ce build échoué dans Blue Ocean, vous verrez souvent une option pour "Rerun" (Relancer) directement au niveau du stage qui a posé problème. En cliquant sur cette option, Jenkins tentera de réexécuter uniquement ce stage et les suivants. Il est important de comprendre que Jenkins essaiera de repartir avec l'état du workspace tel qu'il était au début de ce stage lors de l'exécution précédente, ainsi qu'avec les mêmes paramètres de build.

// Exemple de pipeline déclaratif
pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                echo 'Compilation du code...'
                // sh './compile.sh'
            }
        }
        stage('Test') {
            steps {
                echo 'Exécution des tests unitaires...'
                // sh './run-tests.sh' // Supposons que cette étape échoue
            }
        }
        stage('Deploy') {
            steps {
                echo 'Déploiement de l'application...'
                // sh './deploy.sh'
            }
        }
    }
}

Si le stage 'Test' échoue dans le pipeline ci-dessus, Blue Ocean pourrait vous permettre de le relancer. Si vous avez corrigé le script ./run-tests.sh ou le code source entre-temps et que le nouveau code est accessible à l'agent (par exemple, si le checkout SCM se fait au début du pipeline global ou si le code est déjà sur l'agent), la relance utilisera cette version corrigée.

Cette fonctionnalité est particulièrement utile pour les erreurs transitoires (par exemple, un service réseau temporairement indisponible lors d'un test d'intégration) ou lorsque la correction concerne uniquement la logique interne d'un stage sans impacter l'état produit par les stages précédents.

Limitations et considérations importantes pour la relance d'étapes

Bien que pratique, la relance d'étapes spécifiques n'est pas une solution miracle et comporte des limitations :

• Etat du Workspace : Jenkins tente de réutiliser le workspace existant. Si les étapes précédentes ont créé des fichiers ou modifié l'environnement d'une manière qui influence l'étape relancée, et que ces modifications ne sont pas idempotentes, la relance pourrait ne pas se comporter comme une exécution fraîche. Si un nettoyage du workspace est nécessaire, la relance d'étape pourrait ne pas être appropriée.
• Dépendances entre étapes : Si l'échec d'une étape est dû à un problème survenu dans une étape antérieure (par exemple, un artefact de build incorrectement généré), relancer uniquement l'étape défaillante ne résoudra pas le problème de fond. Il faudra relancer depuis l'étape qui a causé le problème initial, ou tout le pipeline.
• Pipelines Scriptés Complexes : La fonctionnalité de relance est plus robuste et prévisible avec les pipelines déclaratifs. Pour les pipelines scriptés très complexes avec une logique de flux personnalisée, la relance d'une section arbitraire peut être difficile voire impossible pour Jenkins à gérer correctement.
• Non disponible dans l'interface Classique : L'interface utilisateur classique de Jenkins offre généralement moins de granularité pour la relance d'étapes spécifiques comparée à Blue Ocean. On peut souvent relancer le build entier, mais pas un stage isolé aussi facilement.
• Idempotence : Pour que la relance soit fiable, les étapes de votre pipeline devraient idéalement être idempotentes, c'est-à-dire qu'elles peuvent être exécutées plusieurs fois avec les mêmes entrées et produire le même résultat sans effets de bord indésirables. Par exemple, un script de déploiement qui s'assure d'abord que l'application n'est pas déjà dans l'état désiré avant d'agir est plus idempotent qu'un script qui déploie aveuglément.

Il est crucial de comprendre le flux de données et les dépendances entre les étapes de votre pipeline pour évaluer si la relance d'une étape spécifique est pertinente.

Alternatives et stratégies de débogage complémentaires

Si la relance d'une étape spécifique n'est pas possible ou pas pertinente, d'autres stratégies peuvent aider à accélérer le débogage :

• Commenter les étapes : Lors du développement ou du débogage intensif d'une section particulière d'un pipeline, vous pouvez temporairement commenter les étapes précédentes qui sont longues et réussies. Cela permet de se concentrer uniquement sur la partie problématique. N'oubliez pas de décommenter avant de commiter la version finale.

Exemple :

stage('Debug Deploy') {
    // when { expression { return false } } // Une autre façon de skipper temporairement
    steps {
        /*
        // Etapes longues et stables temporairement désactivées
        script {
            // sh './long-build-step.sh'
            // sh './another-stable-step.sh'
        }
        */
        echo "Concentration sur cette partie pour le débogage"
        sh './problematic-deploy.sh'
    }
}

• Paramétrisation pour le débogage : Introduire des paramètres de build qui contrôlent l'exécution de certaines sections. Par exemple, un paramètre booléen `SKIP_BUILD_STEPS` qui, s'il est vrai, saute les étapes de compilation pour aller directement aux tests ou au déploiement.
• Exécution locale : Si possible, essayez de reproduire et de déboguer la logique de l'étape échouée en local, en dehors de Jenkins. Cela peut être plus rapide pour des scripts shell ou des commandes d'outils spécifiques.
• Pipelines de test dédiés : Pour des fonctionnalités complexes, avoir un pipeline de test séparé qui ne s'exécute que sur la partie concernée peut être utile pendant le développement.

En conclusion, la relance d'étapes spécifiques est un outil utile dans l'arsenal de débogage Jenkins, surtout avec Blue Ocean. Toutefois, son efficacité dépend de la structure de votre pipeline et de la nature du problème. Elle doit être utilisée en complément d'autres techniques de diagnostic et de bonnes pratiques de conception de pipeline.