アジャイル開発ではスプリントを決めて開発を行い、修正を都度対応する必要があるため、スピード感を求められる開発現場が多い。
そのため、継続的インテグレーション（CI）や継続的デリバリー/継続的デプロイ（CD)を導入し、マージやデプロイのコストを下げ、効率的な開発を実施したいが、初期導入コストや学習コストなど様々な観点から実施が見送られるケースも少なくない。
今回はCI/CDを学習し、プロジェクトに対して現実的に導入する際のメリット・デメリットに関して言及していきます。
GitHub Actions でCIテスト・デプロイハンズオン
1. CI/CDとは
まず前提としてCI/CDとは何かについて言及します。
CI/CDとは前述のとおり、継続的インテグレーション/継続的デリバリー・継続的デプロイの略で、アプリケーションのリリースサイクルにおいてビルドやテストなどを自動化し、 継続的に実行することで品質改善や納期短縮を実現するための方法（CI）と、CIを進めてユーザーに製品を届けるまでのリリースプロセス全体を自動化し、 継続的に顧客に価値を届けることを目的とした方法（CD）の総称です。
#1. 継続的インテグレーション、継続的デリバリとは
細かい点は上記の記事を参照してください。
要するにコードをコミットするとビルドが走り、ユニットテストを実行後、コードがテスト環境にデプロイされます。
その後結合テストやシステムテストを行い、必要であれば承認後、本番環境にデプロイされるという仕組みの総称です。
2. GitHub Actions
上記を踏まえたうえで、GitHub Actionsを利用してみます。
GitHub Actionsとは GitHub が提供する CI/CD プラットフォームで、複数の Action を組み合わせることで、 さまざまなワークフローを自動化できるようになっています。
#1.1 GitHub Actions とは
publicなリポジトリであれば制限なく利用できるそうなので、publicでリポジトリを作成しました。
github actions では一連の処理を workflow と呼びます。
まず、サンプルの単純なworkflow を実施してみます。
ダッシュボードのリストからActionを選択すると、github actionの画面が開かれます。
＜br＞
こちらのSimple Workflowを選択すると、エディタが開き、Yamlファイルが表示されます。
こちらをそのままCommitします。
Commit ChangesからCreate a new branchを選択するとpropose changesと表示されるので、こちらでコミットを作成します。
その後はブランチが作成されるので、そちらをプルリクエストすると、Actionタブの表示が変わっています。
workflowが作成され、テストが実行されています。
こちらが成功すると左側のアイコンが緑色に変更され、テストがすべてOKだったことが担保されます。
GitHub Actionsとは GitHub が提供する CI/CD プラットフォームで、複数の Action を組み合わせることで、 さまざまなワークフローを自動化できるようになっています。
#1.1 GitHub Actions とは
publicなリポジトリであれば制限なく利用できるそうなので、publicでリポジトリを作成しました。
github actions では一連の処理を workflow と呼びます。
まず、サンプルの単純なworkflow を実施してみます。
ダッシュボードのリストからActionを選択すると、github actionの画面が開かれます。
＜br＞
こちらのSimple Workflowを選択すると、エディタが開き、Yamlファイルが表示されます。
こちらをそのままCommitします。
Commit ChangesからCreate a new branchを選択するとpropose changesと表示されるので、こちらでコミットを作成します。
その後はブランチが作成されるので、そちらをプルリクエストすると、Actionタブの表示が変わっています。
workflowが作成され、テストが実行されています。
こちらが成功すると左側のアイコンが緑色に変更され、テストがすべてOKだったことが担保されます。
3. 文法
ここまででgithub actionでsimple work flowを作成する手順はわかりました。
しかし、実際何が行われているかは全くわかりません。
なので、先ほどのデフォルトのyamlファイルに何が記載されているのか確認していきます。
まず、name CIについてですが、こちらはこのworkflowの表示名になります。
次に、onですが、こちらはworkflowがどのような条件で実施するかというものになります。
現状だと、pushとpull_requestがbranch[‘main’]の時にworkflowが実施されるようになっています。
次にworkflow_dispatch
しかし、実際何が行われているかは全くわかりません。
なので、先ほどのデフォルトのyamlファイルに何が記載されているのか確認していきます。
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "main" branch
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# 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@v3
# 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 CIについてですが、こちらはこのworkflowの表示名になります。
次に、onですが、こちらはworkflowがどのような条件で実施するかというものになります。
現状だと、pushとpull_requestがbranch[‘main’]の時にworkflowが実施されるようになっています。
次にworkflow_dispatch
4. 終わりに
これでおおよそのCIの書き方と実行の流れは把握できました。
メリットとしてはテストの実行漏れを防ぐことができる、デメリットとしてはテストが成功するまで時間がかかる、初期設定にGithubAction独自の記述を覚えなければいけないといったところでしょうか。
速度については設定方法で高速化を図ることができるかもしれないので、導入のメリットの法が大きいなあという印象です。
次回は実際の案件でどのように設定するべきかなどを考察していきたいと思います。