DevOps, CI/CD et contrôle de version

Définition

Le contrôle de version est un système qui enregistre l'historique des modifications d'un fichier dans un dépôt : chaque sauvegarde est un commit identifié, daté, signé par son auteur. Git est l'outil, distribué : chaque clone contient tout l'historique. GitHub est une plateforme d'hébergement de dépôts Git qui ajoute la collaboration (pull requests, revues, issues). Le DevOps applique ce binôme aux opérations réseau, et la CI/CD automatise les tests et le déploiement de la configuration à chaque changement.

Contexte

Le blueprint 200-301, thème 6, demande de décrire les concepts et les avantages du contrôle de version (Git et GitHub), et de reconnaître les fondamentaux du CI/CD appliqués à la gestion de configuration réseau. À l'examen : vocabulaire exact (clone, commit, push, pull, branch, merge), différence Git contre GitHub, principe de la pull request, et la règle absolue des secrets : un mot de passe ne se commite jamais.

Le vocabulaire minimal

Commande	Effet
git clone URL	Copie locale complète d'un dépôt distant
git checkout -b branche	Crée et bascule sur une branche parallèle
git add puis git commit	Photographie locale des changements, avec message
git push	Envoie les commits vers le dépôt distant
git pull	Récupère et fusionne les commits distants
git merge	Intègre une branche dans la branche courante

Git n'est pas GitHub

Git tourne hors ligne, dans le dossier .git de la machine locale ; personne ne peut travailler sur votre historique sans votre clé. GitHub (GitLab, Bitbucket ou un serveur interne) est le point de rencontre : il héberge le dépôt de référence, gère les droits, et permet les pull requests. Sur un dépôt config-reseau, l'arborescence typique d'une équipe place les modèles et l'inventaire en YAML :

# inventaire/site.yaml
site: atelier-concentration
switchs:
  - nom: SW-ATELIER-01
    mgmt_ip: 10.10.20.11
    role: acces
  - nom: SW-ATELIER-02
    mgmt_ip: 10.10.20.12
    role: acces

Le workflow pull request

Le chemin standard : une branche par changement, un commit par intention, une pull request pour la revue, un merge après feu vert. Concrètement, un technicien qui corrige un VLAN cree fix/vlan-atelier depuis main, modifie le YAML, commit avec un message qui explique le pourquoi, push, ouvre la PR. Un second technicien relit le diff, la CI passe au vert, la PR fusionne. L'historique devient un journal d'audit : qui a changé quoi, quand, et avec quelle validation, chaque version du fichier restant récupérable en une commande. Les numéros de version suivent la logique du bump sémantique : 1.0.0 vers 1.0.1 pour un correctif, 1.1.0 pour un ajout compatible, 2.0.0 pour une rupture.

CI/CD appliqué au réseau

La CI (intégration continue) exécute une pipeline à chaque push : validation syntaxique des YAML, lint des règles (un VLAN référencé existe-t-il, une IP est-elle bien formée), tests unitaires des scripts. La CD (délivrance continue) pousse ensuite la configuration validée vers les équipements, souvent via un outil d'infrastructure as code comme Ansible, dont les playbooks décrivent en YAML l'état désiré et vérifient la dérive.

# .github/workflows/lint.yml (extrait)
name: lint-config
on: [pull_request]
jobs:
  yamllint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install yamllint
      - run: yamllint -c .yamllint inventaire/

Le déploiement se fait progressif : d'abord un switch d'accès isolé (canary), vérification, puis le lot complet, avec rollback automatique si le post-test échoue. Comparez aux copies faites à la main dans un dossier partagé : la pipeline n'oublie jamais une étape, ne déploie jamais un fichier mal formé, et documente chaque action.

La règle des secrets

Un commit est éternel : même supprimé dans un commit suivant, il reste dans l'historique et dans chaque clone. C'est la différence avec un fichier effacé d'un dossier. Jamais donc de mot de passe, de clé API ou de communauté SNMP dans le dépôt. Les secrets vivent dans des variables d'environnement ou un coffre, et le code les lit au moment de l'exécution : os.environ["MERAKI_API_KEY"] plutôt qu'une chaîne en clair dans le script. Un fichier .gitignore écarte en plus les artefacts locaux (dossiers .venv, sauvegardes) qui n'ont rien à faire en historique.

Exemple concret

Une équipe gère 60 switchs en YAML dans un dépôt. Une erreur de frappe supprime un VLAN de production sur 40 appareils en CLI manuel : 40 configs à retrouver dans des sauvegardes datées, deux jours de travail. Avec le dépôt versionné, git log identifie le commit fautif en dix minutes, git revert rejoue l'inverse proprement, et la PR obligatoire aurait bloqué le changement sans relecture. L'assurance n'est pas que les erreurs disparaissent, mais qu'elles deviennent traçables et réversibles.

Pièges fréquents

1. Penser que Git est un service en ligne : Git est local, GitHub est le service.
2. Travailler directement sur main sans branche ni pull request.
3. Committer un script avec sa clé API, puis croire que la supprimer du fichier suivant suffit.
4. Confondre merge et rebase dans les questions : le blueprint attend merge.