Github Environmentsでデプロイパイプラインにレビューを搭載する

こんにちはメリークリスマス！コドモンプロダクト開発部のチャブです。

こちらは「コドモン Advent Calendar 2023」の20日目の記事です！

概要

コドモンのプロダクトではCI/CDのプラクティスを取り入れています。開発者のローカル開発環境からユーザーの手に届くまでの過程をなるべく効率よく、素早くするために、積極的にツーリングを取り入れています。今回は、Github actionsのEnvironmentsを用いてデプロイメントワークフローにレビューを取り入れた話をします。(今回紹介する承認機能をプライベートレポジトリで利用するにはGitHub Enterpriseが必要になります)

デプロイパイプライン

新しいバージョンのプロダクトをユーザーに届けるにあたって、リリースの作業は再現性の高い、自動化されたプロセス(=デプロイパイプライン)で行いたいですよね。コドモンではGithub Actionsを用いたパイプラインが主に使われています。サービスおよびパイプラインが一定数あり、今回は自分の開発しているサービスを例に紹介します。

レビュー前のパイプライン

今まではデプロイメントを行うワークフローを2つに分けていました。1つ目はテストを行い、開発環境とステージング環境までデプロイを行ってくれます。そして2つ目はステージング環境での動作確認ができた後に実行するもので、本番までデプロイしてくれます。

今までのプロセスとしては、以下のようになっていました。

'deploy'というキーワードを含んだコミットメッセージでmainブランチにマージ
最初のワークフローが実行され、テストなどを行いステージング環境までデプロイされる
必要な確認をステージング環境で行う
本番用のワークフローにコミットハッシュを指定して手動で実行

このような過程で本番までの道のりは割とお手軽でしたが、2つ目のワークフローを適切なコミットハッシュで実行するための一定の手動の作業が必要になります。そのため、新しいバージョンのデプロイがステージング環境までとどまってしまい、本番に反映するのが少し遅れることもありました。

Environmentsレボリューション

Github のEnvironmentsを用いて上記のプロセスをさらにシンプルにできます。 2つあったワークフローを1つにして、1つのワークフローの最後に本番へのデプロイジョブを追加します。もちろん、勝手に本番にデプロイされては困るので、Environmentsの機能を使ってデプロイ前にレビューのステップを追加します。そうすることでレビュアーに承認されるまでジョブが停止します(ステージング環境までの反映で停止)。