【パイプライン入門】GitHub Actionsを用いたCI/CD環境の構築

1.CI/CD

1.1 CI/CDとは

CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称。CI/CDは、何か特定の技術を指すものではなく、ソフトウェアの変更を常にテストし、自動で本番環境に適用できるような状態にしておく開発手法のことをいう。
https://www.sbbit.jp/article/cont1/81640

CI/CDとは上記の説明にある通り，ある開発手法のことを指しており，下の図がCI/CDのイメージになります．

また，下の図のように，CIはソフトウェアのビルドやテストを自動化して頻繁に実行することでソフトウェアの品質向上や開発効率化を目指す手法で、CDはCIに加えてデプロイまでも自動化する手法です．

1.2 なぜCI/CDツール必要なのか

まず開発に対する考え方の一つにウォータフォール開発というものがあります．これは，プロジェクトの最初の入念な設計と計画を重要視するというもので，各工程の進捗状況が把握しやすく、スケジュール管理がしやすいといった利点があります．

しかし，変化への柔軟な対応や高速なリリースに課題を抱えており，そこでアジャイル開発といった考え方が発展してきました．アジャイル開発では，開発時に発生する変更に柔軟な対応をする，顧客も交えた密なコミュニケーション，変更単位を小さくし継続的なプロダクトへの反映などがウォータフォール開発との大きな違いになります．

しかし，アジャイル開発ではリリース回数の増加に伴い，テスト・ビルド・デプロイといった、コーディング以外の作業にかかるコストが増大するといった課題を抱えることになります．

このような課題を解決するためには，一連の作業を自動化し，人手を介さず継続的に行えるようにすることが重要です．そして，そのための手法として活用されているのが「CI/CD」です．

	長所	短所
ウォータフォール開発	進捗状況，スケジュールが管理しやすい．	変化への柔軟な対応，高速なリリースが課題
アジャイル開発	変化に柔軟に対応できる，高速なリリースが可能	コーディング以外の作業 (テスト・ビルド・デプロイ) にかかるコストが増大

2. GitHub Actionsについて

2.1 Gitとは

　Gitとは，分散型バージョン管理システムの一つで、ファイルの状態を好きなときに更新履歴として保存しておくことができます．そのため，一度編集したファイルを過去の状態に戻したり，編集箇所の差分を表示したりすることができます．

　ここでGitには，２種類のリポジトリがあり，それぞれリモートリポジトリとローカルリポジトリといいます．

リモートリポジトリ：複数人で共有するためのリポジトリ
ローカルリポジトリ：一人で使用するための，自分の手元におくリポジトリ

普段は自分のローカルリポジトリで作業を行い，作業した内容を公開したい場合に，リモートリポジトリにアップロードして公開します．また，リモートリポジトリを通して他の人の作業内容を取得することができます．

そして，GitHubはデータの貯蔵庫であるリポジトリをインターネット上に提供しているサービスのことを指します．

2.2 GitHub Actionsとは

GitHub ActionsはGitHubが提供しているCI/CDツールです．これはリポジトリへのpushやpullといった操作，もしくは指定した時刻になるといったイベントをトリガーとして，あらかじめ定義しておいた処理を実行する機能を持っています．

これによって，リポジトリにコミットが行われた際に特定の処理を実行したり，毎日決まった時刻に特定の処理を実行したりする，といったことを実現できます．

他のCI/CDツールであるAWS code BuildやGCP cloud buildと比べて，GitHub Actionsを用いる利点としては，主に2つあります．

●GitHubとの高い統合性

GitHubを用いてバージョン管理や開発を行っている場合，設定ファイルを追加するだけでCIが自動的に走り，初期設定が不要になります．

●ディレクトリ単位で処理を指定できる

ディレクトリ単位でCIを行うかどうか判定できます．そのため，様々なサービスが一つのレポジトリにある場合に，サービスごとにレポジトリを分ける必要がなくなります．また，ブランチを指定することもでき，ある特定のブランチにpushが行われたときにのみCIを行うといったことも可能です．

また，料金についても従来GitHubの有料プランを使っていた人は追加投資0で利用できることも，GitHub Actionsが広く用いられている要因の一つになります．

3. GitHub Actionsの使い方

では，実際にGitHub Actionsを使ってみたいと思います．

3.1 セットアップ

まず，以下のようなREADME.mdのみのリポジトリを用意します．

次に，Acitonsのタブへ移動すると以下のような画面になります．今回は，Simple workflowを使用します．

すると，以下のようなワークフローファイルが表示されます．

そこで，次にこちらのワークフローファイルを説明していきます．

3.2 ワークフローファイル

まず以下のmainの部分をクリックするとどのブランチに対してActionするかを選ぶことができます．

ワークフローを実行するトリガーを指定．

以下のようになっている場合，mainブランチにpushがあった際にワークフローが実行されます．

workflow_dispatch

Actionタブからワークフローを実行可能にするかどうか．

jobs

ワークフローで行うジョブを指定．

build

ジョブの名前を定義したもの．buildでなくても良い．ex)task1 など．

runs-on

ワークフローが実行される仮想環境．以下から選ぶことができる．

steps

一連のタスクのこと．

ステップでは、コマンドを実行したり、セットアップタスクを実行したり、リポジトリで公開されたアクションを実行したりできます。

uses

使用するライブラリを指定．

name

GitHub上に表示されるジョブの名前.

run

OSのシェルを使用してコマンドラインプログラムを実行する．

他にも様々な機能があるので，詳しくはこちらのサイトを参照してください．https://docs.github.com/ja/actions/using-workflows/workflow-syntax-for-github-actions

3.3 起動確認

ここでは，「Hello World!」と出力したいため，以下のようなワークフローファイルを作成します．

こちらをcommitします．すると，以下のようにワークフローフォルダーが追加されたことが確認できます．

また，ワークフローフォルダーの中には，先ほど作成したhelloworld.ymlファイルが格納されていることが確認できます．

では，ワークフローを実行していきます．helloworld.ymlではworkflow_dispatchを指定しているため，以下のようにまずActionタブを開き，次に「Hello World」ワークフローのRun workflowというボタンをクリックして実行します．

すると以下のような結果が出力されます．

左横に緑のチェックがついたので無事成功したようです．

4. GitHub Actionsを用いたデプロイフロー

では，GitHub Actionsを用いるとどのようなデプロイの流れになるかを説明します．

まず以下のような流れで本番環境へデプロイされているとします．

するとGitHubActionsを用いることで，pushがあれば仮想環境でビルドとテストを行い，それが成功し，pull requestが承認されれば本番環境にmergeするというところが自動化できます．以下の黄色の部分が自動化される部分になります．

このようなGitHub Actionsを用いたデプロイフローを構築することで，手動でのデプロイにおける問題点である①本番デプロイの度に作業人数✕デプロイ時間が必要，②手順確認等でデプロイ時間が必要，③確認ミス等でデプロイが失敗する，場合によっては本番環境を壊してしまう可能性ある，などを解決することができます．