doc-locale/fr-fr/ci/migration/teamcity.md
{{< details >}}
{{< /details >}}
Si vous migrez de TeamCity vers GitLab CI/CD, vous pouvez créer des pipelines CI/CD qui répliquent et améliorent vos workflows TeamCity.
GitLab CI/CD et TeamCity sont des outils CI/CD présentant certaines similarités. GitLab et TeamCity :
Par ailleurs, il existe quelques différences importantes entre les deux :
TeamCity peut être configuré depuis l'interface utilisateur ou dans le Teamcity Configuration fichier au format Kotlin DSL. Une configuration de build TeamCity est un ensemble d'instructions qui définit comment un projet logiciel doit être compilé, testé et déployé. La configuration inclut les paramètres et les réglages nécessaires à l'automatisation du processus CI/CD dans TeamCity.
Dans GitLab, l'équivalent d'une configuration de build TeamCity est le fichier .gitlab-ci.yml. Ce fichier définit le pipeline CI/CD d'un projet, en spécifiant les étapes, les jobs et les commandes nécessaires pour compiler, tester et déployer le projet.
De nombreuses fonctionnalités et de nombreux concepts de TeamCity ont des équivalents dans GitLab offrant les mêmes fonctionnalités.
TeamCity utilise des configurations de build, qui se composent de plusieurs étapes de build dans lesquelles vous définissez des commandes ou des scripts pour exécuter des tâches telles que la compilation du code, l'exécution de tests et la mise en package d'artefacts.
Voici un exemple de configuration de projet TeamCity au format Kotlin DSL qui compile un fichier Docker et exécute des tests unitaires :
package _Self.buildTypes
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildFeatures.perfmon
import jetbrains.buildServer.configs.kotlin.buildSteps.dockerCommand
import jetbrains.buildServer.configs.kotlin.buildSteps.nodeJS
import jetbrains.buildServer.configs.kotlin.triggers.vcs
object BuildTest : BuildType({
name = "Build & Test"
vcs {
root(HttpsGitlabComRutshahCicdDemoGitRefsHeadsMain)
}
steps {
dockerCommand {
id = "DockerCommand"
commandType = build {
source = file {
path = "Dockerfile"
}
}
}
nodeJS {
id = "nodejs_runner"
workingDir = "app"
shellScript = """
npm install jest-teamcity --no-save
npm run test -- --reporters=jest-teamcity
""".trimIndent()
}
}
triggers {
vcs {
}
}
features {
perfmon {
}
}
})
Dans GitLab CI/CD, vous définissez des jobs avec les tâches à exécuter dans le cadre du pipeline. Chaque job peut comporter une ou plusieurs étapes de build.
Le fichier .gitlab-ci.yml GitLab CI/CD équivalent pour l'exemple précédent serait :
workflow:
rules:
- if: $CI_COMMIT_BRANCH != "main" || $CI_PIPELINE_SOURCE != "merge_request_event"
when: never
- when: always
stages:
- build
- test
build-job:
image: docker:20.10.16
stage: build
services:
- docker:20.10.16-dind
script:
- docker build -t cicd-demo:0.1 .
run_unit_tests:
image: node:17-alpine3.14
stage: test
before_script:
- cd app
- npm install
script:
- npm test
artifacts:
when: always
reports:
junit: app/junit.xml
Les déclencheurs TeamCity définissent les conditions qui initient un build, notamment les modifications VCS, les déclencheurs planifiés ou les builds déclenchés par d'autres builds.
Dans GitLab CI/CD, les pipelines peuvent être déclenchés automatiquement pour divers événements, comme des modifications apportées aux branches ou aux merge requests et les nouveaux tags. Les pipelines peuvent également être déclenchés manuellement, à l'aide d'une API, ou avec des pipelines planifiés. Pour plus d'informations, consultez Pipelines CI/CD.
Dans TeamCity, vous définissez les paramètres de build et les variables d'environnement dans les paramètres de configuration de build.
Dans GitLab, utilisez le mot-clé variables pour définir des variables CI/CD. Utilisez des variables pour réutiliser des données de configuration, disposer d'une configuration plus dynamique ou stocker des valeurs importantes. Les variables peuvent être définies de manière globale ou par job.
Par exemple, un fichier .gitlab-ci.yml GitLab CI/CD utilisant des variables :
default:
image: alpine:latest
stages:
- greet
variables:
NAME: "Fern"
english:
stage: greet
variables:
GREETING: "Hello"
script:
- echo "$GREETING $NAME"
spanish:
stage: greet
variables:
GREETING: "Hola"
script:
- echo "$GREETING $NAME"
Les configurations de build dans TeamCity vous permettent de définir des artefacts générés pendant le processus de build.
Dans GitLab, tout job peut utiliser le mot-clé artifacts pour définir un ensemble d'artefacts à stocker lorsqu'un job se termine. Les artefacts sont des fichiers qui peuvent être utilisés dans des jobs ultérieurs, à des fins de test ou de déploiement.
Par exemple, un fichier .gitlab-ci.yml GitLab CI/CD utilisant des artefacts :
stage:
- generate
- use
generate_cat:
stage: generate
script:
- touch cat.txt
- echo "meow" > cat.txt
artifacts:
paths:
- cat.txt
expire_in: 1 week
use_cat:
stage: use
script:
- cat cat.txt
L'équivalent des agents TeamCity dans GitLab sont les runners.
Dans GitLab CI/CD, les runners sont les services qui exécutent les jobs. Si vous utilisez GitLab.com, vous pouvez utiliser la flotte de runners d'instance pour exécuter des jobs sans provisionner vos propres runners autogérés.
Quelques informations importantes sur les runners :
tags pour un contrôle plus précis et associer des runners à des jobs spécifiques. Par exemple, vous pouvez utiliser un tag pour les jobs nécessitant du matériel dédié, plus puissant ou spécifique.Certaines fonctionnalités de TeamCity activées via les fonctionnalités de build et les plugins sont prises en charge nativement dans GitLab CI/CD avec des mots-clés et des fonctionnalités CI/CD.
La liste de recommandations suivante a été élaborée après observation d'organisations ayant réussi à effectuer rapidement une migration vers GitLab CI/CD.
Avant de commencer une migration, vous devez créer un plan de migration afin de vous préparer à la migration.
Pour une migration depuis TeamCity, posez-vous les questions suivantes en préparation :
Avant d'effectuer tout travail de migration, vous devez d'abord :
.gitlab-ci.yml dans chaque projet.Si vous avez des questions sans réponse ici, le forum de la communauté GitLab peut être une excellente ressource.