ドキュメント
circleci.com
Start Building for Free

Github Actions からの移行

1 week ago1 min read
クラウド
Server 3.x
On This Page

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

CircleCI に移行する理由

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

  1. 高度なキャッシュ - 通常の依存関係のキャッシュ に加えて、CircleCI では Docker イメージレイヤー に特化したキャッシュを提供しています。 これは、Docker イメージの後続のビルドがより速く実行されることを意味し、コミットからデプロイまでのワークフローにかかる時間をさらに短縮できます。

  2. ビルドへの SSH 接続 - CircleCI は、 実行環境への安全な SSH 接続 機能を提供しており、ログの監視、ファイルの操作、および各環境と直接やり取りすることが可能です。 これは、失敗したビルドのデバッグに非常に役立ちます。

  3. リソースクラス - プラットフォーム上でさまざまなサイズの Executor を使用することができ、Node 上のワークロードの大きさに応じた調整に最適です。

  4. テストの並列実行 - CircleCI のプラットフォームは、 ジョブの同時実行 だけでなく、並行環境間でテストを分割する機能も備えています。 ワークロードを異なるコンテナに分割することで 、ビルド時間を大幅に短縮することができます。

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

コンセプト

ジョブとワークフロー

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

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

GitHubCircleCI
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: 12.5.1

# 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 でご利用いただけます。 ご協力いただき、ありがとうございます。

サポートが必要ですか

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

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