Git + CI/CD : automatiser son workflow DevOps avec Jenkins

Pourquoi combiner Git et CI/CD ?

Git seul vous permet de versionner votre code, de travailler en équipe et de gérer des branches. Mais sans CI/CD, chaque déploiement reste une opération manuelle : vous compilez sur votre machine, vous testez à la main, vous déployez via FTP ou SSH. C'est lent, risqué et source d'erreurs.

En ajoutant un serveur CI/CD comme Jenkins, chaque git push déclenche automatiquement un pipeline qui compile, teste et déploie. L'intervention humaine se limite à écrire du code et à le pousser sur Git. Tout le reste est automatisé.

Le workflow complet : du commit au déploiement

Voici le workflow type d'une équipe utilisant Git + Jenkins :

Webhook Git → Jenkins : déclencher automatiquement

Un webhook est une notification HTTP envoyée par GitHub (ou GitLab) à Jenkins chaque fois qu'un événement se produit dans le dépôt (push, pull request, merge).

Configuration d'un webhook GitHub → Jenkins

1. Dans GitHub : Settings → Webhooks → Add webhook
2. Payload URL : http://votre-jenkins:8080/github-webhook/
3. Content type : application/json
4. Événements : sélectionnez « Just the push event »
5. Dans Jenkins : dans la configuration du pipeline, cochez « GitHub hook trigger for GITScm polling »

Désormais, à chaque git push, GitHub envoie une notification à Jenkins, qui lance immédiatement le pipeline. Le délai entre le push et le démarrage du build est de quelques secondes.

Le Jenkinsfile dans le repo : Pipeline as Code

La bonne pratique est de stocker le Jenkinsfile à la racine du dépôt Git. Le pipeline vit avec le code. C'est le concept de Pipeline as Code.

Exemple de Jenkinsfile pour un projet Node.js

pipeline {
    agent any

    environment {
        NODE_ENV = 'production'
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }

        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint') {
            steps {
                sh 'npm run lint'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
        }

        stage('Build') {
            steps {
                sh 'npm run build'
            }
        }

        stage('Deploy to Staging') {
            when {
                branch 'develop'
            }
            steps {
                sh './deploy.sh staging'
            }
        }

        stage('Deploy to Production') {
            when {
                branch 'main'
            }
            steps {
                sh './deploy.sh production'
            }
        }
    }

    post {
        failure {
            echo 'Le pipeline a échoué. Vérifiez les logs.'
        }
        success {
            echo 'Déploiement réussi.'
        }
    }
}

Stratégie de branches pour le CI/CD

La manière dont vous organisez vos branches Git impacte directement votre pipeline CI/CD. Voici le modèle le plus courant :

Avec un pipeline multibranches Jenkins, chaque branche du dépôt qui contient un Jenkinsfile obtient automatiquement son propre pipeline. Jenkins détecte les nouvelles branches et crée les jobs correspondants.

Docker dans le pipeline : conteneuriser le build

Docker s'intègre naturellement dans un pipeline Jenkins. Au lieu d'installer les dépendances sur le serveur Jenkins, vous exécutez chaque étape dans un conteneur dédié :

pipeline {
    agent {
        docker {
            image 'node:20-alpine'
        }
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
        }

        stage('Build Docker Image') {
            steps {
                sh 'docker build -t mon-app:latest .'
            }
        }
    }
}

Avantage : l'environnement de build est reproductible et isolé. Pas de conflit entre les versions de Node.js, Python ou Java installées sur le serveur. Chaque pipeline utilise exactement l'image Docker dont il a besoin.

Bonnes pratiques du workflow Git + CI/CD

• Committez souvent, en petits morceaux. Des commits fréquents facilitent l'identification des bugs et réduisent les conflits de merge.
• Utilisez les merge requests (ou pull requests). Elles déclenchent le pipeline sur la branche avant le merge, ce qui garantit que le code est valide avant d'intégrer main.
• Protégez la branche main. Interdisez le push direct et exigez un pipeline vert avant le merge.
• Stockez le Jenkinsfile dans Git. Pipeline as Code = traçabilité, réversibilité, partage.
• Séparez les environnements. Staging pour tester, production pour livrer. Utilisez when { branch } dans le Jenkinsfile.
• Ne stockez jamais de secrets dans Git. Utilisez les credentials Jenkins ou un vault (HashiCorp Vault, AWS Secrets Manager).
• Monitorez vos builds. Configurez des notifications (Slack, email) pour être alerté en cas d'échec.

Maîtrisez Git et Jenkins

Pour mettre en place ce workflow complet, deux formations complémentaires sont disponibles dans le catalogue Lenidit :

19€/mois pour l'accès à l'ensemble du catalogue (ou 159€/an). Attestation de réussite incluse.