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トリガーは、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、またはその他のクラウドプロバイダーまたはデプロイターゲットですか？

前提要件

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

GitLabに慣れてください。
- 主なGitLab CI/CD機能についてお読みください。
- 最初のGitLabパイプラインと、静的サイトをビルド、テスト、およびデプロイするより複雑なパイプラインを作成するためのチュートリアルに従ってください。
- CI/CD YAML構文リファレンスを確認してください。
GitLabをセットアップして構成します。
GitLabインスタンスをテストします。
- 共有GitLab.com Runnerを使用するか、新しいRunnerをインストールして、Runnerが利用可能であることを確認します。

移行手順

SCMソリューションからGitLabにプロジェクトを移行します。
- （推奨）利用可能なインポーターを使用して、外部SCMプロバイダーからの大量のインポートを自動化できます。
- URLでリポジトリをインポートすることができます。
各プロジェクトに.gitlab-ci.ymlファイルを作成します。
TeamCityの設定をGitLab CI/CDジョブに移行し、マージリクエストに結果を直接表示するように設定します。
クラウドデプロイテンプレート、環境、およびKubernetes向けGitLabエージェントを使用して、デプロイメントジョブを移行します。
CI/CD設定をさまざまなプロジェクト間で再利用できるかどうかを確認し、CI/CDテンプレートまたはCI/CDコンポーネントを作成して共有します。
パイプラインの効率性を参照して、GitLab CI/CDパイプラインをより高速かつ効率的にする方法を学びます。

ここに記載されていない質問がある場合は、GitLabコミュニティフォーラムが役立ちます。