Comparaison des solutions CI/CD¶

Cette page alimente un ADR (Architecture Decision Record) pour le choix de la plateforme CI/CD. Voir le format ADR dans Documenter son code — ADR.

Grille de comparaison¶

Analyse détaillée¶

Gitea Actions — Recommande pour CI¶

Forces :

• Integration native avec Gitea (SCM du catalogue) — pas de connecteur a configurer
• Compatibilité avec l'ecosysteme GitHub Actions (milliers d'actions réutilisables)
• Runner leger (act runner) deployable en conteneur Podman
• YAML familier pour les équipes habituees a GitHub Actions
• Self-hosted, pas de dependance a un service externe
• Déclencheurs riches (push, PR, cron, dispatch, tag)

Faiblesses :

• Ecosysteme plus jeune que Jenkins ou GitLab CI
• Pas de capacité CD/GitOps native (nécessaire de coupler avec Flux v2)
• Certaines actions GitHub ne sont pas 100% compatibles
• Moins de documentation communautaire que les alternatives

Verdict : choix naturel pour la CI quand Gitea est le SCM. L'integration native elimine la complexité d'un connecteur externe.

Flux v2 (FluxCD) — Recommande pour CD / GitOps¶

Forces :

• CNCF graduated — maturité et gouvernance communautaire prouvees
• Kubernetes-native (CRD GitRepository, Kustomization, HelmRelease)
• Modèle pull : le cluster tire depuis Git, pas de credentials CI dans le cluster
• Reconciliation continue avec detection de drift (--feature-gates=DetectDrift=true)
• Architecture modulaire : source-controller, kustomize-controller, helm-controller, notification-controller
• Multi-tenancy native via isolation par namespace et ServiceAccount
• Image automation intégrée (image-reflector + image-automation controllers) — détection automatique de nouvelles images sans commit CI
• Support natif de SOPS et Sealed Secrets pour le chiffrement des secrets dans Git
• Bootstrap en une commande (flux bootstrap) — pas de Helm chart a gérer
• Empreinte très légère (~200 Mo pour tous les controllers)
• Compatible Helm, Kustomize, manifestes bruts

Faiblesses :

• Ne fait pas de CI (pas de build, pas de test)
• Pas d'UI native (CLI uniquement ; Weave GitOps UI disponible en option)
• Necessite un cluster Kubernetes
• Courbe d'apprentissage pour les concepts GitOps et les CRD Flux
• Debugging parfois moins visuel qu'une UI intégrée

Verdict : standard GitOps CNCF graduated pour Kubernetes. Architecture légère et modulaire, image automation intégrée, multi-tenancy native. Complementaire a Gitea Actions pour la partie CI.

Jenkins — Si pipelines legacy existants¶

Forces :

• Ecosysteme de plugins le plus large (1800+)
• Flexibilite totale (Groovy permet toute logique)
• Maturité (20+ ans, production-ready)
• Supporte tous les environnements (VM, conteneurs, bare metal, cloud)

Faiblesses :

• Architecture monolithique (controller JVM lourd)
• Groovy : langage complexe, difficile a maintenir
• Sécurité : plugins tiers de qualité variable, surface d'attaque large
• UI datee, UX degradee
• Maintenance operationnelle lourde (plugins, upgrades, compatibilité)

Verdict : justifie uniquement si des pipelines Jenkins existants représentent un investissement significatif. Pour un nouveau projet, privilegier Gitea Actions.

GitLab CI — Si GitLab est le SCM¶

Forces :

• Integration native avec GitLab (SCM + CI + CD + registre dans un seul produit)
• YAML intuitif avec includes, templates et composants réutilisables
• Environments et review apps natifs
• Auto DevOps pour des pipelines zero-config
• Documentation exhaustive

Faiblesses :

• Lie a l'ecosysteme GitLab (pas pertinent si Gitea est le SCM)
• Edition Enterprise nécessaire pour certaines fonctionnalités (SAST, DAST, compliance)
• Empreinte mémoire significative (GitLab complet = plusieurs Go de RAM)
• Runner externe a déployer et maintenir

Verdict : excellent si l'organisation utilise GitLab comme SCM. Non pertinent dans notre contexte ou Gitea est le SCM du catalogue.

Tekton — Pour pipelines Kubernetes-natifs¶

Forces :

• 100% Kubernetes-native (CRD Task, Pipeline, PipelineRun)
• Chaque étape est un conteneur isole dans un Pod
• Réutilisable via le Tekton Hub (catalogue de Tasks)
• Pas de serveur central (scalabilité native Kubernetes)
• Fondation CD de la Linux Foundation

Faiblesses :

• Courbe d'apprentissage elevee (abstractions CRD spécifiques)
• Ecosysteme plus restreint que GitHub Actions ou Jenkins
• Verbeux (beaucoup de YAML pour des pipelines simples)
• Peu de documentation hors du contexte OpenShift Pipelines
• Debugging difficile (logs repartis dans les Pods)

Verdict : pertinent si l'équipe est déjà experte Kubernetes et veut un CI/CD 100% CRD. Sinon, la combinaison Gitea Actions + Flux v2 est plus pragmatique.

Matrice de decision¶

graph TD
    A{SCM utilise ?} -->|Gitea| B{Besoin GitOps K8s ?}
    A -->|GitLab| C[GitLab CI]
    A -->|Autre| D{Pipelines Jenkins existants ?}
    B -->|Oui| E[Gitea Actions CI + Flux v2 CD]
    B -->|Non| F[Gitea Actions CI uniquement]
    D -->|Oui, significatifs| G[Jenkins migration progressive]
    D -->|Non| E

Decision recommandee¶

Pour une DSI utilisant Gitea comme SCM et Kubernetes comme plateforme de déploiement :

Flux v2 vs ArgoCD — Pourquoi Flux v2¶

Le choix de Flux v2 repose sur son architecture légère et modulaire, l'image automation native, le chiffrement SOPS intégré, et la multi-tenancy par namespace qui s'aligne avec le modèle Kubernetes natif.

Alternatives conditionnelles¶

Critères de reevaluation¶

Cette decision doit etre reevaluee si :

• Gitea Actions atteint des limites fonctionnelles bloquantes (pipelines complexes multi-repo)
• Flux v2 est remplace par un standard GitOps plus largement adopte
• L'organisation migre vers GitLab comme SCM
• Tekton simplifie significativement son modèle d'abstraction
• ArgoCD réduit significativement son empreinte et intègre nativement l'image automation