skills-IA/raggaroth-senior-dev/references/infra-devops.md

Infra & DevOps : Docker, Podman, PostgreSQL, Gitea

Docker / Podman

• Image de base : vérifier une version explicite et pinnée (pas de latest en prod/CI) → latest non pinné = 🟠.
• Utilisateur non-root dans le conteneur pour tout ce qui tourne en prod/CI — root par défaut sans justification = 🟠 (surface d'attaque).
• Multi-stage build pour limiter la taille de l'image finale (surtout pour du Java/Node buildé) — absence sur un build lourd = 🟡.
• .dockerignore présent et cohérent pour éviter d'embarquer des secrets/fichiers inutiles = vérifier systématiquement.
• Podman vs Docker : si rootless Podman est utilisé (cohérent avec le choix du studio d'éviter le daemon root), vérifier que les volumes/permissions UID/GID sont gérés correctement (mapping utilisateur) plutôt que de forcer du root.
• Secrets : jamais de secret en clair dans un Dockerfile/docker-compose.yml/ENV versionné = 🔴 systématique.

PostgreSQL

• Migrations : toute modification de schéma doit passer par un outil de migration versionné (pas d'ALTER manuel non tracé) = 🟠 minimum, 🔴 si ça touche une table en prod sans rollback prévu.
• Index : vérifier la présence d'index sur les colonnes utilisées en WHERE/JOIN fréquents avant de valider une requête qui semble lente.
• Transactions : opérations multi-tables qui doivent être atomiques mais ne sont pas dans une transaction explicite = 🔴 potentiel (incohérence de données).
• Connexions : pooling de connexions plutôt que d'ouvrir une connexion par requête dans du code applicatif à fort volume.
• Types : privilégier les types PostgreSQL adaptés (timestamptz plutôt que timestamp sans fuseau, numeric pour les montants plutôt que float).

Gitea (workflow & CI)

• Branch protection sur main : vérifier que le workflow proposé respecte la protection de branche déjà en place (cf. préférences de Benjamin sur la hygiène de clés/rotation et les accès agents IA).
• PR/Issue : cohérence avec la structure EPIC=Milestone / FEATURE=Issue / STORY=checklist item définie dans la skill agile-master — ne pas réinventer une autre convention de nommage dans une review.
• CI (Gitea Actions ou runner équivalent) : tout script de CI doit être idempotent et échouer explicitement (exit code non nul) en cas de problème plutôt que de continuer silencieusement.
• Clés/déploiement : pour tout ce qui touche l'accès Git d'un agent (SSH, PAT), rappeler la préférence du studio pour des deploy keys ou PAT fine-grained scopés (Contents: write + Pull requests: write) plutôt qu'un accès large — accès trop large proposé = 🟠.