Bullet Group Advent Calendar 2020 21日目の記事です。

どーも皆さまお久しぶりです！Technology Department(開発部)でインフラ周りを担当している山口です！

今年もあと10日で終わりますね。。。皆さんは今年どんな年だったでしょうか？今年はコロナでいろいろ大変だった中、個人的には子供が誕生して喜ばしい一年ともなりました！来年は東京オリンピックも開催予定（あるのかな？）ですし、コロナの状況も気になりますが、今年よりもさらに良い一年になることを期待して過ごしております！

さて今回はCI/CDサービスの一つでありますGithub Actionsを触る機会がありましたのでこちらについてご紹介していきます！

CI/CDとは

とその前に簡単にCI/CDについて少しだけ触れたいと思います。
リリースを短期間で行うために開発スピードもそうですが、テストやデプロイなどの運用の部分の効率化を図らなければ品質を担保したまま世の中に素早くサービスを提供することが難しいです。そこを解決するCI/CDという技術的なプラクティスがあります。

簡単に説明しますと、CI（継続的インテグレーション）とはリポジトリに対して変更がかかるタイミングで自動的にテストやビルドを実行されるような仕組みのことで、CD（継続的デリバリー）は自動でテストやビルドが完了後、アプリケーションがいつでもリリース可能な状態にする、つまり自動でデプロイ可能にする仕組みのことです。

これらのCI/CDを行うサービスはいくつも存在しており代表的なものでいうとJenkins、CircleCIやTravisCIなどが挙げられますが、そのサービスの中の一つでありますGithub Actionsをご紹介します。

Github Actionsとは

続いてGithub Actionsについてですが、その名の通りGithubが提供しておりGithub自体に組み込まれているCI/CDサービスです。
ベータ版が2018年に限定公開され、GitHub社がMicrosoftに買収後の2019年にGAとなりました。現在では機能も充実してきたということで注目が高まってきました。

特徴

特徴としてまずGithubとの親和性が高い点です（そりゃそうだろと思いますがw）。他のCI/CDサービスではpushイベントによるCI/CDがメインで、他のイベントはサポートがほとんどされておらずイベント発生時に自動で実行するように自前でその機構を構築する必要性がありました。しかし、Github ActionsはGithubに関わる様々なイベントに対応することが可能であり容易にCI/CD環境を構築することが可能です。あと、Githubで完結しますので管理という観点でも非常に良いですね。

また、料金的にも安価という点です。パブリックリポジトリは無制限で、プライベートリポジトリでもFreeプランであれば2000分/月とのことで他サービスと比較しても利用障壁は低く検証もしやすいです。

さらには自由度が高い点です。GitHubホストランナーとして利用されるVMはMicrosoftAzureのStandard_DS2_v2サイズのものを使用しておりスペックは以下の通りです。

vCPU:2
メモリ:7GiB
SSD:14GiB

上記以外でもセルフホストランナーという機能があり、ユーザー側で独自に実行環境を用意してカスタマイズ性やセキュリティを強固にした状態でCI/CDを実行することも可能なのでユーザーにとっては嬉しい機能ですね。

触ってみた

それではいよいよ触ってみます。まずはどこで設定や実行結果が確認できるかというとGithubのリポジトリのActionsタブからが確認することができます。

Github Actionsはワークフローという単位で構成されYAMLファイルで作成します。このファイルをリポジトリの.github/workflowsディレクトリに保存する必要があります。

基本的には目的別でワークフローのテンプレートや、アクション等を活用しながらワークフローを作成していきます。
アクションとは様々な一連の処理がパッケージされたもので、GitHub Marketplaceから検索して利用も可能ですし自作することも可能です。

今回は下記のデフォルトで提供されるワークフローのテンプレートを元に説明していきます。
また、今回登場する用語やテンプレート内で使用している構文について、簡単に表にまとめましたのでワークフローファイルの構成を確認する際にご参考いただければと思います。

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the master branch
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world!

      # Runs a set of commands using the runners shell
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

簡単な用語集

用語	内容
ワークフロー	何らかのプロセスを実行する最小単位
ジョブ	ワークフロー内で実行する処理のまとまり
ステップ	ジョブ内で実行する処理
アクション	ステップ内で実行する処理がパッケージされたもの

今回使用するワークフロー構文集

構文	内容
name:	各工程の名前設定
on:	トリガーとなるイベント設定
push:	pushイベント
pull_request:	プルリクエストイベント
branches:	対象のブランチ指定
workflow_dispatch:	手動実行設定
jobs:	ジョブの設定
build:	ジョブ名（任意のもので良い）
runs-on:	実行環境の指定
step:	ステップの設定
uses:	アクションの呼び出し
run:	コマンド実行

on:はワークフローを実行するトリガーとなるイベントを設定します。
今回はmasterブランチへpush、pull_requestを行うとワークフローが実行されます。また、各種イベントだけでなくworkflow_dispatch:を使用すれば手動で実行も可能です。

続いて、１つのワークフローは１つ以上のジョブで構成されます。jobs:で処理させたいジョブを構成します。そのジョブはruns-on:で指定した環境で実行されます。
また、self-hostedを指定してセルフホストランナーを利用して独自に用意した環境にて実行することも可能です。
さらに、runs-on:でなくcontainer:を指定することによってコンテナ上でも実行することも可能です。

さらに、ジョブの中にsteps:と呼ばれる一連のタスクがあります。ステップではrun:でコマンドを実行したり、uses:でアクションを呼び出したりします。

今回はubuntu-latestを指定しているためUbuntuの仮想環境内で実行されることとなり、ジョブの動きとしてはactions/checkout@v2のアクションを使用してVM上にリポジトリをチェックアウトして、echoコマンドで文字列を出力するというシンプルなジョブとなっております。

on:で設定していたイベントによって自動的にワークフローが実行されます。成功するとコミットメッセージの隣に緑のチェックが表示されます。