CircleCI からのマイグレーション

現在CircleCIを使用していても、CI/CDパイプラインをGitLab CI/CDに移行でき、GitLab CI/CDの強力な機能を利用できます。CircleCIとGitLabの比較をご覧になり、何が違うのかを確認してください。

GitLabへの移行を始める前に役立つと思われる資料を集めました。

クイックスタートガイドでは、GitLab CI/CDの仕組みの概要を説明しています。またGitLabには、設定をほとんど必要とせずにアプリケーションを構築、テスト、デプロイできるAuto DevOpsも用意されています。

CI/CDを高度に活用している場合でも、カスタムプロジェクトテンプレートを使用することで、パイプライン構成の再利用が可能になります。

なにか質問があるときは、GitLabコミュニティフォーラムを利用してください。

config.yml 対.gitlab-ci.yml

CircleCI のconfig.yml 設定ファイルは、スクリプト、ジョブ、ワークフロー（GitLab では “ステージ” と呼ばれる）を定義します。GitLabでは、リポジトリのルートディレクトリにある.gitlab-ci.yml 。

ジョブ

CircleCIでは、ジョブは特定のタスクを実行するためのステップの集まりです。GitLabでは、ジョブは設定ファイルの基本要素でもあります。GitLab CI/CDではリポジトリが自動的に取得されるため、checkout キーワードは必要ありません。

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の同等の機能はステージと呼ばれます。同じステージのジョブは並行して実行され、前のステージが完了した後にのみ実行されます。デフォルトではジョブが失敗すると次のステージの実行はスキップされますが、失敗したジョブの後でも実行を継続させることができます。

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

並列および順次ジョブの実行

以下の例では、ジョブが並列または順次実行される方法を示しています。

  1. job1 とjob2 が並列に実行されます (GitLab CI/CD のbuild ステージ)。
  2. job3 job1 とjob2 が正常に完了した後にのみ実行されます（test ステージ）。
  3. 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を持っています。またrulesを使って、スケジュールされたパイプラインにジョブを含めるか、含めないかを判断できます。

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 UIのcronスケジュールで、スケジュールの設定と有効/無効を設定できます。

マニュアル実行

CircleCIのマニュアルワークフロー例。

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

GitLab CI/CDでwhen: manual 、同じワークフローの例：

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

Orbs

CircleCI Orbsを補完するGitLabの2つの課題が挙げられており、GitLabでどのように同じ機能を実現するか検討中です。

ビルド環境

CircleCI では、特定のジョブを実行するための内部技術としてexecutors を提供しています。GitLabでは、これはRunnerによって行われます。

対応している環境は以下のとおりです。

セルフマネージド・ランナー：

  • Linux
  • Windows
  • macOS

GitLab.com共有ランナー：

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

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

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