đ Retour au Sommaire
JusquâĂ prĂ©sent, nous avons appris Ă crĂ©er, configurer et utiliser des DevContainers. Mais leur vĂ©ritable puissance se rĂ©vĂšle quand ils deviennent la source de vĂ©ritĂ© (Single Source of Truth) pour lâenvironnement de dĂ©veloppement de votre projet.
Quâest-ce que cela signifie ?
Le DevContainer ne doit pas ĂȘtre simplement « un outil pratique ». Il doit ĂȘtre LA rĂ©fĂ©rence officielle qui dĂ©finit :
Analogie : Imaginez une recette de cuisine. Si chaque cuisinier a sa propre version de la recette, les plats seront tous diffĂ©rents. Mais si tout le monde suit la mĂȘme recette officielle, le rĂ©sultat sera identique. Le DevContainer est cette recette officielle pour votre environnement de dĂ©veloppement.
La dérive de configuration (configuration drift) se produit quand les environnements divergent au fil du temps.
Exemple typique :
Jour 1 : Tout le monde a GCC 11.2
â
Jour 30 : Alice met Ă jour vers GCC 11.4
â
Jour 60 : Bob installe GCC 12 pour tester quelque chose
â
Jour 90 : Le serveur CI utilise toujours GCC 11.2
â
Jour 120 : "Ăa marche chez moi !" đ±
| ProblÚme | Conséquence |
|---|---|
| Versions diffĂ©rentes des outils | Bugs qui apparaissent/disparaissent selon lâenvironnement |
| Configurations différentes | Comportements incohérents |
| BibliothÚques manquantes | « Works on my machine » |
| Documentation obsolÚte | Nouveaux développeurs perdus |
| CI différente du dev local | Erreurs surprises en intégration |
Avec un DevContainer comme source de vérité :
Jour 1 â Jour 1000 :
Tout le monde utilise EXACTEMENT le mĂȘme environnement
défini dans devcontainer.json
Le DevContainer Ă©limine la dĂ©rive car lâenvironnement est :
Le principe SSOT stipule quâune information ne doit ĂȘtre dĂ©finie quâĂ un seul endroit. Toutes les utilisations de cette information doivent rĂ©fĂ©rencer cette source unique.
Appliqué aux DevContainers :
âââââââââââââââââââââââââââââââ
â devcontainer.json â
â (Source de vĂ©ritĂ©) â
âââââââââââââââŹââââââââââââââââ
â
âââââââââââââââââââââââŒââââââââââââââââââââââ
â â â
⌠⌠âŒ
âââââââââââââââââ âââââââââââââââââ âââââââââââââââââ
â DĂ©veloppeur â â DĂ©veloppeur â â CI/CD â
â Alice â â Bob â â Pipeline â
âââââââââââââââââ âââââââââââââââââ âââââââââââââââââ
â â â
âââââââââââââââââââââââŽââââââââââââââââââââââ
â
âââââââââââââââŒââââââââââââââââ
â MĂȘme environnement â
â pour TOUT LE MONDE â
âââââââââââââââââââââââââââââââ
Le devcontainer.json devient la spécification officielle de :
{
// SYSTĂME D'EXPLOITATION OFFICIEL
"image": "mcr.microsoft.com/devcontainers/cpp:ubuntu-22.04",
// OUTILS OFFICIELS ET LEURS VERSIONS
"postCreateCommand": "apt-get update && apt-get install -y gcc-11 valgrind cmake",
// CONFIGURATION OFFICIELLE
"remoteEnv": {
"CC": "gcc-11",
"CFLAGS": "-Wall -Wextra -std=c17"
},
// EXTENSIONS OFFICIELLES
"customizations": {
"vscode": {
"extensions": ["ms-vscode.cpptools"]
}
}
}
Tout ce qui nâest pas dans ce fichier nâest pas officiel.
Sans source de vérité :
DĂ©veloppeur local CI/CD (serveur)
âââââââââââââââââ ââââââââââââââââ
Ubuntu 22.04 Ubuntu 20.04 â DiffĂ©rent !
GCC 11.4 GCC 9.4 â DiffĂ©rent !
CMake 3.22 CMake 3.16 â DiffĂ©rent !
Valgrind 3.18 Valgrind 3.15 â DiffĂ©rent !
RĂ©sultat : "Ăa passe en local mais Ă©choue en CI" đ
Avec le DevContainer comme source de vérité :
DĂ©veloppeur local CI/CD (serveur)
âââââââââââââââââ ââââââââââââââââ
DevContainer MĂȘme image Docker
â â
âââââââââââââŹââââââââââââââââ
â
MĂȘme environnement
Ubuntu 22.04
GCC 11.4
CMake 3.22
Valgrind 3.18
RĂ©sultat : "Ăa passe en local = Ăa passe en CI" â
Extrayez lâimage du devcontainer.json et utilisez-la dans votre CI.
devcontainer.json :
{
"image": "mcr.microsoft.com/devcontainers/cpp:ubuntu-22.04"
}
GitHub Actions (.github/workflows/build.yml) :
name: Build and Test
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/devcontainers/cpp:ubuntu-22.04 # MĂȘme image !
steps:
- uses: actions/checkout@v4
- name: Install additional tools
run: apt-get update && apt-get install -y valgrind
- name: Configure
run: cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
- name: Build
run: cmake --build build
- name: Test
run: cd build && ctest --output-on-failure
- name: Valgrind
run: valgrind --leak-check=full --error-exitcode=1 ./build/mon_programme
Si vous avez un Dockerfile personnalisé :
.devcontainer/Dockerfile :
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y \
build-essential \
gcc-11 \
cmake \
gdb \
valgrind \
&& rm -rf /var/lib/apt/lists/*
ENV CC=gcc-11
ENV CFLAGS="-Wall -Wextra -std=c17"
GitHub Actions :
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build DevContainer image
run: docker build -t projet-c-dev .devcontainer/
- name: Run tests in container
run: |
docker run --rm -v ${{ github.workspace }}:/workspace -w /workspace projet-c-dev \
bash -c "cmake -B build && cmake --build build && cd build && ctest"
GitHub propose une action officielle pour utiliser les DevContainers en CI :
name: Build with DevContainer
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build and test in DevContainer
uses: devcontainers/ci@v0.3
with:
runCmd: |
cmake -S . -B build
cmake --build build
cd build && ctest --output-on-failure
Cette action :
devcontainer.jsonCâest la mĂ©thode la plus fidĂšle car elle utilise exactement votre configuration DevContainer.
Voici un projet complet oĂč le DevContainer est la source de vĂ©ritĂ©.
mon-projet-c/
âââ .devcontainer/
â âââ devcontainer.json # Source de vĂ©ritĂ©
â âââ Dockerfile # Image personnalisĂ©e (optionnel)
âââ .github/
â âââ workflows/
â âââ ci.yml # CI utilisant le DevContainer
âââ .vscode/
â âââ tasks.json
â âââ launch.json
â âââ c_cpp_properties.json
âââ src/
â âââ main.c
âââ include/
âââ tests/
âââ CMakeLists.txt
âââ README.md
âââ ENVIRONMENT.md # Documentation de l'environnement
{
"name": "Projet C - Environnement Officiel",
// === IMAGE DE BASE ===
// Cette image définit l'OS et les outils de base
// Toute modification doit ĂȘtre approuvĂ©e par l'Ă©quipe
"image": "mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04",
// === OUTILS ADDITIONNELS ===
// Liste officielle des outils requis pour le projet
"postCreateCommand": "bash .devcontainer/setup.sh",
// === CONFIGURATION OFFICIELLE ===
"remoteEnv": {
"CC": "gcc",
"CXX": "g++",
"CFLAGS": "-Wall -Wextra -Werror -std=c17",
"CMAKE_BUILD_TYPE": "Debug"
},
// === EXTENSIONS OFFICIELLES ===
"customizations": {
"vscode": {
"extensions": [
"ms-vscode.cpptools",
"ms-vscode.cmake-tools",
"usernamehw.errorlens"
],
"settings": {
"C_Cpp.default.cStandard": "c17",
"cmake.configureOnOpen": true
}
}
},
// === OPTIONS DOCKER ===
"runArgs": [
"--cap-add=SYS_PTRACE",
"--security-opt", "seccomp=unconfined"
],
"remoteUser": "vscode"
}
#!/bin/bash
# Script d'installation officiel
# Ce script définit les outils supplémentaires requis
set -e
echo "=== Installation de l'environnement officiel ==="
# Mise Ă jour des paquets
sudo apt-get update
# Outils officiels du projet
sudo apt-get install -y \
valgrind \
clang-format \
cppcheck \
lcov
# Nettoyage
sudo apt-get clean
sudo rm -rf /var/lib/apt/lists/*
# VĂ©rification
echo ""
echo "=== VĂ©rification des outils ==="
echo "GCC: $(gcc --version | head -1)"
echo "CMake: $(cmake --version | head -1)"
echo "Valgrind: $(valgrind --version)"
echo "clang-format: $(clang-format --version)"
echo ""
echo "â Environnement officiel installĂ© avec succĂšs"
name: CI Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
env:
BUILD_TYPE: Debug
jobs:
# ============================================
# BUILD ET TESTS - Utilise le mĂȘme environnement que le DevContainer
# ============================================
build-and-test:
name: Build and Test
runs-on: ubuntu-latest
# Utilise la MĂME image que le DevContainer
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Install project tools
run: bash .devcontainer/setup.sh
- name: Configure CMake
run: cmake -S . -B build -DCMAKE_BUILD_TYPE=${{ env.BUILD_TYPE }}
- name: Build
run: cmake --build build --parallel
- name: Run tests
run: cd build && ctest --output-on-failure
# ============================================
# ANALYSE MĂMOIRE - MĂȘme environnement
# ============================================
memory-check:
name: Memory Check (Valgrind)
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Install tools
run: bash .devcontainer/setup.sh
- name: Build
run: cmake -S . -B build && cmake --build build
- name: Valgrind check
run: |
valgrind --leak-check=full \
--show-leak-kinds=all \
--error-exitcode=1 \
./build/mon_programme
# ============================================
# ANALYSE STATIQUE - MĂȘme environnement
# ============================================
static-analysis:
name: Static Analysis
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Install tools
run: bash .devcontainer/setup.sh
- name: Run cppcheck
run: cppcheck --enable=all --error-exitcode=1 --std=c17 src/
# ============================================
# VĂRIFICATION DU FORMAT - MĂȘme environnement
# ============================================
format-check:
name: Format Check
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Install tools
run: bash .devcontainer/setup.sh
- name: Check formatting
run: |
find src include -name "*.c" -o -name "*.h" | \
xargs clang-format --dry-run --Werror
Documentez lâenvironnement officiel :
# Environnement de DĂ©veloppement Officiel
Ce document décrit l'environnement de développement officiel du projet.
## Source de Vérité
L'environnement est défini dans `.devcontainer/devcontainer.json`.
**Ce fichier fait autorité** pour toutes les questions d'environnement.
## Spécifications Officielles
| Composant | Version | Justification |
|-----------|---------|---------------|
| OS | Ubuntu 22.04 LTS | Support long terme, stabilité |
| GCC | 11.x | Version LTS Ubuntu, support C17 complet |
| CMake | 3.22+ | Fonctionnalités modernes requises |
| Valgrind | 3.18+ | Détection mémoire précise |
| clang-format | 14+ | Formatage cohérent |
| Standard C | C17 | Norme stable et moderne |
## Flags de Compilation Officiels
### Mode Debug (développement)
-Wall -Wextra -Werror -std=c17 -g -O0
### Mode Release (production)
-Wall -Wextra -std=c17 -O2 -DNDEBUG
## Comment Utiliser
### DĂ©veloppement Local
1. Ouvrir le projet dans VS Code
2. Cliquer "Reopen in Container"
3. L'environnement officiel est automatiquement configuré
### CI/CD
La CI utilise la mĂȘme image Docker que le DevContainer.
Ce qui passe localement passera en CI (et vice versa).
## Modifications de l'Environnement
Pour modifier l'environnement officiel :
1. Créer une issue expliquant le besoin
2. Proposer une PR modifiant `devcontainer.json`
3. Tester localement (rebuild container)
4. Obtenir l'approbation de l'Ă©quipe
5. Merger et communiquer le changement
**Ne jamais modifier l'environnement sans suivre ce processus.**
## Historique des Changements
| Date | Changement | Raison |
|------|------------|--------|
| 2025-01-01 | Création initiale | - |
| 2025-02-15 | Ajout Valgrind | Détection fuites mémoire |
| 2025-03-01 | GCC 11 â explicite | CohĂ©rence CI |
Bien que le DevContainer Ă©volue avec le code, vous pouvez ajouter un versionnement explicite :
{
"name": "Projet C - Env v2.1.0",
// Commentaire de version
// v2.1.0 - Ajout de cppcheck
// v2.0.0 - Migration vers Ubuntu 22.04
// v1.0.0 - Configuration initiale
"image": "..."
}
Maintenez un changelog dédié :
.devcontainer/CHANGELOG.md :
# Changelog de l'environnement
## [2.1.0] - 2025-03-15
### Ajouté
- cppcheck pour l'analyse statique
- lcov pour la couverture de code
## [2.0.0] - 2025-02-01
### Modifié
- Migration Ubuntu 20.04 â 22.04
- GCC 9 â GCC 11
### â ïž Breaking Change
- NĂ©cessite rebuild complet du conteneur
## [1.1.0] - 2025-01-15
### Ajouté
- Valgrind pour l'analyse mémoire
## [1.0.0] - 2025-01-01
### Initial
- Ubuntu 20.04
- GCC 9
- CMake 3.16
Pour les changements majeurs dâenvironnement :
# AprĂšs une mise Ă jour majeure du DevContainer
git tag -a env-v2.0.0 -m "Environment upgrade: Ubuntu 22.04, GCC 11"
git push origin env-v2.0.0
Bien :
{
"postCreateCommand": "bash .devcontainer/setup.sh"
}
# .devcontainer/setup.sh
#!/bin/bash
# Script centralisé, facile à maintenir et à réutiliser en CI
sudo apt-get update
sudo apt-get install -y valgrind cppcheck
Moins bien :
{
"postCreateCommand": "apt-get update && apt-get install -y valgrind && apt-get install -y cppcheck && ..."
}
Bien :
{
"remoteEnv": {
// Compilateur C officiel
"CC": "gcc",
// Flags de compilation mode debug
"CFLAGS": "-Wall -Wextra -std=c17 -g",
// Variable utilisée par les scripts
"PROJECT_ENV": "development"
}
}
Bien :
{
"image": "mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04"
}
Risqué :
{
"image": "mcr.microsoft.com/devcontainers/cpp:latest"
}
Le tag latest peut changer et casser la reproductibilité.
{
// Outils OBLIGATOIRES (dans l'image de base)
"image": "mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04",
// Outils OBLIGATOIRES supplémentaires
"postCreateCommand": "bash .devcontainer/setup.sh",
// Extensions OBLIGATOIRES
"customizations": {
"vscode": {
"extensions": [
"ms-vscode.cpptools" // Obligatoire
]
}
}
}
Documentez clairement ce qui est obligatoire vs optionnel.
Mauvais :
# setup.sh
pip install requests # Quelle version ?
Bon :
pip install requests==2.28.0 # Version explicite
Mauvais :
"J'ai dû ajouter cette variable d'environnement pour que ça marche"
(mais ce n'est Ă©crit nulle part)
Bon :
Toute configuration nécessaire est dans devcontainer.json
ou documentée dans ENVIRONMENT.md
Mauvais :
# CI
container:
image: ubuntu:20.04 # Différent du DevContainer !
Bon :
# CI utilise la mĂȘme image
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04 # Identique !
Créez un fichier de configuration partagé :
.devcontainer/env-config.sh :
#!/bin/bash
# Configuration partagée entre DevContainer et CI
export ENV_VERSION="2.1.0"
export BASE_IMAGE="mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04"
export GCC_VERSION="11"
export CMAKE_MIN_VERSION="3.22"
export C_STANDARD="c17"
export CFLAGS="-Wall -Wextra -Werror -std=c17"
Utilisation dans setup.sh :
#!/bin/bash
source "$(dirname "$0")/env-config.sh"
echo "Installing environment v${ENV_VERSION}"
# ...
Utilisation dans CI :
steps:
- name: Load env config
run: source .devcontainer/env-config.sh && echo "ENV_VERSION=$ENV_VERSION" >> $GITHUB_ENV
Ajoutez un job CI qui vérifie la cohérence :
verify-environment:
name: Verify Environment Consistency
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check image consistency
run: |
# Extraire l'image du devcontainer.json
DEV_IMAGE=$(grep -o '"image":\s*"[^"]*"' .devcontainer/devcontainer.json | cut -d'"' -f4)
# VĂ©rifier que la CI utilise la mĂȘme
CI_IMAGE=$(grep -o 'image:\s*[^ ]*' .github/workflows/ci.yml | head -1 | awk '{print $2}')
if [ "$DEV_IMAGE" != "$CI_IMAGE" ]; then
echo "â ERREUR: Images diffĂ©rentes !"
echo "DevContainer: $DEV_IMAGE"
echo "CI: $CI_IMAGE"
exit 1
fi
echo "â Images identiques: $DEV_IMAGE"
Situation : Bob a besoin de GCC 12 pour tester une fonctionnalitĂ©, mais lâenvironnement officiel utilise GCC 11.
Solution 1 : DevContainer alternatif temporaire
Créez .devcontainer/experimental/devcontainer.json :
{
"name": "Expérimental - GCC 12",
"image": "ubuntu:22.04",
"postCreateCommand": "apt-get update && apt-get install -y gcc-12"
}
Pour lâutiliser : Ctrl+Shift+P â « Dev Containers: Open Folder in Container⊠» â SĂ©lectionner la configuration.
Ce DevContainer expĂ©rimental ne doit PAS ĂȘtre utilisĂ© pour le dĂ©veloppement normal.
Solution 2 : Installation locale temporaire
Dans le conteneur, Bob peut installer temporairement :
sudo apt-get install gcc-12
Cette modification disparaĂźtra au prochain rebuild du conteneur.
Solution 3 : Proposer une mise Ă jour officielle
Si GCC 12 est vraiment nécessaire, Bob doit proposer une PR pour mettre à jour le DevContainer officiel.
Si des exceptions sont autorisées, documentez-les :
## Exceptions Autorisées
### Extensions VS Code personnelles
Les développeurs peuvent installer des extensions personnelles.
Elles ne seront pas synchronisées avec l'équipe.
### ThÚmes et préférences visuelles
Libre choix (dans .vscode/settings.json local non commité).
### Outils de productivité personnels
Autorisé si ça n'affecte pas le build.
## Exceptions NON Autorisées
### Version du compilateur
NON. Doit ĂȘtre celle du DevContainer.
### Flags de compilation
NON. DĂ©finis dans devcontainer.json et CMakeLists.txt.
### BibliothĂšques du projet
NON. Toute dĂ©pendance doit ĂȘtre dans le DevContainer.
âââââââââââââââââââââââ
â 1. Identifier le â
â besoin â
ââââââââââââŹâââââââââââ
â
âŒ
âââââââââââââââââââââââ
â 2. CrĂ©er une issue â
â GitHub/GitLab â
ââââââââââââŹâââââââââââ
â
âŒ
âââââââââââââââââââââââ
â 3. Proposer une PR â
â avec les modifs â
ââââââââââââŹâââââââââââ
â
âŒ
âââââââââââââââââââââââ
â 4. Tester localementâ
â (rebuild) â
ââââââââââââŹâââââââââââ
â
âŒ
âââââââââââââââââââââââ
â 5. Review par â
â l'Ă©quipe â
ââââââââââââŹâââââââââââ
â
âŒ
âââââââââââââââââââââââ
â 6. Merge et â
â communication â
âââââââââââââââââââââââ
## Modification de l'environnement de développement
### Changement proposé
- [ ] Ajout d'outil
- [ ] Mise Ă jour de version
- [ ] Modification de configuration
- [ ] Suppression d'outil
### Description
[DĂ©crire le changement]
### Justification
[Pourquoi ce changement est nécessaire]
### Impact
- [ ] Breaking change (nécessite rebuild)
- [ ] Non-breaking (transparent)
### Tests effectués
- [ ] Rebuild du conteneur réussi
- [ ] Compilation du projet OK
- [ ] Tests passent
- [ ] CI passe
### Actions requises aprĂšs merge
- [ ] Tous les développeurs doivent rebuild leur conteneur
- [ ] Mise Ă jour de la documentation
- [ ] Communication Ă l'Ă©quipe
### Checklist
- [ ] devcontainer.json modifié
- [ ] CI mise à jour si nécessaire
- [ ] ENVIRONMENT.md mis Ă jour
- [ ] CHANGELOG mis Ă jour
AprĂšs un merge modifiant lâenvironnement :
## đą Mise Ă jour de l'environnement de dĂ©veloppement
**Date :** 2025-03-15
**Version :** 2.1.0
### Changements
- Ajout de cppcheck pour l'analyse statique
- Ajout de lcov pour la couverture de code
### Action requise
â ïž **Tous les dĂ©veloppeurs doivent reconstruire leur conteneur :**
1. Dans VS Code : `Ctrl+Shift+P`
2. Tapez : "Dev Containers: Rebuild Container"
3. Attendez la reconstruction (~3-5 min)
### Nouvelles commandes disponibles
- `cppcheck src/` : Analyse statique
- `lcov ...` : Couverture de code
### Questions ?
Contactez @lead-dev ou ouvrez une issue.
Créez .devcontainer/verify-env.sh :
#!/bin/bash
# Vérifie que l'environnement est conforme à la spécification
set -e
echo "=== VĂ©rification de l'environnement ==="
ERRORS=0
# Fonction de vérification
check() {
local name="$1"
local expected="$2"
local actual="$3"
if [[ "$actual" == *"$expected"* ]]; then
echo "â $name: OK ($actual)"
else
echo "â $name: ERREUR (attendu: $expected, obtenu: $actual)"
ERRORS=$((ERRORS + 1))
fi
}
# VĂ©rifications
check "GCC" "11" "$(gcc --version | head -1)"
check "CMake" "3.22" "$(cmake --version | head -1)"
check "Valgrind" "3.18" "$(valgrind --version)"
# Variables d'environnement
check "CC" "gcc" "$CC"
check "CFLAGS" "-Wall" "$CFLAGS"
echo ""
if [ $ERRORS -eq 0 ]; then
echo "â Environnement conforme"
exit 0
else
echo "â $ERRORS erreur(s) dĂ©tectĂ©e(s)"
exit 1
fi
verify-environment:
runs-on: ubuntu-latest
container:
image: mcr.microsoft.com/devcontainers/cpp:1-ubuntu-22.04
steps:
- uses: actions/checkout@v4
- name: Setup
run: bash .devcontainer/setup.sh
- name: Verify environment
run: bash .devcontainer/verify-env.sh
Ă ce stade, vous comprenez :
Le DevContainer nâest plus juste un outil pratique, câest LA rĂ©fĂ©rence officielle de votre environnement de dĂ©veloppement.
devcontainer.json dĂ©finit lâenvironnement officielCitation finale :
« When the DevContainer is your source of truth, âč works on my machine âș becomes âč works everywhere âș. »
â Philosophie DevOps moderne
Félicitations ! Vous avez complété le module sur les DevContainers. Vous savez maintenant :
devcontainer.jsonVotre environnement de développement C est maintenant :
âïž La ChaĂźne de Compilation