開発作業を効率化し、負担を減らすために、CI/CDの導入は重要なツールです。この記事では目の前の作業に追われ、重要とわかっていてもなかなか導入できていない人を対象に、GitHub ペースの CI/CDツール「GitHub Actions」を使ったCI/CDの始め方を説明します。マスターして開発速度向上を目指しましょう！

データサイエンスを基礎からもっと詳しく学びたい方はこちらがおススメです。ディープラーニングやビックデータ分析のカリキュラムがあり、受講後のデータサイエンス系高額案件に有利になるからです。無料体験だけでも勉強になりました。

Last updated 1 day ago

第1特集ここから始める時短(開発)

GitHub Actions で簡単・快適CI/CD
1. GitHubベースの高機能な自動化ツールを体験しよう
CI/CDとは何か、なぜCI/CDが必要なのか
GitHub Actionsとは?
1. GitHub Actionsの概要
GitHub Actionsの主要概念
1. イベント
ワークフローと主要な構成コンポーネント
1. ワークフロー(Workflow)
2. ジョブ(Job)
3. ステップ(Step)
アクション(Action)
1. アクションの種類
ランナー(Runner)
1. GitHubホスト型ランナー
2. セルフホスト型ランナー
GitHub Actionsの始め方
GitHub Actionsで簡単・快適CI/CD
GitHub Actionsによる) : 自動化を体験
CIパイプラインを構築する
1. 事前準備
  1. リポジトリの作成
  2. サンプルコードの用意
ワークフロー作成
フロー実行
ローやタスク実行をすべてGitHubで効率化
複数ジョブの実行パターン
1. Build Matrix
ワークフロー内のデータ共有
1. ステップ間のデータ共有
2. ジョブ間のデータ共有
キャッシュの活用
Environmentsを活用した複数環境のデプロイメント管理
1. Environmentsによる複数環境
2. ジョブ実行の承認者の設定
lacとCI/CDによるインフラ構成管理の自動化
GitHub ActionsによるlaCツール活用例
GitHub Actionsによる細かいタスクの自動化
CIの処理結果をPull Requestのコメントとして投稿
変更ファイルのバスに基づくPull Requestへの自動ラベル付与
おわりに

GitHub Actions で簡単・快適CI/CD

GitHubベースの高機能な自動化ツールを体験しよう

CI/CDEFGitHub Actionsをオススメする理由
豊富な機能と拡張性を兼ね備えた次世代自動化ツール
GitHub Actionsによる自動化を体験
ビルドテストデプロイを行うCI/CDバイプラインを構築
さらに自動化を進めるために知っておきたいこと
開発フローやタスク実行をすべてGitHubで効率化

ここから始める時短開発
GitHub Actionsで簡単・快適CI/CD
GitHubベースのIT高機能な自動化ツールを体験しよう

CI/CDにはGitHub Actionste オススメする理由

豊富な機能と拡張性を兼ね備えた次世代自動化ツール
第1章では、GitHub Actions を利用するうえで押さえておきたい基礎事項を解説します。CI/CDの定義を取り上げ、GitHub Actionsの概要、主要概念、そしてGitHub Actionsの始め方を説明します。実際の使い方を学ぶ前にまずは基礎をしっかり固めましょう。

CI/CDとは何か、なぜCI/CDが必要なのか

CI/CDとは、それぞれ

Continuous Integration (継続的インテグレーション)
Continuous Delivery(継続的デリバリー)もしくはContinous Deployment(継続的デプロイメント)を合わせた用語です。

CIはコードの変更を起点にコードの静的分析、ビルド、テストなどを自動実行することを意味します。

一方、CDはコードやビルドされた成果物をプロダクトへ自動反映させることを意味します。

CI/CDは、このCIとCDを組み合わせて、一連のソフトウェア開発のライフサイクルにおける処理を自動化することを指します。

これにより、テストやリリース作業から属人性を排除し、人間に起因するミスが防止されます。

そして、その結果、品質が担保され、コード更新からプロダクト反映までのリードタイムの短縮化もできます。

CI/CDは、開発、テスト、リリースというサイクルを回して市場への継続的な価値の提供を目指す、DevOpsの文原でよく話に登場してきますが、まさに、DevOpsの実践に不可欠な手法と言えます。

GitHub Actionsとは?

GitHub Actionsの概要

GitHub Actions は、コードのビルド、テスト、パッケージ、リリースなどソフトウェア開発のライフサイクルにおけるワークフローの自動化、迅速化を可能にするCI/CDサービスです。2019 年11月に正式版がリリースされたばかりで、ほかのCI/CDツールと比較すると歴史が浅いものです。しかし、急速に進化を続けており、シンブルかつ豊富な機能と拡張性、そしてGitHub との親和性の高さという利点もあって、リリース以来、多くのユーザーの支持を得ている次世代自動化ツールと言えます。なお、本稿に記載した内容は2021年12月時点の情報です。
GitHub Actionsの代表的な特徴に次のようなものがあります。
・GitHubとの親和性:自動化されたワークフ
ローをGitHubリポジトリに直接作成可能・豊富なジョブ実行環境の選択肢:Linux、 macOS、Windows それぞれの仮想マシンが GitHubホストで提供されており、仮想マシン上のDockerコンテナ内でも直接実行可能・豊富なワークフローの実行トリガー:リポジトリで発生するすべての操作イベントのトリガーが提供されており、スケジュール実行や外部イベントをトリガーにしたワークフローの実行も可能・充実した基本機能:シークレット情報を扱うためのしくみ、ワークフローでのArtifact(成果物)を保存・取得するしくみ、ワークフローで利用する依存データをキャッシュするため

のしくみなどを提供・豊富なアクションの選択肢と充実したエコシステム:公開済みのGitHub公式アクションやコミュニティ提供のアクション、自分で作成したアクションをワークフローで簡単に利用可能
GitHub Actionsの利用料金
パブリックリポジトリや、後述するセルフホストランナーでの利用は無料です。
プライベートリポジトリの場合、ストレージ使用量とジョブ実行時間が一定量まで無料で利用可能な枠がありますが、それを超えると従量課金となっています。この無料枠の量はアカウントの種類によって異なります。また、ジョブ実行時間に対する従量課金は利用OSによって時間あたりの課金額が異なります。Linuxを基準とした場合、Windowsは2倍、macOSの場合は10倍と差があるので注意が必要です。
・無料枠の例:GitHub無料アカウントの場合、
注1)参考リンク:GitHub Actionsの支払いについて URL https://docs.github.com/ja/billing/managing
billing-for-github-actions/about-billing-for-githubactions

ストレージは 500MBまで、ジョブ実行時間は2,000分/月
なお、利用料金の把握は公式に提供されている料金計算ツールがあるので、そちらをご利用ください。

GitHub Actionsの主要概念

GitHub Actionsの主要コンポーネントと、自・動化用の一連の処理を定義するワークフローの基本構造を紹介します。まず、図1がGitHub Actionsの全体の概略図です。

イベント

ワークフロー実行のトリガーとなるアクティビティのことをイベント(図1の左上部)と呼びます。GitHub Actionsはリポジトリで発生する操作イベント(Webhook)をトリガーにワークフローを実行できます。また、リポジトリで発生する操作だけでなく、スケジュールや外部イベントをトリガーにして実行したり、手動で実行したりできます。GitHub Actionsで利用可能な
イベントの詳細は、GitHub 公式ページ「Events that trigger work flows」をご参照ください。
なお、後述するワークフローを tion
定義するYAMLでは、onシンタックスを用いて、どのイベントをワー
クフローのトリガーとするのかを -b2
定義します。リスト1に示すYAML の例では、push イベントをトリガー
として定義しています。

ワークフローと主要な構成コンポーネント

ワークフローと、ワークフロー
2)unner 30511)
3)URL https://github.com/pricing/
calculator URL https://docs.github.com/ja/
actions/learn-github-actions events-that-trigger-workflows

リストワークフローYAMLの例

name: Test Workflow
on:
pushトリガー定番
jobs:
"job_one:
name: Job 1 Runner runs-on: ubuntu-20.04 steps: -name:Step1....
run: echo "cnd1" -name:Step2....
run.echo "cade... - name: Step 3
run: echo "cnd3" job_two:
name: Job 2 runs-on: macos-11
ステップ
Job 2
「定義
steps:
Runner
(.. ..)

を構成するジョブ、ステップについて、それぞれのエッセンスを説明します。

ワークフロー(Workflow)

図1の右に示す図が、ワークフローを表す概念図です。ワークフローは、1つ以上のジョブから構成され、1つのワークフローにつき、1つのYAMLファイルを用意します。トリガーとなるイベントが異なる場合、ワークフローをそれぞれ用意します。

ジョブ(Job)

ジョブとは、1つ以上のステップから構成されるタスクの定義です。ワークフローを定義するYAMLでは、jobsシンタックス下に定義します。リスト1のYAMLの例では、jobone と job twoの2つのジョブを定義しています。ジョブは後述するランナーと呼ばれるアプリケーション内で実行されます。ジョブが分割されると、それぞれ別のランナーアプリケーションインスタンスで実行されるため、ジョブ間のデータ共有を工夫する必要があります。詳細は、第3章「ワークフロー内のデータ共有」で解説します。

マリスト2ステップ定義例
jobs: sample_job:
runs-on: ubuntu-latest steps:
ステップ利用するアクションの定器 – uses: actions/checkoutav2 – uses: actions/setup-nodeav2 『ステップ:コマンドの定義(シングルライン】 – run: npm install ロステップ:コマンドの定義(マルチライン】 -run:
npmci npn build

ステップ(Step)

ステップは、ジョブの中で実行される各タスクのことです。ワークフローYAMLではjobs.job id.stepsシンタックス下に個々のステップを定義します(リスト2)。図1の右上部に示すとおり、各ステップでは、コマンドもしくは後述のアクションを実行できます。アクションは jobs.job id.stepsl".uses シンタックスで、コマンドはjobs, job_id.steps").run シンタックスで定義します。

アクション(Action)

アクションは、ステップを構成する最小の構成要素です。前述のとおり、jobs.job_id.steps", uses シンタックスで、各ステップで実行するアクションを指定します。
GitHub Actionsの特徴として、豊富なアクションの選択肢と充実したエコシステムがあります。アクションは、独自に作成したものをワークフロー内で使用したり、ほかのユーザーと共有したりできます。また、コミュニティにより作成・公開されているパブリックリポジトリのアクションを使用することもできます。また、 GitHub公式のアクションやマーケットプレイスに登録・公開されているアクションを利用し、コマンドと組み合わせることで、たいていの自動化処理を実現できます。

アクションの種類

アクションは、3つの作成方法が用意されて

表1 アクションの作成方法
|アクションの種類|
|JavaScript アクション|
JavaScriptで記述する・ランナー上で直接実行される
・言語制約:JavaScript(TypeScriptなどで記述し、その後JavaScriptにコンパイ |
ルしても可) ・起動時間:ランナー上で直接実行するため、起動が速い。・利用可能なランナーOS:Linux.macOS、Windows
アクションの内容を Dockerコンテナとしてパッケージ化する・ランナー上でコンテナを立ち上げて実行する。
・言語制約:なし(コンテナとしてOSごとパッケージ化するので、自由度が高い) 「Dockerコンテナアクション|
・起動時間:イメージをPull してからコンテナを立ち上げるため、JavaScript より
起動に時間がかかる・利用可能なランナーOS: Linuxだけ
・複数ステップの処理をバンドルし、1つのアクションとして定義・実行する Composite アクション
|・利用可能なランナーOS:Linux,macOS、Windows
▼表2 利用可能なGitHub ホスト仮想マシンのYAMLラベル仮想マシン
仮想マシンのYAMLラベル Ubuntu
ubuntu-latest, ubuntu-18.04. ubuntu-20.04 macOS
macos-latest, macos-11, macos-10.15 Windows Server
windows-latest.windows-2019_windows-2022.windows-2016

います。JavaScript アクション、Dockerコンテナアクション、Compositeアクションの3種類です。それぞれの概要、特徴は表1のとおりで
独自アクションの作成方法は、本稿では紹介しません。詳細は、下記の各GitHub公式ページをご参照ください。
・JavaScript アクション – 「JavaScript アクショ
ンを作成する」・Docker コンテナアクション – 「Docker コンテ
ナのアクションを作成する#5」 . Composite 7792-[Creating a composite action*6]

ランナー(Runner)

ジョブはランナーと呼ばれるアプリケーショ
4) URL https://docs.github.com/ja/actions/creating
actions/creating-a-javascript-action 5) URL https://docs.github.com/ja/actions/creating
actions/creating-a-docker-container-action (注6)(Dhttps://docs.github.com/ja/actions/creating
actions/creating-a-composite-action

ンにより実行されます。ユーザーは、実行環境のホスティングモデルを2種類のランナーから選択します。なお、ランナーは2019年にOSS として公開されています。

GitHubホスト型ランナー

GitHubは、ジョブ実行環境として、ランナーがすでにインストールされた仮想マシンを提供しています。この、GitHubがホスティングする仮想マシンで実行されるランナーのことを GitHub ホスト型ランナーと呼びます。ユーザーはjobs.job_id.runs_on シンタックスで、どの仮想マシンでジョブを実行させるのかをラベルで指定します。リスト1の例では、GitHub ホスト型ランナーを指定しており、Job 1 と Job 2でそれぞれUbuntu 20.04(ラベル:ubuntu-20.04)、 macOS Big Sur 11(ラベル:macos-11)を指定しています。
利用可能なGitHub ホスト仮想マシンと指定可能なYAMLラベルを表2にまとめます。なお、
7) URE https//github.com/actions/runner

最新の情報はGitHub公式ページ「サポートされているランナーとハードウェアリソース」をご参照ください。
また、GitHubホスト型の場合、ジョブ実行のたびにクリーンな仮想マシンインスタンスが提供されます。料金は、GitHubプランの無料分を超えると、分単位での従量課金となるので、ご注意ください。

セルフホスト型ランナー

ジョプはGitHub ホスト仮想マシン以外にも、・独自の環境で実行させることもできます。ランーナーを独自の環境にインストールしてGitHub Actionsと通信できるように設定することで、その環境をジョブ実行に利用できます。これは、ジョブを実行するワーカー部分を自分の環境で動かし、それ以外のすべてをGitHubに管理してもらう方式です。このように、独自環境で実行されるランナーのことをセルフホスト型ランナーと呼びます。独自環境をジョブ実行に利用するおもなメリットとしては、ハードウェア、OS選一択の自由度の高さや、ソフトウェア設定などのカスタマイズ性の高さが挙げられます。デメリットは、ランナーや仮想マシンの運用管理コストがかかる点です。
セルフホスト型ランナーの詳細は「自分のランナーをホストする」をご参照ください。

GitHub Actionsの始め方

GitHub Actionsの始め方を、順に説明します。
具体的な手順の説明に入る前に、ツールのUIをざっくり理解しておきましょう。

8) URL https://docs.github.com/ja/actions/using-github
hosted-runners/about-github-hosted-runners#
supported-runners-and-hardware-resources 9) UND https://docs.github.com/ja/actions/hosting-your
own-runners

まず、GitHubま10上で任意のご自身のリポジトリを選んでください。
すると、図2のように「Actions」というタブが表示されるので、クリックします。
そのリポジトリで、まだ何もワークフローを作成していない場合は、図3のようなスターター用テンプレート選択ページが表示されます。
ここで表示されるテンプレートは、リポジトリにアップされているコードで利用している言語によって自動的に選択されます。

なお、すでにワークフローを作成している場合は、ワークフロー一覧ページが表示されます。その際には、[New workflow]ボタンをクリックすることで、同様のテンプレート選択ページが表示されます。

テンプレート一覧ページにあるテンプレートからどれか1つ選択してください。
図4 の左側の領域のように、Webベースのワークフロー編集ページに遷移します。
なお、当然ながら、テンプレートを選択せずにワークフローを編集することも可能です。その場合は、図3の上部にある「setup a workflow yourself」を選択してください。

ワークフロー編集ページでは、図4の中央および右側のように、アクションの利用時に役に立つスニペットを簡単に取得できます。
また、このページでは、マーケットプレイスに公開されているアクションから、キーワード検索で実現させたいアクションを探しながら選ぶことも可能です。

そして、ワークフローの編集が完了したら、福集ページ上部にあるボタン[Start commit]をクリックします。すると、YAMLファイルがコミットされ、設定完了です。
注10) CD https://github.com/

テンプレートの YAMLはリポジトリ名/.github/workflows配下に保存されます。
とても簡単にワークフローを設定できることをご理解いただけたかと思います。慣れてきた

方は、このようなスターターワークフローを使うことなく、直接ワークフローマニフェストファイルを追加してもよいでしょう。なお、次章以降では、Starter-workflowからではなく、直接ワークフローを追加する流れを解説します。

ここから始める時短開発

GitHub Actionsで簡単・快適CI/CD

高機能な自動化ツールを体験しよう

GitHub Actionsによる) : 自動化を体験

ビルドテスト・デプロイを行う CI/CDパイプラインを構築
第2章では、ローカルで作成したアプリケーションのビルドテストを行う。ワークフローと、テストしたアプリケーションをコンテナレジストリにデプロイするワークフローを作って、GitHub Actions によるCI/CDパイプラインの構築を体験してみます。

本稿では、次の2種類のバイブライン1を構築します。
・CIパイプライン:簡単なGo言語アプリケーションのビルドとテストを行う、単一ジョブのワークフロー・CI/CDパイプライン:Go言語アプリケーションのテストをしたあとに、コンテナイメージをビルドし、コンテナレジストリヘpushを行う、複数ジョブのワークフロー
なお、本稿の実行環境は macOS 11. Go 1.17.1 です。

CIパイプラインを構築する

事前準備

まずは、CIバイプライン構築のために必要なリポジトリとサンプルアプリケーションのファイルを作成します。

リポジトリの作成

GitHubにテスト用のリモートリポジトリを作成します。なお、すでにテスト用リボジトリを作成済みの場合は、そのリポジトリ上で進めていただいてもかまいません。
注1)パイプラインとは一連の処理ステップであり、GitHub
Actionsにおけるワークフローのことです。

まずはWebブラウザでGitHub2にアクセスし、ページ右上の[+]ボタンをクリックします。すると、ドロップダウンメニューが表示されるので、図1のように[New repository]を選択し
次に、新規リポジトリ作成のために必要な情報を求められます。[Repository name]にリポジトリ名を入力し、[Create repository]をクリックしてください。これで、GitHub上にリポジトリが作成されます。公開範囲はデフォルトで Privateになっているので、もし公開したい場合は同入力ページの[Public]を選択してください。

サンプルコードの用意

サンプルコードをリポジトリに反映します。まずは、ローカルリポジトリを作成します。こ
2) URL https://github.com/
▼図1 ドロップダウンメニューで[New
repository]を選択する
New repository Import repository New gist New organization New project

▼図2ローカルリポジトリを作成する
ディレクトリの作成 $ skdir github-actions-cicd $ cd github-actions-cicd
ローカルリポジトリを新規作成] $ git init

こでは「github-actions-cied」というリポジトリ名にします(図2)。
サンプルで利用するファイルgo.mod(リスト 1)、main.go(リスト2、main_test.go(リスト3) を、先ほどのローカルリポジトリのディレクトリに作成・配置します。
作成したサンプルファイルを、ローカルリボジトリにコミットします。
$ git add go.mod main.go main_test.go $ git comnit -m "first comnit"
リモートリポジトリを登録し、サンプルファイルをリモートリポジトリに反映させます(図 3)。
以上で事前準備は完了です。作成したリポジトリページに Webブラウザでアクセスすると、登録したファイルが反映されていることを確認

ワークフロー作成

GitHub Actionsのワークフローを作成していきます。ローカルリポジトリの.github/work flows配下に、go.ymlというワークフローファイルを作成します(リスト4)。このワークフローは、mainブランチへのpush

VUZ 1 go.mod module github.com/7572/github-actions-cicd
go 1.17

マリスト2

main.go
package main import "fnt" func Greeting()string {
return "Hello"
func main() {
fmt.println(Greeting)
マリスト3main_test.go
package main import "testing" func TestGreeting(t *testing.D) { want := "Hello" got %3D Greeting() if want != got {
t.Errorf("got % want X9", got, want)

をトリガーに実行され、リポジトリをチェックアウトし、Go環境のセットアップ、アプリケーションのビルドとテストを行います。

フロー実行

図4のように、ワークフローファイルをリモートリポジトリの mainブランチに反映(push) します。ワークフローファイルでは、mainブランチへのpushをトリガーイベントとして定義しているので、このイベントでワークフローが実行されます。
リポジトリ名の下にある[Actions]タブをクリックすると、ワークフロー一覧ページに遷移

▼図3 リモートリポジトリを登録し、サンプルファイルをpushする
$ git branch – nain リモートの追加 soit remote add origin gitagi thub.com:アカウント名/github-actions-cicd.git,
ローカルにコミットされたサンプルファイルをリモートリポジトリに反映 $ git push u origin main

VUA
.github/workflows/go.yml
name: Go test
on: push: branches:

main
jobs: build:
runs-on: ubuntu-latest steps: #リポジトリをチェックアウト – uses: actions/checkoutav2 # GOREY1727 – name: Set up Go
uses: actions/setup-go@v2 with:
go-version: 1.17 # GOU – DEIL – name: Build
run: go build -v ./… # テストの実行 – name: Test
run: go test -V./…

▼図4ワークフローファイルをリモートリポジトリにpush
する
ローカルリポジトリにワークフローファイルをコミット。 $ git add .github/workflows/go.yml Sagit commit -m "add GitHub Actions workflow"
リモートリポジトリにpush $ git push-u origin main
するので、今回新しく実行されたワークフローをクリックします。すると、図5上のようなサマリーページに遷移します。ここで、Jobs]または視覚化グラフにあるジョブ名(ここでは build)をクリックすると、図5下の画面に遷移します。このページでは、ジョブを構成する各ステップの詳細を確認できます。
CI/CDパイプラインを人構築する

複数ジョブで構成されるワークフローを構築します。先ほど作成したリスト2をテストしたあとに、別のジョブでコンテナイメージをビルドし、コンテナレジストリにpushします。
・事前準備
今回のワークフローでは、コンテナイメージを Docker Hub 3 push L す。そのため、事前準備としてDocker Hubへのアクセスに必要なアクセストークンの取得と、そのトークンのGitHubへの登録を行います。また、コンテナイメージ作成のためのDocker fileも用意します。
3) URL https://hub.docker.com

勝Docker Hubアカウントの用意と
アクセストークンの取得 Docker Hubに移動し、[Sign Up]ページよりアカウント登録を行ってください。なお、すでにアカウントを持っている場合は、そちらをご利用ください。
Docker Hubアカウントを作成したら、 Docker Hubにログイン後、[Account Settings]→[Security]ページより、アクセストークンを作成してください。このトークンは、 Docker CLI LOV-15 Docker Hub 7 クセスする際に必要なものです。なおアクセス権限(Access Permission)は[Read, Write, Delete]を選択してください。アクセストークン作成に関する詳細は公式ドキュメントをご参照ください。
アクセストークンをGitHubにシークレットとして登録 GitHub Actionsでは、トークンやパスワードなどのシークレット情報を安全かつ簡単に扱えるしくみを提供しています。シークレットは、リポジトリの[Settings]タブ→[Secrets]から股
4) URL https://docs.docker.com/docker-hub/access
tokens/

マリスト5 Dockerfile
FROM golang: 1.17.1-buster AS builder ARG VERSION=dev WORKDIR /go/src/app COPY main.go. RUN go build -o main main.go FROM debian:buster-slim COPY — fron-builder /go/src/app/main /go/bin/nain ENV PATH="/go/bin:$CPATH" CMD ["main")

定できます。ここでは、
・アカウント名:DOCKER_USERNAME ・アクセストークン:DOCKER_PASSWORD
をシークレットとして登録します(図6)。
なお、設定したシークレット変数は、ワークフローから5{ secrets.シークレット変数名 }} としてアクセスできます。
Dockerfile コンテナイメージを作成するためのDocker fileを用意します。ファイルの内容はリスト5のとおりです。
先ほどと同様に、Dockerfileをローカルリボジトリにコミットし、リモートリポジトリに反映させます(図7)。

¥97 Dockerfileをリモートリボジトリにpushする
S git add Dockerfile S24git conmit -n "add Dockerfile".
ローカルにコミットされたDocker fileをリモートリポジトリに反映] $ git push-u origin main
|
ワークフロー構築
以上の手順で必要なファイルの用意ができたので、ローカルリポジトリの.github/workflows 配下に、go-deploy.yml というワークフローファイルを作成します(リスト6)。
リスト6のワークフローは、VN.N.N(N = 0~ (9)形式のバージョンタグによる push イベントを

トリガーに実行されます。
deploy ジョブは、jobs.job_id.needsシンタックスでtestを指定しているので、test ジョブのあとに実行されます(needsについての詳細は、第3章「複数ジョブの実行パターン」で解説します)。 test ジョブにて、Go言語アプリケーションのテストが通ったら、deploy ジョブでコンテナイメージをビルドし、コンテナレジストリ (Docker Hub)にpushします。
注5)リスト6で使用しているBuildKitはDocker18.09以降に組
み込まれており、有効化することでイメージを高速かつ安全にビルドできるようになります。BuildKitを有効化したイメージビルドに関する詳細は「auid images with Buildkit」が参考になります。 UND https://docs.docker.com/develop/develop-images/
build enhancements/

Vu6
.github/workflows/go-deploy.yml
name: Go deploy on: push: tags:

" ..*"
jobs: test:
runs-on: ubuntu-latest steps: – uses: actions/checkoutav2 – name: Set up Go
uses: actions/setup-goav2 with:
go-version: 1.17 – name: Test
run: go test -v ./…
deploy:
runs-on: ubuntu-latest 8 needs TASTE. Sccutesty 70XIT needs: test steps: ロリポジトリをチェックアウト – uses: actions/checkoutav2 # *-ZELKI BuildKits – name: Set up Docker Buildx
uses: docker/setup-buildx-actionav1 # 18-YDELFpush – name: Build and push Docker image run:
TAG=$(echo $GITHUB REF | grep – "[0-9][¥.).") DOCKER_IMAGE=SCC secrets.DOCKER_USERNAME}}/greeting: STAG
docker login –usernane $CC secrets.DOCKER_USERNAME )) –password $CC secrets. 7 DOCKER_PASSWORD })
docker build -t $DOCKER_IMAGE. docker push $DOCKER_IMAGE

Docker Hubへのアクセスに必要なユーザー名とアクセストークン情報は、ともにGitHubのシークレットとして管理しています。それぞれワークフローの中で、{{ secrets.DOCKER _USERNAME }}と { secrets.DOCKER_PASS WORD}}で値を参照しています。
そしてpush されたタグ名(U.N.N.N)からい以外の部分を抜き出し、コンテナイメージタグとして設定します。
ワークフロー実行
前述のとおり、ワークフローはvN.N.N(N =3 0~9)形式のバージョンタグによるpush イベントをトリガーとしています。ここでは、v0.0.1

のイメージタグをpushし、ワークフローを実行します。
$ git tag -a v0.0.1 -m "v0.0.1" $ git push origin v0.0.1
コマンドの実行後に、ワークフローの実行結果を確認していきます。今回実行されたワークフローのサマリーは図8上のようになっており、 test ジョブと deploy ジョブが直列に実行されたことがわかります。先ほどと同様に、ジョブ名 (ここでは deploy)をクリックすると図8下のように、ジョブを構成する各ステップの詳細が確認できます。50

ここから始めるの夏開発) 21a GitHub Actions Gi
01高機能な自動化ツールをプで簡単・快適CI/CD 体験しよう。 030

動化を進めるために知っておきたいこと

ローやタスク実行をすべてGitHubで効率化

第3章では、GitHub Actions の本格導入を考えるうえで知っておきたい。機能や使い方を紹介します。効率的なCI/CDパイプラインの作り方や構成管理ツールとの組み合わせ、細かな開発作業の自動化に至るまで、 GitHub ベースのさまざまな作業を時短できることがわかるでしょう。

効率的なCI/CDパイプライン構築に必要な基礎知識

複数ジョブの実行パターン

ここでは複数ジョブの実行パターンについて解説します。
リスト1のように複数ジョブが定義されている場合、デフォルトでは、各ジョブは図1のように並行で実行されます。
ところが、並列実行ではなく、たとえばコードのビルド・テストを行うジョブのあとにデブロイを行うジョブのように、直列で複数ジョブを実行したいケースもあります。その場合、jobs. job_id.needstシンタックスを使うことで、ぼ
1) URL https://docs.github.com/en/actions/learn-github
actions/workflow-syntax-for-github-actions #jobs job_idneeds
マリスト1 複数のジョブのデフォルト定義の例
on: push jobs: job_a:
runs-on: ubuntu-latest steps:
(….】 job_b:
runs-on: ubuntu-latest steps:
job_c:
runs-on: ubuntu-latest steps:

かのジョブに対する依存関係を定義できます。リスト2では、jobs.job_id.needs シンタックスを使い、Job A、Job B、JobCを直列実行するように定義しています(図2)。
なお、当然ながら直列実行と並列実行を組み合わせることで、リスト3のようなFan-out/ Fan-inパターン2によるジョブ実行フローも定義できます(図3は実行イメージ)。よく利用される例としては、複数OS環境における並列ビルドジョブ(Fan-out)が完了したら、その成果物をリリースジョブでまとめてリリース(Fanin)するケースが挙げられます。

Build Matrix

複数のOSやプラットフォーム、言語バージョンなど、設定オプション別のジョブを実行する
注2) メッセージング処理でよく登場するデザインパターンです。
ある共通の送信元から複数のターゲットに対してメッセージが並列で配送、拡散されることをFan-out.それらがすべて完了したあとに共通の処理が実行されることをFan-inと呼びます。

マリスト2 jobs.job_id.needsによる直列実行の例
on: push jobs: job_a:
runs-on: ubuntu-latest steps:
job_b:
needs: job_a R TDEA runs-on: ubuntu-latest steps:
job_c: needs: job_b S TORA runs-on: ubuntu-latest steps:

場合、個々の設定オプションをそれぞれジョブ定義としてワークフローに追加できます。ただし、オプション数が多いと、ワークフローが長く、かつ冗長になります。このような場合、Build Matrixが非常に有効です。Build Matrix は jobs.

jobid.strategy.matrix#シンタックスにより設定オプションをリストで指定できる機能です。
リスト4のサンプルは、第2章の「CIパイプラインを構築する」で紹介
3) URL https://docs.github.com/en/actions/
learn-github-actions/workflowsyntax-for-github-actionstjobsjob idstrategymatrix

したGo言語アプリのビルドとテストを行うサンブルを、Build Matrix によりGoの複数のバージョンとOSのパターンで実行するものです。
リスト4を実行した結果が図4です。Build Matrix により、Go言語アプリを、3つのバージョンのGo環境、さらに3種類のOSでビルド・テストした、合計9個のジョブが実行されたことがわかります。

VUZ 4 Build Matrix Iko Go Xi77UOEK: 721
(go-matrix.yml)
jobs: build: strategy: matrix:
go-version: [1.15, 1.16, 1.17]
os: Cubuntu-latest, macos-latest, windows-latest] runs-on: ${{ matrix.os }} steps: – uses: actions/checkoutav2 – name: Set up Go
uses: actions/setup-goav2 with:
go-version: $CC matrix.go-version) – name: Build
run: go build -v ./… – name: Test
run: go test -v ./…

ワークフロー内のデータ共有

1第1章で説明したとおり、ワークフロー内の各ジョブは、ランナーの別々のインスタンスで実行されます。また、ジョプ内の各ステップはランナーの別々のプロセスで実行されます。よって、各ステップで定義する環境変数を変更したとしても、ステップ間では共有されず、当然ながらジョブ間でも共有されません。このように、ステップ、ジョプいずれも、それぞれのレベルで実行空間が分離されているため、データ共有をする際には工夫が必要です。ここでは、各ステップ問、ジョブ問のデータ共有方法を紹介します。

ステップ間のデータ共有

同一ジョプ内の各ステップは、別々のプロセスで実行されるものの、同じランナーのインス・タンス内で実行されるため、共通のワークスペー

スとファイルシステムにアクセスできます。つまり、同一ジョブにおけるすべてのステップは、共通のファイルシステムを通じてデータを共有できます。この場合、GITHUB_WORKSPACE やHOME といった既定の環境変数を活用できます(リスト5)。
ほかにも、set-output コマンドを使う方法があります。あるステップで、::set-output name=name::valueの形式で変数nameに値 value を設定すると、この変数はステップの Soutput パラメータに設定されます。そしてあるステップで output パラメータに設定された変数は、同一ジョブの後の任意のステップからお{{ steps.step_id.output.name }}の形式で取得できます。リスト6では、IDがset-numberのステップで、set-output コマンドを使い、output パラメータに設定された変数 MY_NUMBERを、後続のステップにて${{ steps.set-number. outputs, MY_NUMBER }}で取得しています。

ジョブ間のデータ共有

jobs.job_id.outputs5を用いた複数ジョブ間におけるデータ共有方法を紹介します。
注4) CD https://docs.github.com/ja/actions/hearn-github
actions/workflow-commands-for-github-actions
setting-an-output-parameter #5) URL https://docs.github.com/en/actions/learn-github
actions/workflow-syntax-for-github-actions#jobs job_idoutputs

VUZ5 9-
7A77711274
177-** (data-sharing-steps1.yml 5##)
steps: – name: Write Data in a Job
run: echo "Hello" > $CGITHUB_WORKSPACE]/myoutput.txt name: Read Data in a Job run:
value=$(cat SCGITHUB_WORKSPACE/myoutput.txt) echo "Read Data: ${value]"
マリスト6同一ジョブ内でset-outputを用いたデータ共有(data-sharing-steps2.ymlから抜粋)
steps: – name: Set my number
run: echo ‘::set-output name=MY_NUMBER:: 12345
id: set-number – name: Get my number
run: echo "My number is ${{ steps.set-number.outputs.MY_NUMBER }}"

VUN
%70 outputs & CT
7
707-*##(data-sharing-jobs1.yml)
jobs: job_1: runs-on: ubuntu-latest outputs:
output_1: $CC steps.step_1.outputs.my-value }}
output_2: $(< steps.step_2.outputs.my-value }} steps: – id: step_1
run: echo "::set-output name=my-value:: apple" – id: step_2
run: echo "::set-output name=my-value::banana" job_2:
runs-on: ubuntu-latest needs: job_1 steps: -run: echo ${{needs.job_1.outputs.output_13) ${{needs.job_1.outputs.output_2}}

任意のジョブの処理結果は、jobs.jobs_id.out putsで設定できます。そして、後続ジョブはその出力結果を参照できます。
リスト7では、job_1の各ステップで、setoutputで設定された出力結果をjobs.job_1. outputsに設定しています。そして、jobで設定された出力結果をjob_2 で SHI needs.job_1. outputs. 変数名 }}として参照しています。
ほかにも、Artifact(成果物)を格納するためのストレージを用いた、複数ジョブ間のデータ共有方法があります。この場合、Artifactアップロード用アクションである upload-artifact 6 と、Artifact ダウンロード用のアクション down load-artifactTを活用します。具体的には、任意のジョブで生成したファイル(Artifact)を、 upload-artifactを用いてArtifact用のストレージにアップロードし、後続のジョブは:downloadartifact を用いて先にアップロードされたファイルをArtifact用のストレージからダウンロードして、その中身を参照します。なお、任意のワークフローの実行中にアップロードされた Artifact は、そのワークフロー実行中にだけダウンロードが可能な点に注意が必要です。
Artifactを用いた複数ジョブ間のデータ共有方法の詳細は、GitHub 公式ページ「Passing data
6) GAD https//github.com/actions upload-artifact 7) URL https://github.com/actions/download-artifact

between jobs in a workflow」をご参照くださ

キャッシュの活用

GitHub ホスト型ランナーインスタンスで実行されるジョブは、実行ごとにクリーンな仮想マシンから実行されるため、ジョブの実行が終わると保存されていたデータは破棄されます。よって、アプリケーションのビルドなどに必要な依存ファイルは、都度ダウンロードする必要があります。それらの依存ファイルのダウンロードにかかる時間を短縮するために、ワークフロー内で頻繁に使われる依存データをキャッシュするしくみをGitHub Actionsは標準でサポートしています。キャッシュは、リポジトリのすべてのワークフローで共有可能です。たとえば、main ブランチでダウンロードされたパッケージをキャッシュし、ほかのブランチでリストアして利用することが可能です。ワークフロー内で、依存データをキャッシュする際には、キャッシュアクションactions/cacheを用います。
キャッシュアクションには、表1の3つのパラメータがあります。リスト8は、Go言語アプリのビルド処理高速
注8) CD https://docs.github.com/en/actions/advanced.
guides/storing-workflow.data-as-artifacts#
passing-data-between-jobs-in-a-workflow 9) URL https://github.com/actions cache

表1 キャッシュアクションのパラメータ一覧「パラメータの種類
概要・特徴・キャッシュするファイル群のパス |path(必須) ・keyパラメータの値がキャッシュのキーと一致すると、ここにキャッシュされたファイル
が復元される
・キャッシュに対応する完全マッチング用キー key(必須)
・この値が完全一致すると、キャッシュが復元される
・keyパラメータの値でキャッシュヒットしなかった場合の救済用あいまい一致用キー restore-keys
・複数キーの追加が可能で、キーを順番に探索して部分一致でキャッシュが復元される

化のために、モジュールとビルドのキャッシュを行うサンプルです。
ここでは、Go言語のモジュールとビルドキャッシュの例を紹介しましたが、ほかにもさまざまな言語パッケージに活用できます。ほかの言語におけるキャッシュ利用のサンプルは、 actions/cache アクションのサンプル一覧法10が参考になります。なお、実際に活用する際には、以下にも留意してください。
・7日間以上アクセスされていないキャッシュ
ファイルは自動的に削除されます・リポジトリあたりの最大キャッシュサイズは 5GBで、この制限を超えた場合、合計サイズが5GB以下になるまでキャッシュが退去されます (参考:Usage limits and eviction policy#1)
10) URL https://github.com/actions/cache/blob/master/
examples.md 11) URL https://docs.github.com/ja/actions/advanced
guides/caching-dependencies-to-speed-upworkflowstusage-limits-and-eviction-policy

Environmentsを活用した複数環境のデプロイメント管理

ここでは、Environments と呼ばれる、環境ごとにシークレットや保護ルールを設定できる機能を使った、CI/CDパイプラインの設定方法を紹介します。
CI/CDパイプラインからデプロイする環境は、本番環境だけではありません。図5のように、開発・検証環境、ステージング環境、本番環境など、複数の環境を対象とすることがほとんどです。そのような場合、環境ごとに異なるシークレットやルールの要件が存在するでしょう。 Environmentsは、そのような要件を満たすべく、 2021年12月にリリースされた比較的新しい機能です。
なお、Environments は、公開リポジトリ、もしくはGitHub Enterprise Cloudでだけ利用可能な機能です。

VUZ
Go E%1-VEELK&#
174%7(go-cache.yml 851)
(.. ..) – uses: actions/cachea v2
id: setup-cache with: path: |
7go/pkg/nod
7.cache/go-build key: ${{ runner.os }}-go-S<hashFiles(‘**/go.sum’) }} restore-keys:
$C runner.os }}-go

name: Build
run: go build -v ./…
nane: Test
run: go test -v ./…

Environmentsによる複数環境

の設定リポジトリ下の「Settings」タブをクリックし、「Environments」を選択します。そして、[New environment] ボタンをクリックし、名前を入力することで新規 Environment を作成できます。ここでは、図6のように production, staging, development という3つのEnvironment を作成します。
そして、図7は各Environment の設定ページです。大きく3種類の設定が可能です(表2)。
次に、Environments を活用した複数環境にデプロイするワークフローを紹介します。
リスト9のサンプルでは、mainブランチへのコミットやマージをトリガーとして、build_test ジョブでビルドとテストを行い、その後、 deploy_stagingジョブでステージング環境にデプロイします。そして、

▼表2 Environments の設定一覧設定項目
概要・特徴・各環境の保護ルールの設定 Environment
|・保護ルールのRequired reviewersでは、ジョブを進行させるために承認者を設定可能 protection rules
・保護ルールのWait timerでは、ジョブ実行までの待機時間(最大30日)を設定可能 Deployment branches | Environmentにデプロイできるブランチ制限の設定
| Environment ごとのシークレットの設定 Environment secrets
・なお、図7ではすでにMY_SECRETという名前のシークレットが設定されている

マリスト9 Environmentを使って複数環境にデプロイするワークフローの例(multi-env-deploy.yml)
name: CICD to multi environments
on: push: branches:

main
jobs: build_test:
runs-on: ubuntu-latest steps:
run: echo building and testing!
deploy_staging: needs: [build_test] runs-on: ubuntu-latest environment:
name: staging steps:
run: echo deploying to staging – run: echo using my secret for staging – St{ secrets.MY_SECRET >>
deploy_production:
needs: [deploy_staging] runs-on: ubuntu-latest environment:
name: production steps:
run: echo deploying to production! – run: echo using my secret for production – ${{ secrets.MY_SECRET }}

deploystaging ジョブのあとに、deploy productionジョブで本番環境にデプロイします。 deploy_staging ジョプと deploy_productionジョブには、jobs.job_id.environmentシンタックスで、それぞれstagingとproduction という名前の Environment を関連付けています。ここでは、 stagingとproductionのEnvironment には、別々のMYSECRETというシークレットを設定しています。リスト9を実行すると、deploy staging ジョブでは stagingに設定したシークレットが、deploy_production ジョブでは productionに設定したシークレットが使われま
す。

ジョブ実行の承認者の設定

HD Environment of Environment protection rules」で、各Environmentの保護ルールの1つとして、ジョブを進行させるためのレ

ビュアーを設定できます。最大で6人のユーザーもしくはOrganization リポジトリの場合はTeam をレビュー担当者に指定可能です。ここでは、図8のように筆者1人をレビュアーとして設定します。
再びワークフローを開始すると、今度は、 deploy_stagingジョブの実行後、図9のように deploy_production ジョブがベンディング状態になります。これは、レビュー待ちの状態です。
レビュアーには、図9の左のように[Review deployments]ボタンが表示され、図9の右のように承認するかどうかを選択します。そして、レビュアーが承認([Approve and deploy])を選択すると、deploy_production ジョブの実行が開始されます。なお、レビュアーが拒否([Rejeet]) を選択するとワークフローは失敗します。

GitHub ActionsとlaCツールによるインフラ構成管理の自動化

GitHub Actionsと構成管理ツールを組み合わせ、CI/CDパイプラインを通じたインフラストラクチャの自動デプロイメントを実現させる例を紹介します。

lacとCI/CDによるインフラ構成管理の自動化

laCとは、Infrastructure as Codeの略で、イ

ンフラ構成をコード化し、その構築を自動化する手法です。IaCを実践することで、インフラ運用管理の属人化防止や作業ミスの削減ができたり、何度でも同じ構成の環境を構築できたりするようになります。
なお、IaCを実現するための構成管理ツールには、表3のようなものがあります。
laCにおいて、コード化されたインフラ構成ファイルは、GitHubのようなコード管理システムでバージョン管理され、CI/CDパイプライン

表3 構成管理ツールの例
構成管理ツール AWS CloudFormation
Google Cloud Deployment Manager
Azure Resource Manager
概要・特徴・AWSリソースの構成管理を可能にするサービス・宣言型アプローチで構築を行う・GCPリソースの構成管理を可能にするサービス・宣言型アプローチで構築を行う・Microsoft Azureリソースの構成管理を可能にするサービス・宣言型アプローチで構築を行う・HashiCorp社による、特定クラウド、マネージドサービスのリソー
スに限定しないOSS構成管理ツール・宣言型アプローチで構築を行う・Red Hat社による、特定クラウド、マネージドサービスのリソース
に限定しないOSS構成管理ツール・手続き型アプローチで構築を行う
Terraform
Ansible

を用いて目的の環境にデプロイするのが一般的です(図10)。IaCとCI/CDを組み合わせることで、一連のインフラ構築、構成変更が自動化され、迅速かつ安全に実施できます。まさに、IAC とCI/CDはインフラ構成管理の自動化に欠かせない2大要素と言えます。

GitHub ActionsによるlaCツール活用例

参考までに、Terraformを活用し、CI/CD経由でAWSにEC2を構築するワークフローを紹介します。
リスト10は、EC2インスタンスを作成する IaCファイル(HCL)、リスト11は、それをもとにTerraform経由でAWS環境にEC2インスタンスをデプロイするワークフローです。Terra
マリスト10 TerraformのHCLファイル
terraform { required_providers { aws = {
source = "hashicorp/aws" version="> 3.27"
backend "s3" {
bucket = "gha-terraform" key = "terraform. tfstate" region = "ap-northeast-1"
required_version = ">= 0.14.9"
resource "aws_instance" "app_server" { ani
="ami-0845511340543554c" instance_type = "t2.micro"
tags = {
Name = "ExampleEC2 Instance"

A
form e rsla HashiCorp # NTZ
r ahashicorp/setup-terraform 127 利用しています。

GitHub Actionsによる細かいタスクの自動化

GitHub Actions lt. -FOUNKT
12) URL https://github.com/hashicorp/setup-terraform
マリスト11 Terraformを活用したGitHub Actionsワーク
70
jobs: terraforn:
nane: "Terraform" runs-on: ubuntu-latest steps:

nane: Setup Terraform
uses: hashicorp/setup-terraformav1 with:
terraforn_version: 0.14.9
name: Terraform Format
run: terraform fnt -check
nane: Terraform Init
run: terraform init
nane: Terraform Validate
run: terraform validate -no-color
nane: Terraform Plan
if: github.event_name == ‘pull_request run: terraform plan -no-color
nane: Terraform Apply
if: github.ref == ‘refs/heads/nain’ && 7 github.event_name =’push’
run: terraform apply -auto-approve

マリスト12actions/github-script を活用して Pull Request にコメントを投稿する例

nane: Terraform Validate
id: validate run: terraform validate -no-color
nane: Terraform Plan
id: plan if: github.event_nane = ‘pull_request’ run: terraform plan -no-color continue-on-error: true
uses: actions/github-scriptav3
if: github.event_nane == ‘pull_request! eny:
PLAN: "terraforminst steps.plan.outputs.stdout }}" with:
github-token: ${{ secrets.GITHUB_TOKEN }} script:
const output = W Terraform Validation SCC steps.validate.outcome) #### Terraform Plan \"${{ steps.plan.outcome }}

Show Plan

In ${process.env.PLAN)

; github.issues.createComment
issue_number: context.issue. number, owner: context.repo.owner, repo: context.repo.repo, body: output
)

・リリースなどを自動化できますが、CI/CD専用の自動化ツールではありません。第1章で説明したとおり、GitHub Actionsはリポジトリで発生するすべての操作イベントをトリガーとしてワークフローを実行できます。そのため、さまざまなタスクの自動化が可能です。たとえば、 Issueの作成(issues)やIssueへのコメント (issue_comment)、リポジトリへのラベル作成 (label)などが挙げられます。ここでは、代表的なタスクの自動化を2つ紹介します。

CIの処理結果をPull Requestのコメントとして投稿

先ほど紹介した、Terraformを活用したCI/ CD経由による、Amazon EC2を構築するワークフローを拡張してみます。Terraformの構成管理を記述するファイルのフォーマットチェック、パリデーションチェック、terraform plan などの処理結果を、各ステップにおける output

の出力結果から取得し、Pull RequestのIssue コメントとして投稿します。この Issue コメントの投稿は、actions/github-script1はアクションを活用します。また、Issue コメントの投稿には、GitHub APIを利用する必要があります。この actions/github-scriptは、リスト12のように、 script 部分に直接JavaScriptをインラインで記述でき、GitHub API操作のためのJavaScript クライアントライブラリ(octokit/rest.js注1)を API認証済みの状態で利用できます。
図11は、このワークフロー実行で、Pull Request にコメント投稿された結果です。

変更ファイルのバスに基づくPull Requestへの自動ラベル付与

) 2つめは、actions/labeler15アクションを
13) URL https://github.com/actions/github-script
14) URL https://octokit.github.io/rest.js/v18 注15) ORD https://github.com/actionstabeler

VUZ 13 .github/labeler-config.yml

kubernetesti. ML (279 ) kubernetes: – kubernetes/*/

TAL

cloudformation TO cloudformation: – cloudformation/*

terrafor ALTFOL terraform: – terraform/*

使った、Pull Request への自動ラベル付与のです。actions/labelerは、変更されるファイルのバスに基づき、新しいPull Requestに自動的にラベルを付与してくれます。
リスト13は、ファイルの変更に対してどのラベルを付与するのかを定義するYAMLファイルです。そして、リスト 14は、actions/labeler アクション利用を定義しているワークフローです。Pull Requestをトリガーに実行されると、actions/ labelerアクションの中で指定する.github/ labeler-config.ymlファイルの内容に基づいてラベルが付与されます。

VUZ 14 .github/workflows/labeler.yml
name: Labeler on:
pull_request:
jobs: Tabel: runs-on: ubuntu-latest steps: – uses: actions/labelerav3 with:
repo-token: "${{ secrets.GITHUB_TOKEN }}" configuration-path: ".github/labeler-config.yml" sync-labels: true

図12は、リスト13、14のワークフローを実行し、付与されたPull Request のラベルです。

おわりに

REA
第1章ではGitHub Actionsの概要を、第2章ではGitHub Actionsを使ったCI/CDパイプライン構築をハンズオン形式で解説しました。そして、第3章では、効率的なワークフローの構築や、開発フローの自動化のために押さえておきたい基礎知識を紹介しました。GitHub Actions を使うことで、CI/CDはもちろん、さまざまな

GitHubベースの作業が自動化でき、効率的なソフトウェア開発が可能になることをご理解いただけたのではないでしょうか。本稿がみなさんの GitHub Actions導入の一助となれば幸いです。50

第1特集 ここから始める時短(開発)