Aller au contenu principal

Configuration de pipeline CI/CD dans Cursor : guide complet

Pipeline CI/CD dans Cursor

Les pipelines d'intégration continue et de déploiement continu (CI/CD) automatisent le processus de construction, de test et de publication, permettant aux équipes de livrer du code en toute sécurité et fréquemment. Le CI/CD moderne couvre plusieurs plateformes — GitHub Actions pour les projets hébergés sur GitHub, GitLab CI pour les dépôts GitLab, et Jenkins pour les pipelines auto-hébergés et hautement personnalisables. Cursor, avec son assistant IA intégré et son modèle d'extensions compatible VS Code, est un excellent éditeur pour créer et maintenir des configurations de pipeline. Il peut générer des workflows à partir de prompts en langage naturel, valider la syntaxe YAML et refactoriser les pipelines au fur et à mesure que votre projet évolue.

Ce guide couvre le workflow CI/CD complet dans Cursor : configuration de GitHub Actions, GitLab CI et Jenkins, intégration de tests automatisés, exploitation de l'IA pour générer et optimiser la configuration de pipeline, et suivi des bonnes pratiques pour une automatisation sûre et fiable.

Configuration des outils CI/CD dans Cursor​

Extensions essentielles​

Cursor hérite de l'écosystème d'extensions de VS Code. Installez celles-ci pour rationaliser la création de pipelines :

  1. YAML (par Red Hat) — validation de schéma pour GitHub Actions, GitLab CI et les fichiers Docker Compose.
  2. GitHub Actions — coloration syntaxique et snippets pour les fichiers de workflow.
  3. GitLab Workflow — validation GitLab CI et gestion des MR.
  4. Docker — création de Dockerfile et assistants de construction d'images.
astuce

L'extension YAML télécharge automatiquement les schémas JSON pour les types de fichiers bien connus. Lorsque vous créez .github/workflows/deploy.yml, Cursor valide la structure par rapport au schéma officiel GitHub Actions et offre l'autocomplétion pour chaque champ.

Structure de projet pour CI/CD​

Un projet prêt pour CI/CD comprend généralement :

project/
  ├── .github/
  │   └── workflows/
  │       ├── ci.yml
  │       └── deploy.yml
  ├── .gitlab/
  │   └── ci/
  │       └── templates.yml
  ├── .jenkins/
  │   └── Jenkinsfile
  ├── src/
  ├── tests/
  ├── Dockerfile
  ├── docker-compose.yml
  └── package.json

GitHub Actions​

Création de votre premier workflow​

GitHub Actions utilise des fichiers YAML dans .github/workflows/. Un workflow CI de base s'exécute sur chaque push et pull request :

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npm run type-check

      - name: Run tests
        run: npm test -- --coverage

      - name: Upload coverage
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/
          retention-days: 14
astuce

Utilisez npm ci au lieu de npm install en CI. La commande ci installe les versions exactes du lockfile, produisant des builds reproductibles et échouant rapidement en cas de dérive du lockfile.

Builds matriciels​

Testez sur plusieurs versions de Node.js et systèmes d'exploitation avec une matrice :

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

Mise en cache des dépendances​

Accélérez les workflows en mettant en cache les dépendances et les sorties de build :

- name: Cache npm
  uses: actions/cache@v4
  with:
    path: |
      ~/.npm
      node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-
attention

Les clés de cache basées uniquement sur le hachage de package-lock.json échoueront lorsque le lockfile change. Incluez l'OS et la version de Node dans la clé pour éviter la contamination croisée entre environnements d'exécution.

Workflows réutilisables​

Découpez les grands workflows en composants réutilisables :

# .github/workflows/reusable-test.yml
name: Reusable Test

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
      - run: npm ci
      - run: npm test

Appelez-le depuis un autre workflow :

jobs:
  test:
    uses: ./.github/workflows/reusable-test.yml
    with:
      node-version: 20

Workflow de déploiement​

Un job de déploiement qui ne s'exécute que sur la branche main :

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: test
    environment:
      name: production
      url: https://app.example.com
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:latest
            123456789012.dkr.ecr.us-east-1.amazonaws.com/app:${{ github.sha }}

      - name: Deploy to ECS
        run: |
          aws ecs update-service --cluster app-cluster --service app-service --force-new-deployment
attention

Utilisez les GitHub Environments avec des relecteurs requis pour les déploiements en production. Cela ajoute une porte d'approbation manuelle avant l'exécution du job de déploiement, empêchant les releases accidentelles.

GitLab CI​

Configuration de .gitlab-ci.yml​

GitLab CI utilise un seul fichier .gitlab-ci.yml à la racine du dépôt :

# .gitlab-ci.yml
stages:
  - lint
  - test
  - build
  - deploy

variables:
  NODE_VERSION: "20"
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/

lint:
  stage: lint
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm run lint
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
  stage: test
  image: node:${NODE_VERSION}
  script:
    - npm ci
    - npm test -- --coverage
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy:production:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-ecs:latest
  script:
    - ecs update-task-definition --cluster app-cluster --service app-service --image $CI_REGISTRY_IMAGE:$IMAGE_TAG
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  when: manual
astuce

Le mot-clé rules de GitLab CI remplace l'ancienne syntaxe only/except. Utilisez rules avec des conditions if pour un contrôle précis du moment d'exécution des jobs, et combinez avec changes pour déclencher les jobs uniquement lorsque les fichiers pertinents sont modifiés.

Modèles GitLab CI​

Découpez les pipelines complexes en fichiers d'inclusion :

# .gitlab/ci/test.yml
.test-template:
  stage: test
  image: node:${NODE_VERSION}
  before_script:
    - npm ci
  script:
    - npm test

Incluez-les :

include:
  - local: .gitlab/ci/test.yml

unit-test:
  extends: .test-template
  script:
    - npm run test:unit

Jobs parallèles et matriciels​

test:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
        OS: ["alpine", "slim"]
  script:
    - npm ci
    - npm test

Jenkins​

Écriture d'un Jenkinsfile​

Les pipelines Jenkins utilisent un DSL basé sur Groovy dans un Jenkinsfile :

// Jenkinsfile
pipeline {
    agent {
        docker {
            image 'node:20-alpine'
            args '-v $HOME/.npm:/root/.npm'
        }
    }

    environment {
        NODE_ENV = 'production'
        DOCKER_IMAGE = "registry.example.com/app:${env.BUILD_NUMBER}"
    }

    options {
        timeout(time: 30, unit: 'MINUTES')
        disableConcurrentBuilds()
        buildDiscarder(logRotator(numToKeepStr: '20'))
    }

    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 -- --coverage'
            }
            post {
                always {
                    junit 'reports/junit.xml'
                    publishHTML(target: [
                        reportDir: 'coverage/lcov-report',
                        reportFiles: 'index.html',
                        reportName: 'Coverage Report'
                    ])
                }
            }
        }

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

        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh "docker build -t ${DOCKER_IMAGE} ."
                sh "docker push ${DOCKER_IMAGE}"
                sh "kubectl rollout restart deployment/app -n production"
            }
        }
    }

    post {
        failure {
            emailext subject: "Build failed: ${env.JOB_NAME} #${env.BUILD_NUMBER}",
                     body: "Check the build at ${env.BUILD_URL}",
                     to: '[email protected]'
        }
        success {
            slackSend channel: '#deploys',
                      message: "Build succeeded: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
        }
    }
}
attention

Les Jenkinsfiles s'exécutent avec les permissions du contrôleur Jenkins. N'utilisez jamais sh pour invoquer des commandes contenant des entrées non fiables, et citez toujours les variables interpolées pour empêcher l'injection shell.

Pipeline déclaratif vs scripté​

L'exemple ci-dessus utilise la syntaxe déclarative. Pour une logique complexe, passez aux blocs scriptés :

stage('Conditional Deploy') {
    steps {
        script {
            def env = params.ENVIRONMENT
            if (env == 'production') {
                input(message: 'Approve production deployment?', ok: 'Deploy')
            }
            sh "./deploy.sh ${env}"
        }
    }
}

Bibliothèques partagées Jenkins​

Pour une logique de pipeline réutilisable, définissez une bibliothèque partagée :

// vars/npmPipeline.groovy
def call(Map config = [:]) {
    pipeline {
        agent any
        stages {
            stage('Install') {
                steps {
                    sh 'npm ci'
                }
            }
            stage('Test') {
                steps {
                    sh 'npm test'
                }
            }
            stage('Build') {
                steps {
                    sh 'npm run build'
                }
            }
        }
    }
}

Utilisez-la dans un Jenkinsfile :

@Library('my-shared-lib') _

npmPipeline(nodeVersion: '20')

Tests automatisés dans les pipelines​

Tests unitaires​

- name: Run unit tests
  run: npm run test:unit -- --reporter=junit --outputFile=reports/junit.xml

Publiez les résultats dans GitHub Actions :

- name: Publish test results
  uses: dorny/test-reporter@v1
  if: always()
  with:
    name: Unit Tests
    path: reports/junit.xml
    reporter: java-junit

Tests d'intégration​

Exécutez des tests d'intégration contre un conteneur de service de base de données :

jobs:
  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
          POSTGRES_DB: app_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:test@localhost:5432/app_test
astuce

Les conteneurs de service dans GitHub Actions fournissent des bases de données jetables pour les tests d'intégration. Incluez toujours des vérifications de santé (--health-cmd) pour que vos tests ne commencent pas avant que la base de données soit prête.

Tests de bout en bout​

Exécutez les tests E2E Playwright en CI :

e2e:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - run: npm ci
    - name: Install Playwright browsers
      run: npx playwright install --with-deps
    - name: Run E2E tests
      run: npx playwright test
    - name: Upload report
      if: always()
      uses: actions/upload-artifact@v4
      with:
        name: playwright-report
        path: playwright-report/

Analyse de sécurité​

Ajoutez l'analyse des dépendances et du code :

- name: Run audit
  run: npm audit --audit-level=high

- name: CodeQL analysis
  uses: github/codeql-action/init@v3
  with:
    languages: javascript-typescript

- name: Perform analysis
  uses: github/codeql-action/analyze@v3

- name: Trivy container scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: app:latest
    severity: CRITICAL,HIGH

Configuration de pipeline assistée par IA​

Génération de workflows à partir de prompts​

L'IA de Cursor génère des fichiers de pipeline complets à partir de descriptions. Ouvrez Ctrl+K dans un nouveau fichier .yml et saisissez :

Create a GitHub Actions workflow that: runs on push to main and on PRs,
sets up Node 20, installs dependencies with npm ci, runs lint, type-check,
and tests with coverage, builds a Docker image, pushes it to GitHub
Container Registry, and deploys to a Kubernetes cluster using kubectl.
Use caching and environment protections.

Cursor produit un workflow complet et valide. Vérifiez les permissions et les secrets, puis affinez en demandant des tests matriciels ou des notifications Slack.

astuce

Lorsque vous saisissez des prompts pour la configuration CI/CD, spécifiez la plateforme et la version exactes. « GitHub Actions avec Node 20 et Docker buildx » produit une bien meilleure sortie que « un pipeline CI pour mon application Node ».

Optimisation des pipelines existants​

Cursor peut analyser et optimiser les pipelines lents. Sélectionnez le fichier de workflow et saisissez :

Analyze this GitHub Actions workflow and suggest optimizations to reduce
runtime. Identify: missing cache opportunities, jobs that could run in
parallel, oversized images, and unnecessary steps.

Optimisations courantes suggérées par l'IA :

  • Ajouter la mise en cache des dépendances.
  • Diviser lint, test et build en jobs parallèles.
  • Utiliser la mise en cache des couches Docker.
  • Annuler les exécutions obsolètes pour la même branche.

Génération de tests de pipeline​

Utilisez act pour exécuter GitHub Actions localement avant de pousser :

# Install act
brew install act

# Run a specific workflow locally
act -j test -W .github/workflows/ci.yml

Prompt Cursor : « Génère un ensemble d'événements de test et de secrets simulés pour exécuter ce workflow localement avec act. »

Gestion des secrets​

Secrets GitHub Actions​

Stockez les secrets dans les paramètres du dépôt ou de l'environnement, jamais dans le code :

- name: Deploy
  env:
    API_KEY: ${{ secrets.API_KEY }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
  run: ./deploy.sh
attention

GitHub masque les valeurs de secret dans les logs, mais la journalisation structurée peut les faire fuir si un secret apparaît comme partie d'une chaîne plus grande. Évitez de journaliser les corps de requête complets pouvant contenir des jetons, et utilisez le contexte secrets uniquement dans env ou with — jamais dans les scripts run où ils pourraient être affichés.

Variables GitLab CI​

deploy:
  variables:
    DATABASE_URL: $CI_DATABASE_URL
  script:
    - ./deploy.sh

Marquez les variables comme « masquées » et « protégées » dans l'interface GitLab pour qu'elles n'apparaissent que dans les branches protégées.

Identifiants Jenkins​

Utilisez le Credentials Store au lieu des variables d'environnement :

withCredentials([string(credentialsId: 'api-key', variable: 'API_KEY')]) {
    sh './deploy.sh'
}

Bonnes pratiques CI/CD dans Cursor​

Garder les pipelines rapides​

  • Mettre en cache les dépendances et les sorties de build.
  • Exécuter les jobs indépendants en parallèle.
  • Utiliser la mise en cache des couches Docker pour les builds d'images.
  • Annuler les exécutions en cours lorsqu'un nouveau commit est poussé.
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Échouer vite et fort​

  • Exécuter lint et type-check avant les tests.
  • Utiliser fail-fast: true sur les jobs matriciels où un échec invalide les autres.
  • Envoyer des notifications en cas d'échec (Slack, email, Teams).

Épingler les versions d'actions​

# À ÉVITER — latest peut casser inopinément
- uses: actions/checkout@v4

# PRÉFÉRER — épingler à un SHA de commit pour la reproductibilité
- uses: actions/[email protected]
astuce

Épinglez les actions tierces à un SHA de commit complet, pas un tag. Les tags peuvent être déplacés par les mainteneurs, ce qui constitue un risque de sécurité de la chaîne d'approvisionnement. L'épinglage SHA garantit le code exact qui s'exécute.

Utiliser les Environments pour la promotion​

Les GitHub Environments fournissent des règles de protection, des relecteurs requis et le suivi des déploiements :

deploy:staging:
  environment: staging

deploy:production:
  needs: deploy:staging
  environment:
    name: production
    url: https://app.example.com

Débogage des pipelines​

Réexécuter les jobs échoués​

GitHub Actions permet de réexécuter uniquement les jobs échoués, économisant du temps et des ressources :

gh run rerun <run-id> --failed

Activer la journalisation de débogage​

- name: Debug step
  env:
    ACTIONS_STEP_DEBUG: true
  run: echo "Detailed logs enabled"

Définissez le secret de dépôt ACTIONS_STEP_DEBUG à true pour des logs détaillés du runner.

Valider le YAML localement​

Utilisez l'extension YAML de Cursor pour valider la syntaxe pendant la saisie. Pour une validation plus approfondie, utilisez actionlint :

brew install actionlint
actionlint .github/workflows/*.yml
astuce

Cursor peut exécuter actionlint à la sauvegarde avec une configuration de tâches. Ajoutez une entrée .vscode/tasks.json qui exécute actionlint sur le fichier courant et affiche les erreurs dans le panneau Problèmes.

Pièges courants et comment les éviter​

Caches périmés​

Un cache qui ne s'invalide jamais peut masquer les changements de dépendances. Incluez toujours le hachage du lockfile dans la clé :

key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}

Croissance illimitée des jobs​

Sans rotation des logs, les anciens builds s'accumulent. Configurez la rétention :

# GitHub : configurer dans les paramètres du dépôt
# Jenkins :
options {
    buildDiscarder(logRotator(numToKeepStr: '20'))
}

Oubli de if: always() sur les artefacts​

Les artefacts d'un job échoué ne sont pas téléchargés par défaut. Ajoutez if: always() pour capturer les rapports de test et la couverture même en cas d'échec.

attention

Attention aux if: always() sur les étapes de déploiement — vous ne voulez pas déployer après un test échoué. Utilisez des conditions spécifiques comme if: success() && github.ref == 'refs/heads/main'.

Secrets dans les logs​

Ne echo jamais les secrets. Même masqués, des fuites partielles se produisent lorsque les secrets sont des sous-chaînes d'autres sorties. Utilisez des outils d'analyse de secrets et examinez manuellement les logs lors du premier déploiement.

Résumé​

Cursor est un éditeur puissant pour créer et maintenir des pipelines CI/CD sur GitHub Actions, GitLab CI et Jenkins. L'extension YAML fournit la validation de schéma, les conteneurs de service permettent les tests d'intégration, et l'assistant IA génère, optimise et débogue les configurations de pipeline à partir de prompts en langage naturel. Commencez par scaffolder un workflow CI, ajoutez des tests automatisés et des analyses de sécurité, et laissez l'IA de Cursor gérer la configuration répétitive pendant que vous vous concentrez sur la livraison de déploiements fiables, rapides et sécurisés.