Aller au contenu

GitOps et changements

Pour exécuter l'ensemble du cycle manuellement, voir Cluster et GitOps sans IA et CI, Dagger et releases sans IA.

Dépôt et chemin actif

  • Dépôt : https://github.com/djayzone/k8s-apps
  • Branche : main
  • Point d'entrée Flux : clusters/ovh-primary
  • Applications actives : apps/ovh-primary
  • Infrastructure : infrastructure/ovh-primary

Procédure de modification

Le travail courant est piloté dans Plane selon AGENTS.md : Project -> Module/Epic -> Lot, puis Story/Task uniquement si le Lot nécessite réellement une décomposition. GitHub porte l'implémentation par branche et Pull Request.

git pull --ff-only
git switch -c feat/<description>
kubectl kustomize apps/ovh-primary
git diff --check
git status --short
git add <fichiers>
git commit -m "type: description"
git push -u origin feat/<description>

Ouvrir ensuite une Pull Request vers main, la rattacher au Work Item Plane concerné, attendre les contrôles autorisés par la politique CI active et la revue, puis fusionner depuis GitHub. Les pushes directs sur main, force-pushes et contournements administrateur sont interdits.

Pilotage Plane / GitHub

Plane est la source de vérité de la roadmap, des priorités, dépendances, états et blocages. GitHub reste la source de vérité du code, des branches, PR, reviews et checks.

Hiérarchie de référence :

Plane Project
  -> Module / Epic
     -> Work Item parent / Lot
        -> Work Item enfant / Story-Task (optionnel)
           -> GitHub PR

Un Lot simple peut aller directement de l'Epic à la PR. Ne pas créer de Stories/Tasks artificielles. Un hotfix isolé peut être un Lot direct du Project lorsqu'aucun Epic légitime n'existe.

Les incidents opérationnels sont également pilotés dans Plane avec la convention INCIDENT — <service ou composant> — <résumé court>. Un incident isolé est un Lot direct du Project ; un incident lié à un chantier existant est rattaché à l'Epic/Lot concerné. Une PR corrective mergée ne suffit pas à clôturer l'incident : Done exige la preuve de récupération runtime attendue. Les travaux de prévention ou hardening découverts pendant l'incident deviennent ensuite des Lots/Epics séparés.

Les GitHub Issues ne servent plus de backlog fonctionnel ni de journal quotidien. Les anciens coms-agents sont historiques. Les exceptions GitHub-native, telles que le Dependency Dashboard Renovate, restent sur GitHub.

Le protocole complet de hiérarchie, incidents, coordination, handoff et preuve est défini dans AGENTS.md.

Politique CI — webhook GitHub App et exceptions GitHub Actions

AGENTS.md est la source de vérité de la politique CI active.

Tant que la dérogation de coût n'est pas levée explicitement par le propriétaire :

  • les tests fonctionnels lourds ne doivent pas consommer du compute GitHub-hosted lorsqu'ils sont disponibles via Dagger déporté ;
  • la GitHub App et le dispatcher prennent en charge le déclenchement, la classification et la publication des checks Dagger, sans minute hosted pour le chemin normal ;
  • Dagger local/K3s reste le chemin de calcul principal ; cloud uniquement sur demande explicite et avec plafonds ;
  • les builds/publications d'image restant sur GitHub Actions sont des exceptions expressément autorisées, par version et périmètre, et non un droit permanent ;
  • les anciens workflows fonctionnels GitHub-hosted ne doivent pas être réactivés ou relancés pour contourner le routage distant ;
  • toute validation non exécutée doit être déclarée comme telle.

Une ancienne date ou une ancienne Issue ne lève jamais automatiquement cette règle. La décision de levée doit être explicite et traçable dans le Work Item Plane de gouvernance ou une PR de politique CI identifiable.

Skip CI pour un changement documentaire trivial

Le marqueur [skip ci] est autorisé uniquement lorsque le diff complet est strictement documentaire et qu'aucun contrôle utile n'est perdu.

Avant le push :

git diff --name-status origin/main...HEAD
git diff --check origin/main...HEAD
git status --short

Ne jamais utiliser [skip ci] pour masquer un échec ou pour un changement de code, test, migration, manifeste Kubernetes, workflow, dépendance, image, version, configuration, sécurité ou procédure de déploiement.

La description de PR documente explicitement la raison du skip et les validations réellement exécutées. Si un contrôle requis reste Pending ou si l'éligibilité est incertaine, ne pas utiliser le skip.

Après le merge

Un opérateur autorisé ou une automatisation privilégiée contrôle la réconciliation Flux et le runtime concerné. Lorsque pertinent :

kubectl get kustomizations,gitrepositories -A
kubectl get pods -A

Flux vérifie périodiquement Git. Pour accélérer une modification urgente, utiliser uniquement le mécanisme de réconciliation autorisé après que le commit a été poussé.

Le Work Item Plane lié est mis à jour selon les preuves obtenues. Un merge ne signifie pas automatiquement Done lorsque le Lot comporte plusieurs tâches, lorsqu'une validation post-déploiement reste à faire ou lorsqu'un incident n'est pas encore prouvé rétabli.

Un contributeur ou agent sans kubeconfig effectue seulement les validations hors ligne disponibles, documente les contrôles non exécutés et ne prétend jamais avoir validé la production sans preuve.

Coordination des agents

Les agents ne créent plus d'Issue quotidienne coms-agents. Ils se coordonnent au bon niveau :

  • Plane pour ownership, état, dépendances, priorités, blocages et progression ;
  • Pull Request pour diff, choix d'implémentation, reviews, checks et preuves associées au SHA ;
  • lease/ownership explicite pour éviter le double travail lorsqu'un traitement exclusif l'exige.

Avant une review finale, un merge ou une mutation de production, relire le Work Item Plane et les derniers commentaires/reviews de la PR concernée.

Ajouter une application

  1. Créer apps/ovh-primary/<nom>.
  2. Ajouter namespace, Deployment/HelmRelease, Service, Ingress et kustomization.yaml.
  3. Définir requests/limits et probes.
  4. Prévoir au moins deux réplicas pour une application stateless critique lorsque pertinent.
  5. Ajouter le dossier à apps/ovh-primary/kustomization.yaml.
  6. Valider Kustomize hors ligne, ouvrir une Pull Request rattachée au Work Item Plane et appliquer la politique CI active de AGENTS.md avant revue/merge.
  7. Pour un hôte *.lab.djayzone.com, utiliser le mécanisme DNS/TLS existant et vérifier le certificat après déploiement.

Secrets

Ne jamais committer un mot de passe, token, kubeconfig ou clé privée. Utiliser un Secret Kubernetes créé hors Git ou cadrer une solution déclarative dédiée avant de versionner des secrets chiffrés.