法人サービスの管理画面をSlackからリリースできるようにしてみた

こんにちは！ NewsPicksの法人向けサービス開発チームの森です。
私は元営業職でエンジニアとして働くのはNewsPicksが初めてで、入社して3ヶ月の頃に入社エントリーを書かせていただきました。 tech.uzabase.com

前回はなぜエンジニアに？なぜNewsPicksに？といったお話をさせていただきましたが
今回は入社から半年経って、NewsPicksのエンジニア組織が大事にしている「開発者体験向上」に繋がる取り組みに挑戦してみました！といった内容について書いていこうと思います。

お時間がない方はぜひ！採用ページだけでも見てくださると泣いて喜びます！（ここが一番大事）

tech.uzabase.com

NewsPicksは開発者体験向上を大事にしています
今回やったこと：フロントエンドをslackからリリースできるようにする
実装方法
Slackからリリースできるようにしてよかったこと
「勉強中の開発」と「実務の開発」のギャップ
最後に

NewsPicksは開発者体験向上を大事にしています

詳しくはNewsPicks CPO／CTO 文字さんのblogに書いているのでぜひご覧ください！ tech.uzabase.com

例えば、NewsPicksのバックエンドはSlackのコマンドほぼ1つでテストもリリースもでき、入社後すぐの私でもミスが起こりにくく短時間でリリース作業が済むような仕組みになっています。
ユーザーに価値提供できる機能開発に注力できる最高の環境で開発することができ、働いていて本当にありがたいなと思う毎日です。

今回やったこと：フロントエンドをslackからリリースできるようにする

私は法人向けサービスの管理画面を開発することが多いのですが、今回はその管理画面のリリース手順を簡易的にしました。

前提

リリース対象は管理画面のフロントエンド(Vue.js)
デプロイ先はS3

変更前

下記のコマンドを一つ一つ手で打ってリリースしていました。

cd {管理画面のレポジトリ}
git checkout master && git pull
TAG_NAME=release_$(TZ=UTC date '+%Y%m%d_%H%M')
echo $TAG_NAME
git tag $TAG_NAME
git push origin $TAG_NAME
cd sh 
./deploy.production.sh $TAG_NAME ${対象環境のロールのprofile}

./deploy.production.shにはCodeBuildやCloudFrontを実行するAWS-CLIが記載されており、 ./deploy.production.shを実行するとCodeBuildでビルドとS3へのデプロイ、CloudFrontでキャッシュをクリアできます。

こちらの方法でもすでにかなり簡単なのですが、何せNewsPicksのバックエンドはSlackのコマンドほぼ1つでリリースできてしまうので、管理画面ももっと簡単にしたい！と思い、下記のように変更してみました。

変更後

Slackのワークフローでリリースできるようになりました。
「管理画面です！」と「OK！😇」のプルダウン2個を選択してsubmitを押せば管理画面がリリースされます。

実装方法

こちらの画像が実装のイメージ図です。

①Slackでワークフローを実行するとChatbotで以下のコマンドが走り、Lambda経由でGitHub Actionが実行される

②GitHub Actionで変更前に元々手動で打っていたコマンド（タグを切って./deploy.production.shを実行していたコマンド）を実行
③./deploy.production.shを実行することで、変更前と同じようにCodeBuildでビルドとS3へのデプロイ、CloudFrontでキャッシュをクリア

今まであったものを活かしつつ、①と②を新しく実装したことでslackからリリースすることができるようになりました。もっと良い方法もあるかもしれませんが、ひとまずこちらの方法で実現しています。

Slackからリリースできるようにしてよかったこと

リリースが一瞬で終わるようになった
少しの追加実装でこれからの何十回とするであろうリリース作業がslackからぽちっとできるようになったので、変更する価値はあったのではないかと思っています。
※少しの追加実装と書きましたが、私はインフラ系のタスクに挑戦するのが初めてで、どう変更したら良いかすぐにアイデアが浮かびませんでした。考える時間・チームメンバーに相談する時間をいただきました。ジュニアエンジニアにも挑戦の機会をくださる環境に本当に感謝です。
権限の付与が簡易的に
リリースのワークフローを実行できるSlackチャンネルは鍵付きにしていて、デプロイ作業をするメンバーだけ参加しています。
今までは新メンバーが入るたび、デプロイ用のロールに切り替えるアクセス許可をユーザーに付与する申請ってどうやってやるんだっけ…？と過去のSlackを検索する、ということを行いがちでした。
今回の修正によってリリースに関してはSlackチャンネルにメンバーを追加するだけでよくなりました。
人的ミスのリスク削減
コマンド操作の必要がなくなったので、人的ミスのリスク削減できたと思います。
過去にどなたかがミスをしたという実態はありませんが、少しの可能性でも潰しておくのは良いことかなと思っています。

「勉強中の開発」と「実務の開発」のギャップ

入社前に勉強していた時の開発と実務での開発を比べてどのようなことにギャップを感じたのか、折角なので（?）書いてみようと思います。
温かい目で読んでください。笑

そもそも自分ではAWSの設定ができない
勉強中はもちろん自分で設定するしかなかったのですが、私のチームでは本番環境のAWSの設定はチームリーダーしかできないので、リーダーに作業を依頼する必要がありました。
リーダーの時間を奪わないように手順書を作成しましたが、作業する中で手順書に書きもれている工程もあり、他の方に作業していただくイメージを膨らませる力はとても大事だなと勉強になりました。
権限、ロールの設定が難しい
勉強中の開発ではそこまでロールの設定など細かく考えることは正直できていませんでしたが、組織での開発となると当たり前ですがそうはいきません。
余計なポリシーをつけないようになどチームリーダーにもチェックいただきましたが、個人的にはロール、ポリシーの設定が一番難しかったです。
GitHub token、どのアカウントで発行すればいい？
LambdaからGitHub Actionを実行する際に、GitHub tokenが必要でした。
個人開発ではもちろん個人のアカウントで発行しましたが、組織ではどのアカウントのGitHub tokenを発行すべきか悩みました。
結局、組織共通のアカウントがあったのでそちらのアカウントで発行しましたが、こういった組織で開発する時のノウハウ的なものは私にとってはとても新鮮で、もっと吸収していく必要があると実感しました。
仕組み化すると組織内に喜んでくれる人がいる
自分だけでなくチームメンバーの開発者体験向上に貢献できるという点が一番大きな違いでした。
軽微な変更かもしれませんが、私自身挑戦してみてとても楽しかったですし、開発者体験向上が結果的にお客様への価値提供にも繋がってくると思うので、開発者体験向上につながるタスクにこれからも挑戦していきたいと思いました。