Travis CI a marqué l’histoire du CI/CD dans le monde open source, mais son attractivité a décliné au fil des années : limitations du plan gratuit, politiques tarifaires fluctuantes et intégration désormais moins profonde avec les plateformes de dépôt. Pour une organisation qui héberge (ou souhaite héberger) son code sur GitLab, la migration vers GitLab CI est une évidence : elle permet de centraliser le code source, le CI/CD, le registre de conteneurs, la revue de code et le suivi des issues dans un écosystème unique.
Pourquoi quitter Travis CI pour GitLab CI ?
La raison première est la centralisation. Travis CI est un service externe qui se branche sur GitHub ; GitLab CI est natif de la plateforme GitLab. En migrant, l’équipe gagne un environnement cohérent où tout se pilote depuis un même endroit : le dépôt, les pipelines, les artefacts, les environnements de déploiement et les revues de code. La gestion des permissions, des secrets et des runners est unifiée.
S’ajoutent des raisons de souveraineté et de coût : GitLab peut être auto-hébergé (GitLab CE/EE), ce qui permet de maîtriser la localisation des données et les coûts, là où Travis CI impose un service cloud. Enfin, GitLab CI offre une syntaxe déclarative puissante (fichier .gitlab-ci.yml) avec des fonctionnalités avancées : stages, DAG, needs, environnements, revues d’apps et include pour la réutilisation.
Travis CI vs GitLab CI : les correspondances
| Concept Travis CI | Équivalent GitLab CI | Remarques |
|---|---|---|
| .travis.yml | .gitlab-ci.yml | Syntaxe différente, plus riche |
| Build | Pipeline (stages + jobs) | Notion de stages explicite |
| Job | Job | Exécuté par un runner GitLab |
| Stages implicites | Stages + needs (DAG) | Exécution conditionnelle fine |
| Environment variables | CI/CD variables (masquées/protégées) | Portée dépôt/groupe/instance |
| Secrets encryptés | Variables masquées + Vault | Gestion centralisée |
| Deploy provider | Environnements + environment: | Revue d’apps, rollback |
| Build matrix | parallel: matrix | Matrice native |
| Cron builds | Scheduled pipelines | Planification intégrée |
Cette table illustre que la migration est aussi une montée en puissance fonctionnelle, à condition de bien maîtriser la nouvelle syntaxe.
Les étapes d’une migration Travis CI vers GitLab CI
- Inventaire des builds Travis : lister les dépôts, leurs fichiers
.travis.yml, les variables d’environnement, les secrets, les déploiements et les jobs planifiés. - Migration des dépôts : si le code est encore sur GitHub, importer les dépôts vers GitLab (import natif, avec conservation de l’historique et des branches).
- Écriture des fichiers .gitlab-ci.yml : convertir chaque build en pipeline GitLab, en organisant les jobs en stages (build, test, deploy) et en utilisant des images Docker explicites.
- Configuration des runners : utiliser les runners partagés de GitLab.com ou déployer des runners auto-hébergés (exécuteurs Docker, shell, Kubernetes) selon les besoins.
- Migration des variables et secrets : transférer les variables vers les CI/CD variables GitLab, en marquant les secrets comme « masqués » et « protégés ».
- Mise en place des environnements : définir les environnements (staging, production) pour activer le déploiement continu et les revues d’apps.
- Tests en parallèle et bascule : faire tourner GitLab CI en parallèle de Travis, valider les résultats, puis désactiver Travis et former les équipes.
Les pièges de la conversion des pipelines
Le premier piège est la syntaxe : Travis utilise un YAML avec des concepts propres (install, script, deploy, matrix), alors que GitLab CI raisonne en stages et jobs, avec une logique needs pour le parallélisme. Une conversion mécanique produit des pipelines lents ; il faut repenser le découpage. Le deuxième piège est la gestion des secrets : Travis chiffrait des variables dans le fichier ; GitLab privilégie les variables de projet/groupe, ce qui impose une migration propre des informations sensibles. Le troisième est l’exécution : les runners partagés GitLab.com ont des quotas, et les gros builds nécessitent des runners dédiés ou une optimisation du cache.
Enfin, la réutilisation : GitLab offre include (fichiers locaux, distants, templates) pour factoriser les pipelines ; sans cette pratique, on reproduit la duplication de Travis.
Centraliser l’écosystème de développement
Le bénéfice le plus tangible est la centralisation : en plus du CI/CD, l’équipe dispose du registre de conteneurs (GitLab Container Registry), de la gestion des packages (GitLab Package Registry), des revues de code (merge requests), des environnements et des revues d’apps. Cette unification réduit le nombre d’outils, simplifie la gouvernance et accélère le cycle de développement, du commit jusqu’au déploiement.
Sécuriser et gouverner les pipelines
GitLab CI offre des mécanismes de sécurité qu’il convient d’activer dès le départ. Les variables CI/CD peuvent être masquées et protégées (accessibles uniquement sur les branches protégées), et le couplage avec un coffre de secrets (Vault, ou l’intégration native GitLab) évite de stocker des informations sensibles en clair. La protection des branches permet d’exiger des pipelines verts avant tout merge, et les environnements protégés restreignent les déploiements en production à un cercle restreint d’approbateurs.
Côté gouvernance, l’usage d’include et de templates partagés garantit l’uniformité des pipelines entre les équipes : on impose des standards de build, de test et de sécurité, tout en laissant aux projets la souplesse d’adapter leurs jobs spécifiques. Cette structuration, souvent absente de Travis CI, transforme le CI/CD en un bien commun maîtrisé plutôt qu’en une collection de configurations hétérogènes.
Bonnes pratiques et conduite du changement
- Utiliser
includepour factoriser les pipelines et imposer des standards. - Protéger les variables sensibles et les branches (main, production).
- Configurer des environnements avec approbation manuelle pour la production.
- Activer le cache (dépendances, build) pour accélérer les exécutions.
- Former les équipes à la syntaxe
.gitlab-ci.yml, aux runners et aux environnements. - Documenter les runbooks : gestion des secrets, dépannage des runners, rollback des déploiements.
Pourquoi confier cette migration à Performances Digital ?
La migration de Travis CI vers GitLab CI est l’occasion de moderniser toute votre chaîne de développement en la centralisant sur une plateforme unique. Chez Performances Digital, nous pilotons cette transition de bout en bout : import des dépôts, réécriture des pipelines, configuration des runners, migration des secrets, mise en place des environnements et formation de vos équipes. Notre méthode par bascule progressive garantit la continuité du CI/CD pendant toute la durée du projet.
Centraliser vos outils de développement, c’est simplifier le quotidien de vos équipes et accélérer vos livraisons. Demandez votre devis gratuit : nous évaluerons vos builds Travis et vous remettrons un plan de migration chiffré, avec un calendrier de bascule sans interruption.
