Github Actions からの移行

クラウド

Server 3.x

このページの内容

このドキュメントでは、GitHub Actions から CircleCI に移行する方法を概説します。

CircleCI に移行する理由

CircleCI は、大変優れた CI ツールです。 8 年前に設立して以来、CI/CD は弊社の専門分野です。通常の CI/CD ツールに求められる機能に加えて、CircleCI が他と一線を画すのは、生産性を高める以下のような機能です。

高度なキャッシュ - 通常の依存関係のキャッシュに加えて、CircleCI では Docker イメージレイヤーに特化したキャッシュを提供しています。これは、Docker イメージの後続のビルドがより速く実行されることを意味し、コミットからデプロイまでのワークフローにかかる時間をさらに短縮できます。
ビルドへの SSH 接続 - CircleCI は、実行環境への安全な SSH 接続機能を提供しており、ログの監視、ファイルの操作、および各環境と直接やり取りすることが可能です。これは、失敗したビルドのデバッグに非常に役立ちます。
リソースクラス - プラットフォーム上でさまざまなサイズの Executor を使用することができ、ノード上のワークロードの大きさに応じた調整に最適です。
テストの並列実行 - CircleCI のプラットフォームは、ジョブの同時実行だけでなく、並行環境間でテストを分割する機能も備えています。ワークロードを異なるコンテナに分割することで、ビルド時間を大幅に短縮することができます。

その他にも、CircleCI ソリューションを特徴づける様々な機能があります。今すぐ無料アカウントを作成し、CircleCI をお試しください。チームでのご利用をお考えでしたら、セールスチームにご連絡をいただければ、トライアルを設定させていただきます。

コンセプト

ジョブとワークフロー

GitHub Actions と CircleCI には、「ジョブ」と「ワークフロー」という似たような概念があります。ワークフローは、複数の連結されたジョブのエンドツーエンドの流れであり、ジョブは小さなタスク (例えば、「ユニットテストの実行」や「Docker イメージのビルド」) を実行するためのコマンドで構成されています。

主に異なる点は、CircleCI では設定構文においてワークフローとジョブの依存関係をジョブのインラインではなく別のセクションで設定します。

GitHub CircleCI

GitHub	CircleCI
`name: My GitHub Actions Workflow on: [push] jobs: job_1: runs-on: ubuntu-latest steps: # job steps job_2: needs: job_1 runs-on: ubuntu-latest steps: # job steps`	`jobs: job_1: executor: my-ubuntu-exec steps: # job steps job_2: executor: my-ubuntu-exec steps: # job steps workflows: my_workflow: jobs: - job_1 - job_2: requires: - job_1`

name: My GitHub Actions Workflow

on: [push]

jobs:
  job_1:
    runs-on: ubuntu-latest
    steps:
      # job steps
  job_2:
    needs: job_1
    runs-on: ubuntu-latest
    steps:
      # job steps

jobs:
  job_1:
    executor: my-ubuntu-exec
    steps:
      # job steps
  job_2:
    executor: my-ubuntu-exec
    steps:
      # job steps

workflows:
  my_workflow:
    jobs:
      - job_1
      - job_2:
          requires:
            - job_1

Actions と Orb の比較

GitHub の「アクション」とは、ジョブ内で実行する再利用可能なコマンドやタスクのことです。しかし、それらは Docker コンテナ内で実行するように書かれていたり、JavaScript で個々のステップとしてコーディングされています。そのため、作業が増え、適用できる範囲が限られてしまいます。

CircleCI の場合は、同様の機能を Orb で提供しています。主な違いは、CircleCI の Orb はパッケージ化された再利用可能な YAML であり、再利用可能なジョブ、Executor、またはコマンドを「Orb 化」し、ジョブやワークフローの中で適切に使用することができます。

GitHub では、Marketplace でアクションを参照できます。CircleCI では、パートナーやコミュニティの多数の認定 Orb やインテグレーションが記載されたインテグレーションのページだけでなく、 Orb レジストリもあります。

ランナーと Executor の比較

GitHub では、YAML の runs-on キーによって、Linux、macOS、Windows のビルドの実行環境を指定することができ、コンテナで何かを実行したい場合は、追加の container キーを指定します。

CircleCI では、同じように環境 (Executor と呼ばれる) を選択でき、Docker 用のオプションや機能が追加されています。

各 Executor のタイプにお好きなバージョンを選択することができ、それによりその後インストールされるベースソフトウェアのバージョンが異なります。

以下の表を参照して設定を比較してください。

設定の比較

GitHub の設定	CircleCI の設定
実行環境の指定: GitHub ではコンテナの実行は別々に指定されますが、CircleCI では `docker` が Executor の独自のクラスです。
`# Choosing an Operating System runs-on: ubuntu-latest # or windows, etc. # If running steps on a container container: image: openjdk:17.0-jdk`	`# Docker (container) Executor docker: - image: cimg/openjdk:17.0 auth: username: mydockerhub-user password: $DOCKERHUB_PASSWORD # context / project UI env-var reference # Linux Ubuntu Executor machine: true # macOS Executor macos: xcode: 14.2.0 # Windows Executor # NOTE: Orb declaration needed. See docs executor: win/vs2019`
依存関係/サービスの指定: CircleCI で最初に指定されたイメージ以降に指定されたイメージは、すべて依存関係として扱われます。
`jobs: build: runs-on: ubuntu-latest # Main container container: image: openjdk:17.0-jdk # Dependency Service(s) services: postgres: image: postgres:10.8 env: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: postgres`	`jobs: build: docker: # Primary Executor - image: cimg/openjdk:17.0 auth: username: mydockerhub-user password: $DOCKERHUB_PASSWORD # context / project UI env-var reference # Dependency Service(s) - image: postgres:10.8 auth: username: mydockerhub-user password: $DOCKERHUB_PASSWORD # context / project UI env-var reference environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: postgres`
ジョブ内で実行するステップの指定: 同じような機能ですが、構文が異なります。
`jobs: build: # runner config here steps: - name: Build with Gradle run: ./gradlew build`	`jobs: build: # executor config here steps: - run: name: Build with Gradle command: ./gradlew build`
共有タスクの利用 (GitHub ならアクション、CircleCI なら Orb): CircleCI では、最初にトップレベルの Orb を宣言し、設定で名前によりその Orb を参照します。これは Python や JavaScript のインポートに似た概念です。
`jobs: build: # runner config here steps: - name: Slack Notify uses: rtCamp/action-slack-notify@v1.0.0 env: SLACK_COLOR: '#32788D' SLACK_MESSAGE: 'Tests passed' SLACK_TITLE: Slack Notify GA SLACK_USERNAME: Bobby SLACK_WEBHOOK: # WEBHOOK`	`orbs: slack-orb: circleci/slack@3.4.0 jobs: build: # executor config here steps: - slack-orb/notify: color: '#32788D' message: Tests passed title: Testing Slack Orb author_name: Bobby webhook: # WEBHOOK`
ワークフローでの条件付きステップの使用: CircleCI では、ステップの基本的な条件 (例: on_success (デフォルト)、 on_success、on_failure) だけでなく、パラメーターに基づいた条件付きのステップを提供しています。また、条件付きのジョブも提供しており、条件付きのパラメーター化されたワークフローとパイプラインが現在プレビュー中です。
`jobs: build: # environment config here steps: - name: My Failure Step run: echo "Failed step" if: failure() - name: My Always Step run: echo "Always step" if: always()`	`jobs: build: # executor config here steps: - run: name: My Failure Step command: echo "Failed step" when: on_fail - run: name: My Always Step command: echo "Always step" when: always`

CircleCI のその他の設定例は、サンプルとガイドの概要とサンプルプロジェクトのページをご覧ください。

GitHub Actions と CircleCI の設定は似ているため、ジョブやワークフローの移行は非常に簡単です。しかし、移行を成功させる可能性を高めるために、アイテムを以下の順序で移行することをお勧めします。

ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。ご協力いただき、ありがとうございます。

このページの編集をご提案ください (最初に「コントリビューションガイド」をご覧ください)。
ドキュメントの問題点を報告する、またはフィードバックやコメントを送信するには、GitHub で issue を作成してください。
CircleCI は、ユーザーの皆様の弊社プラットフォームにおけるエクスペリエンスを向上させる方法を常に模索しています。フィードバックをお寄せいただける場合は、リサーチコミュニティにご参加ください。

サポートが必要ですか

CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。

または、サポートサイトから、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。

CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.