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

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

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

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

  1. job1とjob2は、（GitLab CI/CDのbuild stageで）並列に実行されます。
  2. job3は、job1とjob2が正常に完了した後（test stage）にのみ実行されます。
  3. job4はjob3が正常に完了した後（deploy stage）にのみ実行されます。

CircleCIのworkflows使用例。 

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
  
job 1:
  stage: build
  script: make build dependencies

job 2:
  stage: build
  script: make build artifacts
  
job3:
  stage: test
  script: make test

job4:
  stage: deploy
  script: make deploy

スケジュール実行

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

ブランチによるフィルタリングジョブ

rulesは、特定のブランチに対してジョブ実行可否を決定する仕組みです。

CircleCIのブランチでフィルタリングされたジョブ例。 

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

GitLab CI/CDのrulesを使用したワークフロー例。 

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

キャッシュ

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を使ったワークフロー例。 

image: node:latest

# Cache modules in between jobs
cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js

コンテキストと変数

CircleCIでは、プロジェクトのパイプラインに環境変数を安全に渡すためのコンテキストを提供しています。GitLabでは、Groupを作成して関連するプロジェクトをまとめます。グループレベルでは、変数を個々のプロジェクト外に保存し、複数プロジェクトのパイプラインへ安全に渡せます。

Orbs

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

ビルド環境

CircleCIは、特定のジョブを実行するための基盤技術としてexecutorsを提供しています。GitLabでは、同じ機能をRunnersによって実現します。

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

セルフマネージドRunner。

  • Linux
  • Windows
  • macOS

GitLab.comの共有Runner。

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

tagsを使って、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!"