正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

TeamCityから移行する

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

TeamCityからGitLab CI/CDへ移行する場合は、TeamCityのワークフローをレプリケートし、強化するCI/CDパイプラインを作成できます。

主な類似点と相違点

GitLab CI/CDとTeamCityは、いくつかの類似点があるCI/CDツールです。GitLabとTeamCityはどちらも:

  • ほとんどの言語のジョブを実行できる十分な柔軟性があります。
  • オンプレミスまたはクラウドにデプロイできます。

さらに、両者にはいくつかの重要な違いがあります:

  • GitLab CI/CDパイプラインはYAML形式の設定ファイルで設定され、手動で編集することも、パイプラインエディタで編集することもできます。TeamCityのパイプラインは、UIまたはKotlin DSLを使用して設定できます。
  • GitLabは、SCM、コンテナレジストリ、セキュリティスキャンなどを内蔵したDevSecOpsプラットフォームです。TeamCityでは、これらの機能のために通常インテグレーションによって提供される個別のソリューションが必要です。

設定ファイル

TeamCityはUIから設定するか、Kotlin DSL形式のTeamcity Configurationファイルで設定できます。TeamCityのビルド設定は、ソフトウェアプロジェクトをどのようにビルドし、テストし、デプロイするかを定義する一連の指示です。その設定には、TeamCityでのCI/CDプロセスを自動化するために必要なパラメータと設定が含まれます。

GitLabでは、TeamCityのビルド設定に相当するものが.gitlab-ci.ymlファイルです。このファイルはプロジェクトのCI/CDパイプラインを定義し、プロジェクトをビルド、テスト、デプロイするために必要なステージ、ジョブ、およびコマンドを指定します。

機能と概念の比較

多くのTeamCityの機能と概念には、GitLabに同じ機能を提供する同等のものがあります。

ジョブ

TeamCityはビルド設定を使用します。これは複数のビルドステップで構成されており、コードのコンパイル、テストの実行、アーティファクトのパック化などのタスクを実行するコマンドやスクリプトを定義します。

以下は、Dockerファイルをビルドすると単体テストを実行するKotlin DSL形式のTeamCityプロジェクト設定の例です:

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 {
        }
    }
})

GitLab CI/CDでは、パイプラインの一部として実行するタスクとともにジョブを定義します。各ジョブには、1つ以上のビルドステップを定義できます。

前の例に相当するGitLab CI/CDの.gitlab-ci.ymlファイルは次のようになります:

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

パイプライントリガー

TeamCity Triggersは、VCSの変更、スケジュールされたトリガー、または他のビルドによってトリガーされたビルドなど、ビルドを開始する条件を定義します。

GitLab CI/CDでは、ブランチやマージリクエストの変更、新しいタグなどのさまざまなイベントに対してパイプラインを自動的にトリガーできます。パイプラインは、APIを使用するか、スケジュールされたパイプラインを使用して手動でトリガーすることもできます。詳細については、CI/CDパイプラインを参照してください。

変数

TeamCityでは、ビルド設定の設定でビルドパラメータと環境変数を定義します。

GitLabでは、variablesキーワードを使用してCI/CD変数を定義します。変数を使用して、設定データを再利用したり、より動的な設定を行ったり、重要な値を保存したりできます。変数は、グローバルまたはジョブごとに定義できます。

例えば、変数を使用するGitLab CI/CDの.gitlab-ci.ymlファイルは次のとおりです:

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"

アーティファクト

TeamCityのビルド設定では、ビルドプロセス中に生成されるアーティファクトを定義できます。

GitLabでは、任意のジョブでartifactsキーワードを使用して、ジョブの完了時に保存されるアーティファクトのセットを定義できます。アーティファクトは、後のジョブでテストやデプロイのために使用できるファイルです。

例えば、アーティファクトを使用するGitLab CI/CDの.gitlab-ci.ymlファイルは次のとおりです:

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

Runner

GitLabにおけるTeamCityエージェントに相当するものはRunnerです。

GitLab CI/CDでは、Runnerはジョブを実行するサービスです。GitLab.comを使用している場合は、Runnerフリートを使用して、独自のセルフマネージドRunnerをプロビジョニングすることなくジョブを実行できます。

Runnerに関するいくつかの重要な詳細:

  • Runnerは、インスタンス全体、グループ全体で共有するように設定したり、単一のプロジェクトに専用にしたりできます。
  • より詳細な制御のためにtagsキーワードを使用し、Runnerを特定のジョブに関連付けることができます。例えば、専用の、より強力な、または特定のハードウェアを必要とするジョブには、タグを使用できます。
  • GitLabには、Runnerのオートスケール機能があります。オートスケールを使用して、必要なときにのみRunnerをプロビジョニングし、不要なときにスケールダウンします。

TeamCityのビルド機能とプラグイン

ビルド機能とプラグインを通じて有効になるTeamCityの一部の機能は、CI/CDキーワードと機能によってGitLab CI/CDでネイティブにサポートされています。

TeamCityプラグインGitLab機能
コードカバレッジコードカバレッジとテストカバレッジの可視化
単体テストレポートJUnitテストレポートアーティファクトと単体テストレポート
通知通知メールとSlack

移行の計画と実行

以下のおすすめのステップのリストは、GitLab CI/CDへの移行を迅速に完了できた組織を観察した後に作成されました。

移行計画を作成する

移行を開始する前に、移行の準備をするために移行計画を作成する必要があります。

TeamCityからの移行に備えて、以下の質問を自問してください:

  • 現在、TeamCityのジョブではどのようなプラグインが使用されていますか？
    • これらのプラグインが具体的に何をするか知っていますか？
  • TeamCityのエージェントには何がインストールされていますか？
  • 共有ライブラリは使用されていますか？
  • TeamCityからどのように認証していますか？SSHキー、APIトークン、またはその他のシークレットを使用していますか？
  • パイプラインからアクセスする必要がある他のプロジェクトはありますか？
  • 外部サービスにアクセスするための認証情報がTeamCityにありますか？例えば、Ansible Tower、Artifactory、または他のクラウドプロバイダーやデプロイターゲットなどですか？

前提条件

移行作業を行う前に、まず次のことを行う必要があります:

  1. GitLabに慣れる。
  2. GitLabをセットアップして設定します。
  3. GitLabインスタンスをテストします。
    • 共有GitLab.comRunnerを使用するか、新しいRunnerをインストールして、Runnerが利用可能であることを確認します。

移行ステップ

  1. プロジェクトをSCMソリューションからGitLabに移行します。
  2. 各プロジェクトで.gitlab-ci.ymlファイルを作成します。
  3. TeamCityの設定をGitLab CI/CDジョブに移行し、マージリクエストで結果を直接表示するように設定します。
  4. クラウドデプロイメントテンプレート 、環境 、およびKubernetes向けGitLabエージェントを使用して、デプロイメントジョブを移行します。
  5. 異なるプロジェクト間で再利用できるCI/CD設定があるかどうかを確認し、CI/CDテンプレートまたはCI/CDコンポーネントを作成して共有します。
  6. GitLab CI/CDパイプラインをより速く、より効率的にする方法については、パイプラインの効率性を参照してください。

ここで回答されていない質問がある場合は、GitLabコミュニティフォーラムが役立つリソースとなります。