リリースフローを整えました(git-pr-releaseを導入し、GitHub Actionsで自動化したお話)
こんにちは、昨年の10月に新卒未経験でエンジニアとして入社させていただいた渡辺です。
いつか自分の番が来てしまうとビクビクしていましたが、ついにその時がきてしまったので、半人前ながら先月行った"git-pr-releaseをGithub Actionsで自動化した話"について書いてみようと思います。
概要
自社プロダクトの”シンシアレジデンス”では、以下のように複数の開発環境に分けて、リリースを行っています。
- 開発環境
- staging 環境 (developブランチ / 動作確認環境)
- production 環境 (本番環境)
- ローカルで開発を行い、トピックブランチを作成する
- 上記のブランチからdevelopに対して、Pull Requestを作成する
- トピックブランチ→developへのPull Requestをsquash mergeする
- developはstaging環境にデプロイされるので、そこで動作確認をする
- developからmainへmergeし、CIでproduction 環境へデプロイする
課題背景
- staging環境からmainへマージする際、release PRを作成し各開発者にstaging環境で動作確認をしたかどうか、逐一コミュニケーションを取る必要があったため、コストがかかり且つ面倒だったこと。
- 新規にstaging環境にマージされた内容が何か一目でわからず、意識していないとstaging環境に変更が溜まりがちであった
→一回のリリース量が多すぎてしまう(障害発生時に原因究明が難しい…)
今回、上記課題を解決するためにGitHub Actionsを利用してgit-pr-release の自動化に臨みました。
手順
Github Actionsをリポジトリに追加する
.github / workflows ディレクトリをリポジトリ上に作成する。
上記ディレクトリ配下にgithub-actions-demo.ymlを作成する。
(ファイル名はなんでもOKで、自分はgithub-actions.ymlに設定)
(詳しくは、GitHub DocsのQuickstart を参照してください。)
docs.github.comgithub-actions.yml に自動化するワークフローを追加する
push イベントが発生したときにワークフローを実行するように設定。
(各ワークフローをトリガーするイベントについてはこちら↓)
jobs下に、job_idと それぞれのjob_nameを設定する
id: create-release-pr
name: Set up Ruby 2.6
設定したJob_idとjob_nameはGitHub Actionsで表示される。
Actions内のworkflowに行くと、設定したJob_idとjob_nameを確認することができる。
TZの環境変数を設定する
デフォルトのままだと、日本時間でないため、TZ: 'Asia/Tokyo'を追加する
Rubyのセットアップ
git-pr-releaseのセットアップ
GIT_PR_RELEASE_BRANCH_STAGINGには、masterブランチにマージするブランチを設定する
GIT_PR_RELEASE_LABELSに文字を追加すると、release PRにラベルが追加される(なくてもOK)
git-pr-release --squashとすることで、squashマージされたPRを検知するように設定
(弊社ではトピックブランチからdevelopへはsquash mergeをしているため)
上記の設定がうまくいっていれば、トピックブランチをdevelopにsquash mergeをすると以下のようなrelease PRが自動的に作成されるようになります。
補足
もともと、git-pr-release上で git-pr-release -squashを行うと同じ項目のチェックボックスが複数生成されてしまうというバグがありました。
これをチームのエンジニアが修正PRを本家のオープンソースに出してくださったことで、正常に動くようになりました。
課題解決
git-pr-releaseを追加し、GitHub Actions で自動化したことにより、以下の点で作業効率が上がりました。
- developにトピックブランチをpushするだけでrelease PRが作成されるため、作業時間の短縮につながった
- チェックボックスと開発担当者が表示されるおかげで、staging環境でだれがどの動作確認したかが一目でわかるようになった
- staging環境にある変更内容がリスト化されて表示されることで、変更内容をstaging環境で溜めすぎず、コンスタントにリリースを行えるようになった
終わりに
半年前に入社した当初はVue.jsもRuby on Railsも触ったことのない私でしたが、なんとか半年間周りの先輩方のおかげで食らいつくことができています。また、最近では上記のようなワークフロー周りの整備だったり、スクレイピング、などなど様々なことに挑戦しています。
弊社ではフロントもバックエンドも関係なく、様々なことに挑戦させていただける環境です。一緒に開発してくださる方をお待ちしています！！
参照
git-pr-release with GitHub Actions
Github Docs
git-pr-release
