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

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では、これはRunnerによって行われます。

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

セルフマネージド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!"