GithubActionsでCI環境構築してみた

2020年5月25日 13:39

こんにちは、テスト自動化アーキテクトの若木です。

今回は、SHIFTが得意としている領域の1つ、テストの自動化よりCI環境の構築についてご紹介します。

CI環境構築とは

テスト自動化には大きく3つのステップがあります。
• テスト設計
• テストスクリプト作成
• CI環境構築（←今回のお話）

テスト自動化におけるCI環境構築とは、自動でテストを実行する環境を指すことが多いです。
「テストスクリプト作成」で作成したソースコードはそれ単体では動かないので、自動で実行する環境を用意してあげる必要があります。
テストを自動実行することで開発中のプロダクトの品質を担保し、安全にソースコードをマージすることが出来るようになります。
こうした一連の流れをContinuous Integration（継続的インテグレーション）と呼び、こうした環境を構築することを、そのイニシャルからCI環境構築と呼びます。

CIツールとは

CI環境構築と一言で言っても、ゼロから作り始めるわけではありません。
DAAE（※1）の一つにもあるように、既存のツールをAssembleして構築することがほとんどです。
それらツールの中でも特にCIの中核的な役割をもつツールをCIツールと呼びます。

CIツール言えば、SHIFTの技術顧問でもある川口耕介氏が開発したJenkinsが有名でした。
しかしながらその運用はオンプレサーバを基本としており、近年主流となっているクラウド化の流れからは外れつつあります（オンプレよりもクラウドが優れているという話ではないですよ）。
クラウドサービスとして様々なCIツールが提供されるようになった昨今では、様々な方向性にそれぞれ特化したツールを利用者が選定して、ニーズに合わせたCI環境構築ができるようになりました。

（※1）DAAE … SHIFTが提唱するQCDに変わる概念。DAAEはDesign, Agility, Assembly, Economic-qualityのイニシャルである。行動経済成長期の製造業の作れば作るだけモノが売れる大量生産の時代（QCDの時代）から、モノが大量にあふれ、エンドユーザーがモノを選択する時代に変化している。そんな中で圧倒的に成功している企業はエンドユーザーに提供する価値の最大化に努めており、その価値の指標としてDAAEが提唱された。

GitHub Actionsとは

GitHubは、VCS（Version Control System）と呼ばれるプロダクトのソースコードの変更履歴を管理するGitというツールを利用した世界最大規模のWebサービスです。
ここでは「めちゃめちゃ便利で世界中の開発者がこぞって利用するWebサービス」くらいに考えてください。

世界最大規模の開発者向けサービスということもあり、様々な開発ツールとの連携も容易にできるようになっており、CIツールとの親和性も高いものでした。
そんなGitHubが2019年11月に、標準CI/CDサービスとして正式リリースしたものがGitHub Actionsです。

GitHub ActionsでCI環境を構築する
前置きが長くなりましたが、ここからが本題です。

設定ファイルの構成

近年主流となっているクラウド型CIサービスは基本的に設定ファイルを書くだけで環境構築が済んでしまいます。。
大抵はyaml形式で設定を書き込むことになります。
GitHub Actionsの設定ファイルは大きく分けると以下のような構成になっています。

#ワークフローの名前（省略可）
name: workflow_name

#ワークフローのトリガー
on: trigger
  
#ジョブ（具体的に何をやるか）の設定
jobs:
 #ジョブの名前
 job_name:
　  #実行マシンの指定（基本的にGitHubのVMで動作します）
   runs-on: ubuntu-latest
　  #決められた形式でタスクを指定
   steps:
　    #usesで公開されているタスクが使用可能
   - name: テストコードのチェックアウト
     uses: actions/checkout@v1

   - task1: hogehoge
   - task2: fooooooo!
（以下略）

具体的なトリガーやタスクの設定方法は公式ドキュメントやGitHub Marketplaceを参照してください。

作成した.ymlファイルはリポジトリ直下の.github/workflowsに配置することでワークするようになります。

設定ファイルの記述例

以下にSHIFTの自動化のフレームワークであるRacineを動かす設定を例として記載します。
ただし、実行にdocker-composeを利用していたり、標準フォーマットからはややはみ出ていますので、Racine側もそれに合わせて修正する必要があります。
参考時にはその点にご注意ください。

name: Test Run

on:
 repository_dispatch:
   types: [Test-Run]
 schedule:
   - cron: "10 0 * * *"

jobs:
 build:
   runs-on: ubuntu-latest
   env: 
     TEST_CASE: jp.shiftinc.automation.demo.scenarios

   steps:
   - name: テストコードのチェックアウト
     uses: actions/checkout@v1
   
   - name: テスト環境構築
     run: |
       docker pull selenoid/vnc_chrome:80.0
       docker-compose up -d
       sleep 10s
       docker ps -a
   
   - name: JDK 1.8のセットアップ
     uses: actions/setup-java@v1
     with:
       java-version: 1.8
       
   - name: E2Eテスト実行
     run: |
       cd pc
       chmod +x ../master/gradlew
       ../master/gradlew \
       clean test --tests --continue $TEST_CASE.DemoTest allureReport

   - name: Allure Reportの出力
     uses: actions/upload-artifact@v1.0.0
     with:
       name: allure-report
       path: pc/build/reports/allure-report

最後に

以上、「GitHub ActionsでCI環境構築してみた」でした。
設定ファイルを作成するだけでCI環境構築できるので非常に楽です。
こうした特徴はGitHub Actionsだけでなく、CircleCIやAzure DevOpsにも共通しており、これらを使用する際には上記の設定方法が参考になるかと思います。

Jenkinsは使用に際して色々と作りこみが必要になるので、属人化しやすいというデメリットがありますが、最近のCIツールは設定ファイルひとつで済むので属人化しづらいというメリットがあります。
もちろんJenkinsには、豊富なプラグインを利用することで完全に自身の環境にフィットしたCI環境構築ができるといった強みもあります。
弊社では様々なCIツールを利用することで、お客様に最適な自動テスト環境を整えることが可能となっております。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

最後まで読んでくださり、ありがとうございます！

御社サービスのご相談はお気軽に。

ソフトウェア品質のプロがお伺いします。