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と呼びます。同じステージ上のジョブは並行して実行され、前のステージが完了した後にのみ実行されます。ジョブが失敗すると次のステージの実行はデフォルトではスキップされますが、失敗したジョブの後に実行を継続できるよう設定できます。
使用できるパイプラインの種類については、パイプラインアーキテクチャの概要を参照してください。パイプラインは、大規模で複雑なプロジェクトや独立して定義されたコンポーネントを使用したモノレポなど、ニーズに合わせてカスタマイズできます。
並列および順次ジョブの実行
以下の例では、ジョブが並列または順次実行される方法を示しています。
-
job1
とjob2
は、(GitLab CI/CDのbuild
stageで)並列に実行されます。 -
job3
は、job1
とjob2
が正常に完了した後(test
stage)にのみ実行されます。 -
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でどのように同じ機能を実現するか検討中です。
- https://gitlab.com/gitlab-com/Product/-/issues/1151
- https://gitlab.com/gitlab-org/gitlab/-/issues/195173
ビルド環境
CircleCIは、特定のジョブを実行するための基盤技術としてexecutors
を提供しています。GitLabでは、同じ機能をRunnersによって実現します。
対応している環境は以下のとおりです。
セルフマネージドRunner。
- Linux
- Windows
- macOS
GitLab.comの共有Runner。
- Linux
- Windows
- macOS(予定)
マシンと特定のビルド環境
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!"