CircleCIから移行する

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

現在CircleCIを使用している場合は、GitLab CI/CDに移行して、その強力な機能をすべて活用できます。

移行を開始する前に役立つ可能性のあるリソースをいくつか収集しました。

クイックスタートガイドは、GitLab CI/CDの仕組みの概要を把握するのに役立ちます。Auto DevOpsに関心があるかもしれません。これは、アプリケーションをビルド、テスト、デプロイするために使用でき、設定はほとんど必要ありません。

高度なCI/CDチームの場合、カスタムプロジェクトテンプレートを使用すると、パイプラインの設定を再利用できます。

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

`config.yml`と`.gitlab-ci.yml`の違い

CircleCIのconfig.yml設定ファイルは、スクリプト、ジョブ、ワークフロー（GitLabでは「ステージ」と呼ばれます）を定義します。GitLabでは、リポジトリのルートディレクトリにある.gitlab-ci.ymlファイルを使用して、同様のアプローチが使用されます。

ジョブ

CircleCIでは、ジョブは特定のタスクを実行するための一連のステップです。GitLabでは、ジョブも設定ファイルの基本的な要素です。checkoutキーワードは、リポジトリが自動的にフェッチされるため、GitLab CI/CDでは不要です。

CircleCIのジョブ定義の例:

jobs:
  job1:
    steps:
      - checkout
      - run: "execute-script-for-job1"

GitLab CI/CDでの同じジョブ定義の例:

job1:
  script: "execute-script-for-job1"

Dockerイメージ定義

CircleCIは、ジョブレベルでイメージを定義します。これは、GitLab CI/CDでもサポートされています。さらに、GitLab CI/CDは、imageが定義されていないすべてのジョブで使用されるように、これをグローバルに設定することをサポートしています。

CircleCIのイメージ定義の例:

jobs:
  job1:
    docker:
      - image: ruby:2.6

GitLab CI/CDでの同じイメージ定義の例:

job1:
  image: ruby:2.6

ワークフロー

CircleCIは、workflowsを使用してジョブの実行順序を決定します。これは、同時実行、連続実行、スケジュール実行、または手動実行を決定するためにも使用されます。GitLab CI/CDでの同等の機能は、ステージと呼ばれます。同じステージのジョブは並行して実行され、前のステージが完了した後にのみ実行されます。デフォルトでは、ジョブが失敗すると次のステージの実行はスキップされますが、ジョブが失敗した後でも続行させることができます。

使用できるさまざまな種類のパイプラインのガイダンスについては、パイプラインアーキテクチャの概要を参照してください。パイプラインは、大規模で複雑なプロジェクトや、独立して定義されたコンポーネントを持つモノレポなど、ニーズに合わせて調整できます。

並列および連続ジョブ実行

次の例は、ジョブを並行して、または順番に実行する方法を示しています:

job1とjob2は、（GitLab CI/CDのbuildステージで）並行して実行されます。
job3は、job1とjob2が正常に完了した後にのみ（testステージで）実行されます。
job4は、job3が正常に完了した後にのみ（deployステージで）実行されます。

workflowsを使用したCircleCIの例:

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

GitLab CI/CDでのstagesと同じワークフローの例:

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には、パイプラインのスケジュールを設定するための使いやすいUIがあります。また、スケジュールされたパイプラインにジョブを含めるか除外するかを決定するためにルールを使用できます。

スケジュールされたワークフローのCircleCIの例:

commit-workflow:
  jobs:
    - build
scheduled-workflow:
  triggers:
    - schedule:
        cron: "0 1 * * *"
        filters:
          branches:
            only: try-schedule-workflow
  jobs:
    - build

GitLab CI/CDでrulesを使用した同じスケジュールされたパイプラインの例:

job1:
  script:
    - make build
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_REF_NAME == "try-schedule-workflow"

パイプラインの設定を保存したら、GitLabユーザーインターフェースでcronスケジュールを設定し、UIでスケジュールを有効または無効にすることもできます。

手動実行

手動ワークフローのCircleCIの例:

release-branch-workflow:
  jobs:
    - build
    - testing:
        requires:
          - build
    - deploy:
        type: approval
        requires:
          - testing

when: manualを使用したGitLab CI/CDでの同じワークフローの例:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  when: manual
  environment: production

ブランチによるジョブのフィルター

ルールは、特定のブランチに対してジョブが実行されるかどうかを判断するメカニズムです。

ブランチでフィルターされたジョブのCircleCIの例:

jobs:
  deploy:
    branches:
      only:
        - main
        - /rc-.*/

GitLab CI/CDでrulesを使用した同じワークフローの例:

deploy:
  stage: deploy
  script:
    - echo "Deploy job"
  rules:
    - if: $CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH =~ /^rc-/
  environment: production

キャッシュ

GitLabは、以前にダウンロードした依存関係を再利用することにより、ジョブのビルド時間を短縮するためのキャッシュメカニズムを提供します。これらの機能を最大限に活用するには、キャッシュとアーティファクトの違いを知っておくことが重要です。

キャッシュを使用するジョブのCircleCIの例:

jobs:
  job1:
    steps:
      - restore_cache:
          key: source-v1-< .Revision >
      - checkout
      - run: npm install
      - save_cache:
          key: source-v1-< .Revision >
          paths:
            - "node_modules"

GitLab CI/CDでcacheを使用した同じパイプラインの例:

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は、プロジェクトパイプライン全体で環境変数を安全に渡すためのコンテキストを提供します。GitLabでは、関連するプロジェクトをまとめるためにグループを作成できます。グループレベルでは、CI/CD変数を個々のプロジェクトの外部に保存し、複数のプロジェクトにわたるパイプラインに安全に渡すことができます。

Orbs

CircleCI Orbsに対処し、GitLabが同様の機能を実現する方法について説明する2つのGitLabイシューが開いています。

ビルド環境

CircleCIは、特定のジョブを実行するための基盤となるテクノロジーとしてexecutorsを提供します。GitLabでは、これはRunnerによって行われます。

次の環境がサポートされています:

セルフマネージドRunner:

Linux
Windows
macOS

GitLab.comのインスタンスRunner:

Linux
Windows （ベータ）。
macOS （ベータ）。

マシンと特定のビルド環境

タグを使用すると、どのRunnerがジョブを実行するかをGitLabに指示することで、異なるプラットフォームでジョブを実行できます。

特定の環境で実行されているジョブのCircleCIの例:

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!"

GitLab CI/CDでtagsを使用した同じジョブの例:

windows job:
  stage: build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage: build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"