CI/CD
Comme nous l’avons vu, les tests doivent être déclenchés automatiquement à chaque push ou merge, via GitLab CI, GitHub Actions, Jenkins ou autre pour maintenir correctement ses tests automatisés sur le long terme.
Concevoir une pipeline
Une chaîne CI/CD efficace suit un découpage par étapes indépendantes :
– Build & static scan : compilation, linters, SCA.
– Tests unitaires parallélisés : exécution en multi-processus afin d’obtenir un premier retour en moins de deux minutes.
– Packaging / Artefacts : images OCI, paquets NPM, libraries Maven.
– Tests d’intégration & e2e : Cypress ou Playwright sur un Selenium Grid ou un provider cloud (BrowserStack, Sauce Labs).
– Analyse de couverture & mutation.
– Vérifications de sécurité (SAST, secrets scan, IaC).
Raccourcir le feedback grâce au Test Impact Analysis (TIA)
L’exécution exhaustive de milliers de tests à chaque commit devient vite prohibitive. Le TIA identifie, via la couverture et la dépendance de code, le sous-ensemble significatif de scénarios à relancer. Les gains constatés peuvent allé jusqu’à presque 50 % de temps économisé sur la fenêtre build-test. Azure Pipelines propose la case “Run only impacted tests” depuis la version 2 du Visual Studio Test task, sans configuration supplémentaire.
Vous pouvez le voir la page blog de https://devblogs.microsoft.com/devops/accelerated-continuous-testing-with-test-impact-analysis-part-2/
console.log( 'Code is Poetry' );
Nous allons créer un fichier GitHub Actions qui se déclenche :
- lors d’un push sur main, ou,
- à chaque pull-request, tous les jours à 21 h (heure de Paris) ou,
- via le bouton Run workflow
Veillez cependant, à ne jamais lancer deux exécutions simultanées sur la même branche.
Une fois démarré, le script installe les dépendances Node 20, exécute nos tests Cypress dans le navigateur demandé (sans passer par Cypress Cloud) puis archive automatiquement les vidéos, captures d’écran et rapports générés.
Secrets ou variables :
Vous pouvez utiliser des variables et des secrets. Ce n’est pas le cas dans l’exemple que nous avons crée.
Cependant, se peut être votre besoin si vous avez Cypress Cloud pour exécuter vos tests en parallèle et y mettre votre clé Cypress Cloud.
Le code sera donc :
- name: Run Cypress
uses: cypress-io/github-action@v6.8.0
with:
record: true
parallel: true
browser: ${{ inputs.browser ||'chrome' }}
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
SAUCE_USERNAME: ${{ secrets.SAUCE_USERNAME }}
SAUCE_ACCESS_KEY: ${{ secrets.SAUCE_ACCESS_KEY }}
Créez un fichier ci.yml dans le dossier .github/workflows :
name: CI
on:
push:
branches: [main] pull_request: # pipeline à chaque commit sur main
# pipeline pour chaque PR (toutes branches)
schedule:
- cron:
'0 19 * * *' # 21 h CEST
workflow_dispatch:
inputs:
browser:
description:
required: false
default:
"chrome"
"Navigateur : chrome, firefox, edge…
"
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
jobs:
cypress-run:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node 20
uses: actions/setup-node@v4
with:
node-version: 20
cache:
'npm'
- name: Install dependencies
run: npm ci
- name: Run Cypress
uses: cypress-io/github-action@v6.8.0
with:
browser: ${{ inputs.browser || 'chrome' }}
- name: Upload artefacts (vidéos, screenshots)
if: always()
uses: actions/upload-artifact@v4
with:
name: cypress-artifacts
path: |
cypress/videos
cypress/screenshots
cypress/results
Le Digital Operational Resilience Act (DORA)
Après un premier run (ici 52…), le résultat est :
– 3 tests sont ok
– 1 est en échec (c’est attendu, c’est l’anomalie que nous attendions)
– les tests ont duré 12,292s
Si vous cliquez sur les artifacts, vous allez télécharger un zip qui contient toutes les copies d’écrans des tests en échec. Ici :
