1年ほど前に GitHub Actions を使うなら、気にしたほうがいいこと というタイトルで記事を書きましたが、この1年でそれなりにGitHub Actionsを書いてきました。
その中でこれ意外と使うかも、いいノウハウかもと思ったものをまとめました。
ワークフローによっては前段のワークフローが成功したとしてもスキップしたとしても、実行したい場合があると思います。その場合はif: ${{ !cancelled() && !failure() }}と書くと実現できます。
以下の例ではcall-build-imageが成功してもスキップしてもcall-deploy-appは実行されます。
name: App Deploy
on:
workflow_call:
inputs:
environment:
required: true
type: string
description: "デプロイ環境（staging/production）"
secrets:
aws_role_arn:
required: true
jobs:
call-build-image:
if:
uses: ./.github/workflows/build-image.yaml
with:
environment: ${{ inputs.environment }}
secrets:
aws_role_arn: ${{ secrets.aws_role_arn }}
call-deploy-app:
needs: call-build-image
if: ${{ !cancelled() && !failure() }}
uses: ./.github/workflows/deploy-app.yaml
with:
environment: ${{ inputs.environment }}
image_tag: ${{ needs.call-build-image.outputs.image_tag }}
secrets:
aws_role_arn: ${{ secrets.aws_role_arn }}
先日書いた記事ですが、
デプロイのような流れ作業を想定したワークフローの場合、使う場面がそれなりにあると思います。
AWSなどのクラウド上に環境を構築すると、デプロイやパラメータストアの参照などでCLIを使うことがあると思います。
Marketplaceに公開されているactionsを使うこともあると思いますが、それでも痒いところに手が届かない場合もあったりします。
そんな場合は自分でShell芸することになりますが、最近はAIが本当に発達してきて素人でもShell芸がしやすくなりました。
先日書いたこちらの記事でもAIを駆使したShell芸を行っています。
もしかしたらあんなことやこんなこともShell芸で実現できちゃうんじゃないか…諦める前にAIに尋ねてみましょう。
例えばデプロイワークフローは環境が異なるだけで、ワークフローの中身はほとんど同じだったりすることもあると思います。
その場合、環境ごとにワークフローを分けると同じコードを何回も書くことになります。
当たり前ですが、このような場合は共通のワークフローを作成しておくと便利です。
deploy-app.yaml # 大元のデプロイワークフロー
deploy-production-app.yaml # 本番環境用のデプロイワークフロー
deploy-staging-app.yaml # ステージング環境用のデプロイワークフロー
deploy-app.yamlでは引数を取れるようにworkflow_callのinputsやsecretsを定義します。
name: App Deploy
on:
workflow_call:
inputs:
environment:
required: true
type: string
description: "デプロイ環境（staging/production）"
aws_region:
required: false
type: string
default: ap-northeast-1
description: AWSリージョン
secrets:
aws_role_arn:
required: true
deploy-production-app.yamlでは必要な引数を設定して、deploy-app.yamlを呼び出すだけの実装にします。
name: Production App Deploy
on:
repository_dispatch:
types: [production_deploy]
jobs:
call-deploy:
uses: ./.github/workflows/deploy-app.yaml
with:
environment: production
secrets:
aws_role_arn: ${{ secrets.AWS_ROLE_ARN }}
deploy-staging-app.yamlでも必要な引数を設定して、deploy-app.yamlを呼び出すだけとし、こちらは手動実行ができるように実装してみます。
name: Staging App Deploy
on:
workflow_dispatch:
inputs:
environment:
type: string
required: true
default: "staging"
description: "デプロイ環境"
jobs:
call-blue-green-deploy:
uses: ./.github/workflows/deploy-app.yaml
with:
environment: ${{ inputs.environment }}
secrets:
aws_role_arn: ${{ secrets.AWS_ROLE_ARN }}
前回記事の「ワークフローのテンプレートをmainブランチに含めておく」がここで役に立ちます。
例えば先ほどのdeploy-staging-app.yamlがまだリポジトリ上に存在しておらず、手動で動作確認したくなった場合があったとします。
ワークフローのテンプレートをdeploy-staging-app.yamlの中身で全て上書きします。
そして、ブランチ指定でワークフローを実行すれば手動での動作確認が可能になります。
この場合は、新規のブランチや実際の修正ブランチから切った一時的なブランチを使うと、余計な修正が混在しません。
弊社ではSlackを使ったChatOpsでデプロイをしており、どうしてもmainブランチにマージしなければ厳密な動作確認は行えないこともありますが、手動での擬似動作確認だけでも行えれば、マージ後の手戻りも少なくなると思います。
ワークフローファイルをプロジェクトやコンポーネント、アプリケーションなどを単位としたサブディレクトリで管理したいですよね。.github/workflows内でサブディレクトリを作成し、その中にワークフローファイルを置いていくイメージです。
残念ながらいまだにできないようです。
Views: 0
