GitHub Actions vs GitLab CI pour backend, web et mobile

Ce qui pose problème dans le CI multi-applications

Quand un repo construit un backend, une application web et des apps mobiles, le CI n’est plus « juste exécuter des tests ». Il devient un gestionnaire de trafic pour des toolchains différentes, des temps de build différents et des règles de release différentes.

Le problème le plus courant est simple : une petite modification déclenche trop de travail. Une édition de docs lance la signature iOS, une retouche backend force une reconstruction complète du web, et soudain chaque merge paraît lent et risqué.

Dans les setups multi-app, quelques problèmes apparaissent vite :

• Runner drift : les versions des SDK diffèrent selon les machines, donc les builds se comportent différemment entre CI et local.
• Prolifération des secrets : clés API, certificats de signature et identifiants stores se retrouvent dupliqués entre jobs et environnements.
• Confusion des caches : la mauvaise clé de cache crée des builds obsolètes, mais l’absence de cache rend tout douloureusement lent.
• Règles de release mixtes : les backends veulent des déploiements fréquents, tandis que les mobiles sont verrouillés et nécessitent des vérifications supplémentaires.
• Lisibilité du pipeline : la configuration devient un mur de jobs que personne n’a envie de toucher.

C’est pour ça que le choix entre GitHub Actions et GitLab CI pèse plus dans un monorepo que dans un projet mono-app. Il faut des façons claires de scinder le travail par chemin, de partager des artefacts en toute sécurité et d’empêcher que des jobs parallèles se marchent sur les pieds.

Une comparaison pratique se résume à quatre points : configuration et scalabilité des runners, stockage et périmètre des secrets, cache et artefacts, et la facilité à exprimer « ne construire que ce qui a changé » sans transformer le pipeline en soupe de règles fragile.

Il s’agit de fiabilité et de maintenabilité au quotidien, pas de quel outil a le plus d’intégrations ou la plus jolie interface. Ce guide ne remplace pas non plus les choix sur vos outils de build (Gradle, Xcode, Docker, etc.). Il aide à choisir le CI qui rend la structure propre plus facile à maintenir.

Comment GitHub Actions et GitLab CI sont structurés

La différence la plus visible est la façon dont chaque plateforme organise les pipelines et la réutilisation, et cela commence à compter dès que backend, web et mobile partagent le même repo.

GitHub Actions stocke l’automatisation dans des fichiers YAML sous .github/workflows/. Les workflows se déclenchent sur des événements comme push, pull request, schedule ou runs manuels. GitLab CI est centré autour de .gitlab-ci.yml à la racine du repo, avec des fichiers inclus optionnels, et les pipelines s’exécutent typiquement sur les pushes, merge requests, schedules et jobs manuels.

GitLab est construit autour de stages. Vous définissez des stages (build, test, deploy), puis assignez des jobs à ces stages qui s’exécutent dans l’ordre. GitHub Actions est structuré autour de workflows contenant des jobs. Les jobs s’exécutent en parallèle par défaut, et vous définissez des dépendances quand quelque chose doit attendre.

Pour exécuter la même logique sur plusieurs cibles, les matrices de GitHub sont naturelles (iOS vs Android, plusieurs versions de Node). GitLab peut faire un fan-out similaire avec des jobs parallèles et des variables, mais il faut souvent relier plus de pièces soi‑même.

La réutilisation diffère aussi. Dans GitHub, les équipes s’appuient souvent sur des reusable workflows et des composite actions. Dans GitLab, la réutilisation vient généralement de include, de templates partagés et d’ancres/extends YAML.

Les approbations et les environnements protégés sont aussi différents. GitHub utilise souvent des environnements protégés avec reviewers requis et des secrets d’environnement pour faire patienter un déploiement de production. GitLab combine habituellement branches/tags protégés, environnements protégés et jobs manuels pour que seuls certains rôles puissent lancer un déploiement.

Configuration des runners et exécution des jobs

La configuration des runners est là où les deux plateformes commencent à se différencier au quotidien. Les deux peuvent utiliser des runners hébergés (machine gérée par la plateforme) ou des runners self-hosted (vous gérez la machine, les mises à jour et la sécurité). Les runners hébergés sont plus simples pour démarrer ; les self-hosted sont souvent nécessaires pour la vitesse, des outils spéciaux ou l’accès à des réseaux privés.

Une séparation pratique dans beaucoup d’équipes : runners Linux pour backend et web, macOS uniquement quand il faut construire iOS. Android peut tourner sur Linux, mais c’est lourd, donc la taille du runner et l’espace disque comptent.

Hébergé vs self-hosted : ce que vous gérez

Les runners hébergés conviennent quand vous voulez une configuration prévisible sans maintenance. Les self-hosted sont pertinents quand vous avez besoin de versions Java/Xcode spécifiques, de caches plus rapides ou d’accès réseau interne.

Si vous optez pour du self-hosted, définissez les rôles des runners tôt. La plupart des repos s’en sortent bien avec un petit set : un runner Linux général pour backend/web, un runner Linux plus puissant pour Android, un runner macOS pour packaging et signature iOS, et un runner séparé pour les déploiements avec permissions strictes.

Choisir le bon runner par job

Les deux systèmes permettent de cibler des runners (labels dans GitHub, tags dans GitLab). Nommez-les selon les charges : linux-docker, android, ou macos-xcode15 par exemple.

L’isolation est à l’origine de nombreux builds fragiles. Fichiers résiduels, caches partagés corrompus ou outils installés « à la main » sur une machine self-hosted peuvent créer des échecs aléatoires. Des workspaces propres, des versions d’outils figées et un nettoyage programmé des runners rapportent vite.

La capacité et les permissions sont d’autres points récurrents, surtout avec la disponibilité et le coût de macOS. Une règle simple : les runners de build construisent, les runners de déploiement déploient, et les credentials de production vivent dans le plus petit ensemble possible de jobs.

Secrets et variables d’environnement

Les secrets sont un point délicat dans les pipelines multi-app. Les fondamentaux sont similaires (stocker les secrets sur la plateforme, les injecter à l’exécution), mais le périmètre diffère.

GitHub Actions scope généralement les secrets au niveau du repository et de l’organisation, avec une couche supplémentaire d’Environments. Cette couche est utile quand la prod a besoin d’un gate manuel et d’un jeu de valeurs distinct de la staging.

GitLab CI utilise des variables CI/CD au niveau du projet, du groupe ou de l’instance. Il prend aussi en charge des variables scoping par environnement, plus des protections comme protected (uniquement disponibles sur branches/tags protégés) et masked (cachées dans les logs). Ces contrôles sont utiles quand un monorepo sert plusieurs équipes.

Le mode d’échec principal est l’exposition accidentelle : sortie de debug, une commande échouée qui echo des variables, ou un artefact incluant un fichier de config. Considérez logs et artefacts comme partageables par défaut.

Dans les pipelines backend + web + mobile, les secrets comprennent typiquement des credentials cloud, des URLs de bases de données et clés API tierces, du matériel de signature (certificats/profiles iOS, keystore Android et mots de passe), des tokens de registry (npm, Maven, CocoaPods) et des tokens d’automatisation (email/SMS, chat bots).

Pour plusieurs environnements (dev, staging, prod), gardez des noms cohérents et swappez les valeurs via le périmètre d’environnement plutôt qu’en copiant des jobs. Ça facilite la rotation et le contrôle d’accès.

Quelques règles empêchent la plupart des incidents :

• Préférez des credentials court‑terme (par ex. OIDC vers les cloud providers quand disponible) plutôt que des clés longue durée.
• Appliquez le principe du moindre privilège : identités de déploiement séparées pour backend, web et mobile.
• Masquez les secrets et évitez d’imprimer les variables d’environnement, même en cas d’erreur.
• Restreignez les secrets de production aux branches/tags protégés et aux approbations nécessaires.
• Ne stockez jamais de secrets dans des artefacts, même temporairement.

Un exemple simple et à fort impact : les jobs mobiles ne doivent recevoir les secrets de signature que sur des releases taguées, tandis que les jobs de déploiement backend peuvent utiliser un deploy token limité sur les merges vers main. Ce changement réduit fortement la surface d’exposition en cas de mauvaise configuration.

Caching et artefacts pour accélérer les builds

La plupart des pipelines lents le sont pour une raison ennuyeuse : ils retéléchargent et reconstruisent sans cesse les mêmes choses. Le cache évite le travail répété. Les artefacts résolvent un autre problème : conserver l’output exact d’un run spécifique.

Ce qu’il faut cacher dépend de ce que vous construisez. Les backends profitent des caches de dépendances et du cache de compilation (par exemple le module cache Go). Les builds web profitent du cache des gestionnaires de paquets et des outils de build. Les builds mobiles ont souvent besoin du cache Gradle et de l’Android SDK sous Linux, et des caches CocoaPods ou Swift Package Manager sur macOS. Prudence avec le caching agressif des outputs iOS (comme DerivedData) à moins de maîtriser les compromis.

Les deux plateformes suivent le même schéma basique : restaurer le cache au début d’un job, sauvegarder le cache mis à jour à la fin. La différence du quotidien tient au contrôle. GitLab rend le comportement des cache et artefacts explicite dans un fichier, incluant l’expiration. GitHub Actions s’appuie souvent sur des actions séparées pour le caching — flexible mais plus facile à mal configurer.

Les clés de cache comptent d’autant plus dans un monorepo. De bonnes clés évoluent quand les inputs changent et restent stables sinon. Les lockfiles (go.sum, pnpm-lock.yaml, yarn.lock, etc.) doivent piloter la clé. Il est aussi utile d’inclure un hash du dossier spécifique de l’application que vous construisez au lieu du repo entier, et de garder des caches séparés par application pour qu’un changement n’invalide pas tout.

Utilisez des artefacts pour les livrables que vous voulez garder : bundles de release, APK/IPA, rapports de tests, fichiers de couverture et métadonnées de build. Les caches accélèrent ; les artefacts conservent un enregistrement.

Si les builds restent lents, vérifiez les caches surdimensionnés, des clés qui changent à chaque run (timestamps, SHAs complets) et des outputs mis en cache non réutilisables entre runners.

Adaptation au monorepo : plusieurs pipelines sans chaos

Un monorepo devient désordonné quand chaque push déclenche tests backend, builds web et signatures mobiles, même si on n’a modifié qu’un README. Le bon pattern : détecter ce qui a changé et n’exécuter que les jobs pertinents.

Dans GitHub Actions, cela signifie souvent des workflows séparés par application avec des filtres de chemins (path filters) pour que chaque workflow ne s’exécute que si des fichiers dans sa zone ont changé. Dans GitLab CI, on utilise rules:changes (ou des child pipelines) pour créer ou ignorer des groupes de jobs selon les chemins.

Les packages partagés sont le point où la confiance casse. Si packages/auth change, backend et web peuvent devoir être reconstruits même si leurs dossiers n’ont pas changé. Traitez les chemins partagés comme des déclencheurs pour plusieurs pipelines et maintenez des frontières de dépendance claires.

Une carte de déclenchement simple pour limiter les surprises :

• Les jobs backend s’exécutent sur changements dans backend/** ou packages/**.
• Les jobs web s’exécutent sur changements dans web/** ou packages/**.
• Les jobs mobile s’exécutent sur changements dans mobile/** ou packages/**.
• Les changements docs déclenchent des vérifications rapides (formatage, vérif orthographique).

Parallélisez ce qui est sûr (tests unitaires, lint, build web). Sérialisez ce qui doit être contrôlé (déploiements, releases stores). Les deux plateformes offrent des mécanismes (needs sur GitLab, dépendances de jobs sur GitHub) pour exécuter des checks rapides tôt et arrêter le pipeline en cas d’échec.

Isolez la signature mobile du CI quotidien. Placez les clés de signature dans un environnement dédié avec approbation manuelle, et lancez la signature seulement sur des tags de release ou une branche protégée. Les pull requests peuvent toujours produire des apps non signées pour validation sans exposer les credentials sensibles.

Étape par étape : un pipeline propre pour backend, web et mobile

Un pipeline multi-app lisible commence par un nommage clair. Choisissez un schéma et tenez‑vous y pour que l’on puisse parcourir les logs et savoir ce qui a tourné.

Un schéma lisible :

• Pipelines : pr-checks, main-build, release
• Environnements : dev, staging, prod
• Artefacts : backend-api, web-bundle, mobile-debug, mobile-release

Ensuite, gardez les jobs petits et ne promouvez que ce qui a réussi aux étapes précédentes :

1. PR checks (chaque pull request) : exécutez des tests rapides et le lint seulement pour les apps qui ont changé. Pour le backend, construisez un artefact déployable (image container ou bundle serveur) et conservez-le pour que les étapes suivantes ne le reconstruisent pas.

2. Web build (PR + main) : construisez le web en bundle statique. Sur PR, conservez la sortie comme artefact (ou déployez dans un environnement preview si vous en avez un). Sur main, produisez un bundle versionné pour dev ou staging.

3. Mobile debug builds (PR uniquement) : construisez un APK/IPA debug. Ne signez pas pour la release. L’objectif est un retour rapide et un fichier installable pour les testeurs.

4. Release builds (tags uniquement) : quand un tag comme v1.4.0 est poussé, exécutez les builds complets backend et web plus les builds mobiles signés. Générez des outputs prêts pour les stores et conservez les notes de release avec les artefacts.

5. Approbations manuelles : placez les approbations entre staging et prod, pas avant les tests de base. Les devs peuvent déclencher des builds, mais seuls les rôles approuvés doivent déployer en production et accéder aux secrets de prod.

Erreurs courantes qui font perdre du temps

Les équipes perdent souvent des semaines à cause d’habitudes de workflow qui créent des builds fragiles.

Un piège est l’usage excessif de runners partagés. Quand de nombreux projets se disputent la même pool, vous obtenez des timeouts aléatoires, des jobs lents et des builds mobiles qui échouent uniquement aux heures de pointe. Si backend, web et mobile comptent, isolez les jobs lourds sur des runners dédiés (ou au moins des queues séparées) et définissez des limites de ressources explicites.

Les secrets sont un autre gouffre temporel. Les clés de signature mobile sont faciles à mal gérer. Erreur courante : les stocker trop largement (disponibles pour chaque branche et job) ou les divulguer via des logs verbeux. Restreignez le matériel de signature aux branches/tags protégés et évitez toute étape qui imprime des valeurs secrètes (même encodées en base64).

Le caching peut se retourner contre vous si vous mettez en cache d’énormes répertoires ou confondez caches et artefacts. Cachez seulement des inputs stables. Conservez les outputs nécessaires comme artefacts.

Enfin, dans les monorepos, déclencher chaque pipeline sur chaque changement brûle des minutes et la patience. Si quelqu’un touche un README et que vous reconstruisez iOS, Android, backend et web, les gens cessent de faire confiance au CI.

Checklist rapide :

• Utilisez des règles basées sur les chemins pour que seuls les apps affectés tournent.
• Séparez jobs de test et jobs de déploiement.
• Restreignez les clés de signature aux workflows de release.
• Cachez des inputs petits et stables, pas des dossiers de build entiers.
• Prévoyez une capacité runner prévisible pour les builds mobiles lourds.

Vérifications rapides avant de vous engager sur une plateforme

Avant de choisir, faites quelques vérifications qui reflètent votre façon de travailler. Elles vous évitent de choisir un outil qui semble OK pour une app mais pénible quand vous ajoutez du mobile, des environnements multiples et des releases.

Concentrez-vous sur :

• Plan de runners : hébergés, self-hosted ou mix. Les builds mobiles poussent souvent vers un mix à cause de macOS.
• Plan de secrets : où vivent les secrets, qui peut les lire et comment se font les rotations. La prod doit être plus verrouillée que la staging.
• Plan de cache : ce que vous cachez, où c’est stocké et comment les clés sont formées. Si la clé change à chaque commit, vous payez sans gagner en vitesse.
• Plan monorepo : filtres de chemins et moyen propre de partager des étapes communes (lint, tests) sans copier-coller.
• Plan de release : tags, approbations et séparation des environnements. Définissez qui peut promouvoir en prod et quelle preuve est requise.

Testez ces réponses sur un petit scénario. Dans un monorepo avec un backend Go, une app Vue et deux apps mobiles : un changement docs devrait presque rien faire ; un changement backend devrait lancer tests backend et construire un artefact API ; un changement UI mobile devrait ne construire qu’Android et iOS.

Si vous ne pouvez pas décrire ce flux sur une page (déclencheurs, caches, secrets, approbations), faites un pilote d’une semaine sur les deux plateformes avec le même repo. Choisissez celle qui vous paraît ennuyeuse et prévisible.

Exemple : un flow réaliste de build et release pour un monorepo

Imaginez un repo avec trois dossiers : backend/ (Go), web/ (Vue) et mobile/ (iOS et Android).

Au quotidien, vous voulez un feedback rapide. Pour les releases, vous voulez des builds complets, la signature et les étapes de publication.

Une séparation pratique :

• Branches feature : exécuter lint + unit tests pour les parties modifiées, construire backend et web, et éventuellement lancer un build Android debug. Ignorer iOS sauf si vraiment nécessaire.
• Tags de release : tout exécuter, créer des artefacts versionnés, signer les apps mobiles et pousser images/binaires vers votre stockage de release.

Le choix des runners évolue quand le mobile entre en jeu. Les builds Go et Vue aiment Linux. iOS exige macOS, ce qui peut influencer la décision plus que tout. Si l’équipe veut un contrôle total des machines, GitLab CI avec runners self-hosted peut être plus facile à gérer en flotte. Si vous préférez moins d’opérations et une mise en place rapide, les runners hébergés GitHub sont pratiques, mais les minutes macOS et la disponibilité deviennent des éléments à planifier.

Le caching est là où vous gagnez vraiment du temps, mais le meilleur cache dépend de l’app : pour Go, cachez les modules et le build cache ; pour Vue, le store du package manager et rebuild uniquement quand les lockfiles changent ; pour mobile, cachez Gradle et l’Android SDK sur Linux, cachez CocoaPods ou SPM sur macOS — attendez-vous à des caches plus gros et plus d’invalidation.

Une règle de décision solide : si votre code est déjà hébergé sur une plateforme, commencez par là. Changez seulement si les runners (notamment macOS), les permissions ou la conformité vous y obligent.

Prochaines étapes : choisir, standardiser et automatiser en sécurité

Choisissez l’outil qui correspond à l’endroit où votre code et vos équipes sont déjà. La différence se voit surtout dans la friction quotidienne : revues, permissions et la rapidité pour diagnostiquer un build cassé.

Commencez simple : un pipeline par app (backend, web, mobile). Une fois stable, extrayez les étapes partagées dans des templates réutilisables pour réduire le copier-coller sans diluer la responsabilité.

Notez le périmètre des secrets comme vous noteriez qui a les clés d’un bureau. Les secrets de production ne doivent pas être lisibles par chaque branche. Programmez une rotation (trimestrielle vaut mieux que jamais), et convenez d’un processus d’invalidation d’urgence.

Si vous utilisez un générateur no-code qui produit du code réel, traitez la génération comme une étape CI à part entière. Par exemple, AppMaster (appmaster.io) génère des backends Go, des apps Vue3 et des apps mobiles Kotlin/SwiftUI : votre pipeline peut régénérer le code quand il change, puis ne construire que les cibles affectées.

Quand votre équipe fait confiance au flow, faites-en la valeur par défaut pour les nouveaux repos et gardez-le ennuyeux : déclencheurs clairs, runners prévisibles, secrets serrés et releases qui ne s’exécutent que quand vous le voulez.