Tester c&#est tricher, compiler c&#est douter

Cet article explore le concept, les avantages, les inconvénients et un exemple de démonstration de l'intégration continue (CI).

Revue historique

Tout d’abord, jetons un bref coup d’œil à l’histoire.

En 1999, Kent Beck a exploré ce sujet en profondeur dans son premier livre sur l'Extreme Programming. En 2001, CruiseControl, l'un des premiers outils CI open source, est né.

Pourquoi utiliser CI ?

L'objectif de CI est d'exécuter des tests automatisés après chaque validation de code. Cela garantit que le code reste toujours fonctionnel. Nous appelons cela intégration continue car chaque fois que le code est modifié, il est vérifié pour garantir qu'aucun problème de régression ne se produit.

Avantages

• Détectez les erreurs le plus tôt possible : Les problèmes sont identifiés rapidement, ce qui permet d'apporter des réponses rapides.
• Amélioration de la qualité : Des tests systématiques garantissent un code plus robuste.
• Gain de temps : Les pipelines automatisés réduisent le besoin de tests manuels répétitifs.

Inconvénients

• Coût initial : La mise en place de CI peut nécessiter un investissement initial et une expertise importants.
• Temps d'exécution : Les pipelines complexes peuvent prolonger le temps nécessaire aux développeurs pour vérifier leur code.

Comment ça marche

Avant de comprendre comment cela fonctionne, comprenons quelques termes :

• Jobs : Une instance d'un conteneur (généralement Docker) utilisée pour exécuter des scripts. Cela peut inclure des commandes, des tests ou des opérations simples telles que l'écho.
• Pipeline : Une série de jobs organisés en séquence ou en parallèle. Chaque commit déclenche cette série d'actions pour valider les modifications.

Le principe est simple : chaque job renvoie un code de statut (succès ou échec). Si une tâche échoue, le pipeline s'arrêtera ou ignorera les étapes suivantes en fonction de la configuration.

Perceuse pratique

Nous utiliserons des exemples basés sur GitLab CI. Peut être configuré via des fichiers .gitlab-ci.yml.

Exemple de base

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Compiler les drapeaux

Ajouter des drapeaux de compilation, il existe deux méthodes :

1. Passez les règles dans Makefile.
2. Passez les indicateurs directement dans les commandes CI.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

Utilisation de Criterion pour les tests et le signalement

Criterion est une bibliothèque de tests unitaires en langage C.

Installation des critères

Avant d'utiliser Criterion pour les tests, vous devez installer Criterion.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

Construction en plusieurs étapes

Divisez les tests unitaires et les tests fonctionnels en plusieurs phases, vous pouvez :

• Mieux organisé
• Meilleure vue des résultats

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

Utilisez Clang pour formater le code

Le formatage du code est crucial pour maintenir une base de code propre.

<code>image: alpine:latest

myjobname:
  script:
    - make</code>

Cache

Dans certains cas, il est utile de mettre en cache des fichiers ou des dossiers pour éviter de les recharger à chaque fois que le pipeline est exécuté.

Un exemple courant est le dossier node_modules/ en JavaScript.

<code>myjobname_hard:
  script:
    - CFLAGS="-Wall -Werror" make
    # 或者
    - make compile_flags</code>

Bien entendu, vous pouvez utiliser des options supplémentaires dans la configuration du pipeline pour vider le cache si nécessaire.

Artefact

Les artefacts sont des fichiers générés par CI qui peuvent être partagés ou téléchargés entre les tâches.

Par exemple, des rapports de tests ou de couverture.

<code>before_script:
  - apt-get update && apt-get install -y libcriterion-dev
script:
  - ./configure
  - make test</code>

Couverture des tests

La couverture des tests peut être mesurée en intégrant des outils comme gcovr ou Cobertura dans votre pipeline CI.

<code>stages:
  - build
  - test

build:
  stage: build
  script:
    - make all

test-unit:
  stage: test
  script:
    - make unit-test

test-functional:
  stage: test
  script:
    - make functional-test</code>

Rapport

Ce bloc de code vous permet d'intégrer le reporting de couverture dans vos demandes de fusion afin que vous puissiez voir le code qui n'est pas couvert ainsi que le pourcentage de couverture.

<code>clang_format:
  stage: format
  before_script:
    - apt-get -qq update && apt-get -qq install -y clang-format autotools-dev autoconf-archive gcovr libcriterion-dev
  script:
    - clang-format -i $(find src/ -type f -name "*.c") --dry-run --Werror</code>

Environnement personnalisé

Vous pouvez spécifier l'environnement de base pour CI en sélectionnant une image Docker spécifique.

<code>cache:
  paths:
    - node_modules/

install:
  script:
    - npm install</code>

En combinant le contenu ci-dessus, vous pouvez obtenir l'exemple suivant :

<code>artifacts:
  paths:
    - build/
    - reports/</code>

Notez que le fichier .h est manquant et before_script est manquant.

Suppléments supplémentaires

Vous pouvez également rechercher les fichiers indésirables pour vous assurer que make clean fonctionne correctement.

<code>test-coverage:
  stage: test
  script:
    - gcovr --html --html-details -o coverage.html
  artifacts:
    paths:
      - coverage.html</code>

Résumé

L'intégration continue est un outil extrêmement puissant. Même si sa mise en place peut être difficile, les avantages sont énormes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!