Concept de CI/CD (Integration Continue / Déploiement Continu)

Introduction

Très utile de nos jours dans le développement logiciel, le CI/CD est une pratique qui vise à automatiser et améliorer le processus de livraison des applications. CI/CD permet aux équipes de développement de livrer des modifications de code plus fréquemment et de manière plus fiable. Par cette automatisation, il sera possible par exemple d'ajouter des tests, de vérifier la qualité du code, et de déployer les applications plus rapidement. On peut assurer ainsi la non-regression du code, c'est-à-dire que les nouvelles modifications n'introduisent pas de bugs ou de problèmes dans l'application existante.

Importance dans le contexte du logiciel libre

Dans le contexte du logiciel libre, s'assurer de la non-regression est crucial pour maintenir la qualité et la fiabilité du logiciel. Les projets de logiciel libre sont souvent développés par des communautés distribuées, où de nombreux contributeurs peuvent apporter des modifications au code. Le CI/CD permet de gérer efficacement ces contributions en automatisant les tests et les validations, assurant ainsi que chaque modification respecte les normes de qualité établies.

Jumeler au principe de pull request (merge request), cela permet de vérifier automatiquement chaque contribution afin qu'elle respecte différentes règles avant qu'elle ne soit intégrée dans la branche principale du projet.

Sans cela, les administrateurs de projet devraient manuellement vérifier chaque contribution, ce qui peut être fastidieux et sujet à des erreurs humaines.

Ce qu'il est possible de faire avec CI/CD

Voici quelques exemples de ce qu'il est possible de faire avec CI/CD :

• Tests automatisés : Exécuter des tests unitaires, des tests de non-regression. (IMPORTANT)
• Compilation du projet : Si necessaire, compiler le code source pour s'assurer qu'il n'y a pas d'erreurs de compilation.(IMPORTANT)
• Implémentation de linters : Analyser le code pour s'assurer qu'il respecte les normes de codage établies.(OPTIONNEL)
• Implémentation de systemes métriques : Evalue la performence du code, la couverture de test, etc.(OPTIONNEL)
• Déploiement automatisé : Déployer automatiquement l'application vers des environnements de test ou de production après chaque modification validée.(OPTIONNEL)

Il existe également plusieurs autres applications possibles au ci/cd, mais celles-ci sont les plus courantes.

Logiciels et technologies utilisés pour le CI/CD

Services d'intégration continue

Voici une liste de quelques services couramment utilisés pour le CI/CD :

• GitHub Actions : Service d'intégration continue intégré à GitHub
• GitLab CI/CD : Service d'intégration continue intégré à GitLab
• Travis CI : Service d'intégration continue populaire pour les projets open source
• Azure DevOps : Service d'intégration continue et de déploiement continu de Microsoft

A notée qu'il y en existe d'autre mais ceux-ci sont les plus populaires.

Docker et conteneurisation

Docker est une plateforme de conteneurisation qui permet d'emballer une application et ses dépendances dans un conteneur léger et portable. Dans le contexte du CI/CD, Docker est souvent utilisé pour créer des environnements de test cohérents et reproductibles. En utilisant des conteneurs Docker, les équipes de développement peuvent s'assurer que les tests sont exécutés dans un environnement identique à celui de la production, réduisant ainsi les problèmes liés aux différences d'environnement.^[1]

L'utilisation se fait via l'invite de commande (CLI) et le logiciel va intéragir avec des images (images Docker) qui sont des modèles pour créer des conteneurs. Ces images peuvent être créées à partir de fichiers de configuration appelés Dockerfile, qui définissent les étapes nécessaires pour construire l'image.

Exemple de dockerfile simple pour une application Node.js :

# Utiliser une image de base officielle de Node.js
FROM node:18
# Définir le répertoire de travail dans le conteneur
WORKDIR /app
# Copier les fichiers package.json et package-lock.json dans le conteneur
COPY package*.json ./
# Installer les dépendances de l'application
RUN npm install
# Copier le reste des fichiers de l'application dans le conteneur
COPY . .
# Exposer le port sur lequel l'application va s'exécuter
EXPOSE 3000
# Définir la commande pour démarrer l'application
CMD ["node", "server.js"]

Pour une utilisation plus simplifier, il est possible d'utiliser l'outil "docker-desktop" qui offre une interface graphique pour gérer les conteneurs et les images Docker.

Cependant, celle-ci s'avère payante dans un contexte d'entreprise.

Puisque nous sommes dans un cours utilisant du logiciel libre, si vous souhaiter effectuer des tests et utiliser une technologie comme celle la dans votre projet, je vous conseille d'utiliser Podman, qui est une alternative open source à Docker. Podman offre des fonctionnalités similaires à Docker, mais avec une architecture sans deamon, ce qui le rend plus sécurisé et plus facile à utiliser dans certains contextes. De plus, podman-desktop est également disponible en tant qu'interface graphique pour gérer les conteneurs et les images Podman.^[2]

Configuration sur Github Actions

Pour configurer un workflow CI/CD sur GitHub Actions, vous devez créer un fichier YAML dans le répertoire .github/workflows/ de votre dépôt. À titre d'exemple, voici le fichier yml que j'ai utilisé pour déployer ce site sur githuh pages:

name: Deploy VitePress site to Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup Bun
        uses: oven-sh/setup-bun@v1
        with:
          bun-version: latest

      - name: Setup Pages
        uses: actions/configure-pages@v4

      - name: Install dependencies
        run: bun install

      - name: Build with VitePress
        run: bun run docs:build

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: docs/.vitepress/dist

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Plusieurs éléments intéressant se passe dans ce fichier:

• Le workflow est déclenché à chaque fois qu'il y a un push sur la branche main.
• Le job build s'exécute sur une machine virtuelle Ubuntu.
• Les étapes incluent le checkout du code, l'installation de Bun, l'installation des dépendances, la construction du site avec VitePress, et le téléchargement de l'artifact.
• Le job deploy dépend du job build et déploie le site sur GitHub Pages.

Il est evident que chaques projets auront des besoins différents, il faut pouvoir s'adapter et adapter nos ressources en conséquences.

Pour ce qui est du fonctionnement sur gitlab, le principe est similaire.

---

1. Source: https://www.docker.com/ ↩︎

2. Source: https://podman.io/ ↩︎