はじめに
『GithubActions』超初心者です。「GithubActionsとは何ぞや?」を噛み砕いてまとめてみました…メモ程度の内容ですが公開します。(ちなみにこのメモをまとめた後、簡単に組んだりなどもしました◎触ってみるとより理解が進みますよね)
同じく初心者だよ~という方、一緒に学んでいきましょう!また、経験者さまによる「GithubActions、知ってるよ!このメモのココは違うかも(こういう認識のが良いかも)」といったようなツッコミも歓迎しております
こちらは社内にて2023年10月頃に公開した内容とほぼ変わりません。
むしろ社内公開版の方がオマケもあって詳しいです。見たことある方、すみません…
GithubActionsって、なぁに?
-
Githubにて利用可能なCI/CDのプラットフォーム。
ビルド、テスト、デプロイなどのパイプラインを自動化できる。 - 対象ディレクトリに配置された、かつ設定の正しく記載されたyamlファイルが存在するとき
対象ブランチに、何かしらの指定したアクション(例:対象ブランチにmerge)をしたタイミングで、
yamlファイル内に記述されたコマンドが実行される。
⇒設定の記述されたyamlファイルを特定のフォルダに配置しておくと、
そのyamlファイル内で指定されたブランチに対してとあるアクション(merge等)を実施したときに、
ローカルのコマンドプロンプトでちまちま実施していたようなことを
自動で実施してくれる!みたい。
(※ということは…yamlファイルを書く前に、「何をさせたいか」はもちろん
「(させたい内容に基づき)どんなコマンドを実施したいのか」「そのコマンドはローカルでは動くのか」 等を確認しても良いかも◎)
こんなことがデキル!一例集
- リポジトリに対するpull request作成をトリガーに、テストを実施!
- mergeされたpull requestをトリガーに、本番環境へデプロイ!
GithubActionsのメリット
主に以下3点?
▼サーバーを用意する必要がない
GitHubActionsは、GitHubが提供する仮想マシン上で実行される。別途サーバーを用意する必要ナシ!
▼使いやすい
YAML形式のワークフローファイルを記述するだけで
簡単に自動化処理を作成することができる!
▼拡張性が高い
GitHub Marketplaceで公開されているアクションや、ユーザーが独自に作成したアクションを組み合わせて使用することができる。
(例:コードの自動テスト、ビルドの自動実行、デプロイの自動実行、コードの品質チェック、セキュリティスキャン、ドキュメントの自動生成…)
また、機能によっては以下のようなメリットにもつながるかも。
▼バージョン管理+デプロイが楽になる
例えば…AWS Lambdaのような、それ単体ではバージョン管理の無い+デプロイが手動な機能と組み合わせることで、
(バージョン管理システムである)Githubで管理し、
特定のブランチにmergeされたら自動でデプロイしてくれる!
等の管理方法が可能になる。
※Githubのおかげで「以前のLambdaのコードの内容が分からない!」が無くなるのに加えて、
GithubActionsを正しく設定しておけば、レビュー→merge完了後に勝手にデプロイまでやってくれる…
という安全で楽な運用ができるようになる!
出てくる単語(yamlファイルの中身)
-
ワークフロー(workflow)
- イベントのトリガーや実行条件、ジョブのシーケンスなどを定義します。
- .github/workflow以下に配置される一つのYAMLファイルが一つのワークフロー
-
トリガー(trigger)
- ワークフローが実施されるきっかけを定義する
-
ジョブ(job)
- ワークフロー内で実行される単一のタスク単位
- ワークフロー内に複数のジョブを定義することができ、それぞれのジョブは並列に実行される
- ジョブ毎に実行環境が立ち上がって処理が実行されるため、ジョブ毎に異なる環境やプラットフォームで実行することが可能
-
ステップ(step)
- ジョブ内の個々の処理
- コマンドやAction、スクリプトなど処理の実態を定義する(具体的な処理を記載する)
- 例:ソースコードのビルド、テストの実行、デプロイの実施など
- 各ステップは前のステップの完了に依存して実行される
導入方法
⓪今回はどんなことを実施させる?(考えてから実施しよう)
⇒今回は「developブランチに別のブランチがpush(merge)されたら、
GithubActions内に "Hello" といった結果が出力されるようにする」
(便利さとかじゃなく、マジで動作確認用に作ってみる!)
①どのブランチにmergeされたらGithubActionsが動作するか決定する
⇒今回は「develop」ブランチとする
(developブランチに別のブランチがmergeされたらGithubActioinsが動作する)
②「.github/workflows」下にyamlファイルを作成する
※フォルダが無かったら作成してOK
※ファイル名は任意
⇒今回は「develop.yml」
③手順2で作成したファイルに必要事項を記入する
⇒例↓
# ワークフローの名称
name: action_hello01
# トリガー…何をきっかけにワークフローを実施する?
## 今回は「develop」ブランチに「(mergeし)push」されたら
on:
push:
branches:
- develop
# ワークフロー内で実施してほしい内容(ジョブ)は?
## 今回は「Hello」と出力するステップを追加
jobs:
hello-develop:
runs-on: ubuntu-latest
steps:
- name: execute echo command
run: echo "Hello"
④手順③まで完了したら、その内容をcommit→pushする
⑤手順④が完了すると、対象ブランチ(今回はdevelop)にmerge時に、
yamlファイルに書いた内容が実行される!
実行されている様子がGithubの画面からも見られますヨ!対象リポジトリの「Actions」タブを要チェックや!
ジョブ(job)の中でできることって?
- コマンドで実施できることは一通り実施できるみたい。
- なので、前述の通りyamlファイルに記述前に「このコマンド正しいの?(ローカルでも動く?)」といったことは確認すると吉◎
- AWSと連携させて、あれこれできるみたい。
- IAMロールとか用意する必要があるので、実施したい場合は準備を忘れずに!
※できることの詳細に関してはググったり別の記事を読んだりしてみてください
おわりに
ということで、本当に超~~あっさり、初心者向けにGithubActionsに関して書いてみました 「yamlファイルを特定のフォルダに置いておく必要があるんだな」「yamlファイルに書かれたジョブを、トリガーが発火したら実施してくれるんだな」「ジョブにいろいろ指定することで、自動テストはじめ便利なことがいろいろできそうだな」くらいは感じ取っていただけていたら幸い。
今回の記事だけでは便利さ(具体的にできること)や設定詳細(どう指定すればどういうジョブが動くの?)など、まだまだ分からないことだらけだと思うので、ぜひ他のいろいろな例を見てみて&試してみてください!