GitHub Actionsについてざっくりまとめてみた

●背景

いまの仕事でAzureを使ったCI/CD構成ってあまり構築したことないな～（CI/CD構成はAWSばっかだな）。てかそもそもCI/CD周りの案件にあまり関与したことないな～など考えていたら、先日のJAZUGイベントで皆さん当たり前のようにAzure×CI/CD周りを話されていたので、ざっくりGitHub Actionsについて用語や何となくのイメージをまとめようと思います。

実際必要になった時やさらに興味持った時に触ってみようと思います。

●よく聞くGitHub Actionsって何？

テスト、ビルド、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー（CI/CD）

※ちなみにGitHubは”バージョン管理ツール“（変更履歴を記録し、管理するシステム）

• テスト：「仕様通りの機能が実装されているか」といった確認が自動的に行われる
• ビルド：リリース用のブランチ（作業用に複製された領域）にマージ（併合）されビルドされる。※ビルドとは、ソースコードをコンパイルし必要なアプリケーションやライブラリなどを準備して、ソースコードが動作できる環境を組み立てること。ビルド後は自動的にテスト用のサーバにデリバリーされ、いつでも動作確認ができる状態になります。
• デプロイ：本番環境へのアップデート

※ブランチとは、プログラムのコード開発において、主要な開発ラインから一時的に分岐した作業の流れのことを指す。例えば、ある機能の開発中に別の修正が必要になったとき、ブランチを切って修正作業を行うことで、並行して複数のタスクを進めることができる。これにより、チーム内での作業の衝突を避けたり、特定のバージョンのコードを保存しておくことも可能となる

●GitHub Actionsにも種類がある

①Github hosted Runner：GitHub管理サーバ下で稼働

②Self-hosted Runner：ユーザ所有の環境下で稼働

●Actions Runner Controller（ARC）

Self-hosted Runnerの調整、スケーリングを行うKubernetes Operator。※Kubernetes上で管理

以下3つの役割を持っている。

①Controller-manager

②Listener

③Runner Scale Set

●用語

• Kubernetes：コンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェア

• Helm：Kubernetesのパッケージマネージャー。アプリケーションのクラスタへのデプロイに必要なすべてのコードとリソースが含まれ、アプリの配信を自動化します。