doc-locale/fr-fr/ci/migration/circleci.md
{{< details >}}
{{< /details >}}
Si vous utilisez actuellement CircleCI, vous pouvez migrer vos pipelines CI/CD vers GitLab CI/CD et commencer à exploiter toutes ses fonctionnalités puissantes.
Nous avons rassemblé plusieurs ressources qui vous seront peut-être utiles avant de commencer la migration.
Le Guide de démarrage rapide est une bonne vue d'ensemble du fonctionnement de GitLab CI/CD. Vous pourriez également être intéressé par Auto DevOps, qui peut être utilisé pour compiler, tester et déployer vos applications avec peu ou pas de configuration nécessaire.
Pour les équipes CI/CD avancées, les modèles de projets personnalisés permettent de réutiliser les configurations de pipeline.
Si vous avez des questions auxquelles vous ne trouvez pas de réponse ici, le forum de la communauté GitLab peut être une excellente ressource.
config.yml vs .gitlab-ci.yml {#configyml-vs-gitlab-ciyml}Le fichier de configuration config.yml de CircleCI définit des scripts, des jobs et des workflows (appelés « étapes » dans GitLab). Dans GitLab, une approche similaire est utilisée avec un fichier .gitlab-ci.yml dans le répertoire racine de votre dépôt.
Dans CircleCI, les jobs sont un ensemble d'étapes permettant d'effectuer une tâche spécifique. Dans GitLab, les jobs constituent également un élément fondamental du fichier de configuration. Le mot-clé checkout n'est pas nécessaire dans GitLab CI/CD, car le dépôt est automatiquement récupéré.
Exemple de définition de job CircleCI :
jobs:
job1:
steps:
- checkout
- run: "execute-script-for-job1"
Exemple de la même définition de job dans GitLab CI/CD :
job1:
script: "execute-script-for-job1"
CircleCI définit les images au niveau du job, ce qui est également pris en charge par GitLab CI/CD. De plus, GitLab CI/CD permet de définir ce paramètre globalement pour tous les jobs qui n'ont pas image défini.
Exemple de définition d'image CircleCI :
jobs:
job1:
docker:
- image: ruby:2.6
Exemple de la même définition d'image dans GitLab CI/CD :
job1:
image: ruby:2.6
CircleCI détermine l'ordre d'exécution des jobs avec workflows. Cela est également utilisé pour déterminer les exécutions simultanées, séquentielles, planifiées ou manuelles. La fonction équivalente dans GitLab CI/CD s'appelle stages. Les jobs d'une même étape s'exécutent en parallèle et ne s'exécutent qu'après la fin des étapes précédentes. Par défaut, l'exécution de l'étape suivante est ignorée lorsqu'un job échoue, mais il est possible de permettre la poursuite de l'exécution même après l'échec d'un job.
Consultez la vue d'ensemble de l'architecture des pipelines pour obtenir des conseils sur les différents types de pipelines que vous pouvez utiliser. Les pipelines peuvent être adaptés à vos besoins, par exemple pour un projet complexe de grande envergure ou un monorepo avec des composants indépendants définis.
Les exemples suivants montrent comment les jobs peuvent s'exécuter en parallèle ou de manière séquentielle :
job1 et job2 s'exécutent en parallèle (dans l'étape build pour GitLab CI/CD).job3 s'exécute uniquement après la fin de job1 et job2 avec succès (dans l'étape test).job4 s'exécute uniquement après la fin de job3 avec succès (dans l'étape deploy).Exemple CircleCI avec workflows :
version: 2
jobs:
job1:
steps:
- checkout
- run: make build dependencies
job2:
steps:
- run: make build artifacts
job3:
steps:
- run: make test
job4:
steps:
- run: make deploy
workflows:
version: 2
jobs:
- job1
- job2
- job3:
requires:
- job1
- job2
- job4:
requires:
- job3
Exemple du même workflow sous forme de stages dans GitLab CI/CD :
stages:
- build
- test
- deploy
job1:
stage: build
script: make build dependencies
job2:
stage: build
script: make build artifacts
job3:
stage: test
script: make test
job4:
stage: deploy
script: make deploy
environment: production
GitLab CI/CD dispose d'une interface utilisateur simple pour planifier les pipelines. De plus, les rules peuvent être utilisées pour déterminer si les jobs doivent être inclus ou exclus d'un pipeline planifié.
Exemple CircleCI d'un workflow planifié :
commit-workflow:
jobs:
- build
scheduled-workflow:
triggers:
- schedule:
cron: "0 1 * * *"
filters:
branches:
only: try-schedule-workflow
jobs:
- build
Exemple du même pipeline planifié utilisant rules dans GitLab CI/CD :
job1:
script:
- make build
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"
Une fois la configuration du pipeline enregistrée, vous configurez la planification cron dans l'interface GitLab et pouvez également activer ou désactiver les planifications depuis l'interface.
Exemple CircleCI d'un workflow manuel :
release-branch-workflow:
jobs:
- build
- testing:
requires:
- build
- deploy:
type: approval
requires:
- testing
Exemple du même workflow utilisant when: manual dans GitLab CI/CD :
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
when: manual
environment: production
Les rules sont un mécanisme permettant de déterminer si le job s'exécute pour une branche spécifique.
Exemple CircleCI d'un job filtré par branche :
jobs:
deploy:
branches:
only:
- main
- /rc-.*/
Exemple du même workflow utilisant rules dans GitLab CI/CD :
deploy:
stage: deploy
script:
- echo "Deploy job"
rules:
- if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH =~ /^rc-/
environment: production
GitLab fournit un mécanisme de mise en cache pour accélérer les temps de compilation de vos jobs en réutilisant des dépendances précédemment téléchargées. Il est important de connaître la différence entre le cache et les artefacts pour tirer le meilleur parti de ces fonctionnalités.
Exemple CircleCI d'un job utilisant un cache :
jobs:
job1:
steps:
- restore_cache:
key: source-v1-< .Revision >
- checkout
- run: npm install
- save_cache:
key: source-v1-< .Revision >
paths:
- "node_modules"
Exemple du même pipeline utilisant cache dans GitLab CI/CD :
test_async:
image: node:latest
cache: # Cache modules in between jobs
key: $CI_COMMIT_REF_SLUG
paths:
- .npm/
before_script:
- npm ci --cache .npm --prefer-offline
script:
- node ./specs/start.js ./specs/async.spec.js
CircleCI fournit des Contextes pour transmettre de manière sécurisée des variables d'environnement à travers les pipelines de projets. Dans GitLab, un Groupe peut être créé pour rassembler des projets connexes. Au niveau du groupe, des variables CI/CD peuvent être stockées en dehors des projets individuels et transmises de manière sécurisée dans les pipelines de plusieurs projets.
Deux tickets GitLab sont ouverts concernant les Orbs de CircleCI et la façon dont GitLab peut offrir des fonctionnalités similaires.
CircleCI propose executors comme technologie sous-jacente pour exécuter un job spécifique. Dans GitLab, cela est réalisé par des runners.
Les environnements suivants sont pris en charge :
Runners autogérés :
Runners d'instance GitLab.com :
Les tags peuvent être utilisés pour exécuter des jobs sur différentes plateformes, en indiquant à GitLab quels runners doivent exécuter les jobs.
Exemple CircleCI d'un job s'exécutant dans un environnement spécifique :
jobs:
ubuntuJob:
machine:
image: ubuntu-1604:201903-01
steps:
- checkout
- run: echo "Hello, $USER!"
osxJob:
macos:
xcode: 11.3.0
steps:
- checkout
- run: echo "Hello, $USER!"
Exemple du même job utilisant tags dans GitLab CI/CD :
windows job:
stage: build
tags:
- windows
script:
- echo Hello, %USERNAME%!
osx job:
stage: build
tags:
- osx
script:
- echo "Hello, $USER!"