リリースサイクルの見直し
こんにちは、microCMS FMです。
この番組は、microCMSの中の人が、 いろいろなトピックについて雑談する番組です。
最初に自己紹介ですが、 僕がPMをやってます平松です。
そして、
はい、自分はmicroCMSのCTOをやってます大西です。 よろしくお願いします。
お願いします。
今日のテーマなんですけど、今日のテーマが、 品質高くリリースサイクルを早めるために一度立ち止まった話ということで、
話していきたいです。これは何ですか?
そうですね、ここ1、2ヶ月ぐらいですかね。
1、2ヶ月ぐらい、機能開発基本的にちょっと手を止めて、
いろいろ技術不細と言いますか、品質高く、
リリースサイクルを早めるために、
結構いろいろ足回り固めたりとかするっていう、 具体的に言う前に、
今まで週1でリリースをしてたんですよね、 リリースサイクル週1でやってまして、
1年ぐらいかな、1年ぐらいずっとそんな感じでやっていて、
それはそれで割と定着してて良かったんですけども、
頻度高くリリースした方が素早く価値届けられたりするし、
お客様にこういう不具合がありますとか、 ちょっとこういうふうに改善して欲しいですみたいな言われた時に、
1時間後ぐらいに対応しましたみたいなやってね、
結構喜んでもらえるみたいなイメージがつくじゃないですか。
熱いよね。
それ結構熱いので、その世界観をやりたいなと思ってたのと、
これは平松さんとも話してたことですけど、
あともう一個はエンジニアのノー負荷と言いますか、
来週月曜日にリリースするから、 その間にこっちのタスクやっておこうかなみたいな、
微妙な並行状態が、僕はそういうの得意じゃないっていうのもあって、
疲れるというかね、覚えておくのもしんどいし、
時系列がぐちゃるんで、それも出来上がったらすぐリリースするみたいな感じでね、
メインブランチにマージしてリリースして、はい終わりみたいな、
で次のタスクやるみたいな、結構すっきりいくじゃないですか。
っていう2つ大きくあって、
なので結論言うと、今後は出来上がったらすぐリリースするという、
都度リリースする、週1リリースやめて、
オンデマンドでリリースしていくというフローに変わりますっていう、
それを変えるために、ちょっと1、2ヶ月ぐらい、
技術不細の返済もついでにという感じで色々やってました。
自動テストの強化
やってたこととしては、自動テストですね、
リミットテストとか言いついテストとか、
結構元々結構やってはいたんですけど、
もうちょっと充実させようというのでやってましたね。
カバレッジも100%近く上げたりとかしましたし、
なんでしょうね、結構不具合が起こりがちなメインのシステムじゃないんだけど、
結構バグりがちなシステムの、一旦言いついテストみたいなの作って、
それ決済絡むやつ、ストライプの決済絡むやつだったんで、
ストライプ絡めて言いついテストするみたいな、
ちゃんとストライプで正しい課金がされてるかみたいな。
そういうのをやるようにしましたね。
結構大変でしたけどやりましたね。
自動テスト充実させたのと、
あと分散トレーシングって言うんですかね、
トレースログを結構今まで結構ログ出力も整ってたり整ってなかったりだったんで、
その辺りも丸といい感じにログを出すようにして、
不具合あったりとか調査するときにどこで何が起こってたのかみたいなのを、
把握しやすくしましたね。
あとデータベースのクリーニングみたいなのもしまして、
なんか分かんないですけど多分歴史的経緯で変なデータが入ってるレコードとか、
結構あったんですよね。
そういうのを削除したり、データの型を変えたりとかいろいろ綺麗にして、
あとはですね、
あとライブラリーの更新。
これも基本的にはライブラリーの更新もしてって言ってたんですけど、
AWS SDK v2とかですね、
なんか結構使い方変わったりとか、
破壊的変更系のメジャーバージョンアップ系のやつでやってないやつがあったんで、
その辺もアップデートして出ましたね。
ちょっと僕がずっとしゃべる感じになりますけど、
開発環境の改善
こうやってラジオの音があるから。
もうちょっと聞こうかな。
もうちょっとね。
あと開発環境の改善も、開発者体験の改善もやってまして、
AWSのログイン方法というか権限管理方法をモダン化して、
アイデンティティセンターとか使うようにして、ちょっとモダンにしたりとか、
あとはDevContainerを使うようにしました。
チーム全員でVS CodeのDevContainerを。
平間さんDevContainer知ってます?
最近ちょっと触り始めました。
開発環境ね、Dockerで開発環境立ち上げてってやるので、
各々のマシン、ローカルマシン上にいろんなツールを入れて、
みんなでバージョン管理したりとかしなくても、
DevContainer使えばみんなで同じ環境使えるみたいになりました。
DevContainer自体は新しい技術ですか?
新しい…もう何年ですかね。
高校に入ると6年とかだったかな。
新しいってほどではないかな。
ある存在はみんな知ってたけど、環境を整えるみたいな腰を入れる必要があって、
今やってるみたいな。
そうですね。
あとはチームの合意とかもね。
これも好き嫌いは変えたりするんですよね。
そうかもね。
でも我々はDevContainerでみんなで同じでよくないってなって、
それでいいですよねってなったからみんなで同じの使ってるって感じですね。
なるほどなるほど。
でも結構いいですね。
僕も最近結構コード書くようになったんですけど、
本当立ち上げるだけでいいから。
Goのバージョンが違うなとか、ノードのバージョンが違うなとか、
そりゃないんでめっちゃ楽ですね。
意外とそういうので開発止まったりするもんね。
そうそう。
でなんかね、チャンネルで聞いて、バージョンがおかしいみたいですねみたいな。
僕はこれで動いてますみたいなね。
あんまり意味のない時間かなと思うので。
エディターこだわったりとか。
エディターこだわったりとか。
すごい使いたいとかね、こだわったりする人はちょっと向かないかもしれないですが、
幸い我々のチームにはそんなにいないので。
それでかなりスムーズに曲がってるって感じですね。
でも結構良かったです、これは。
最後、リリースの改善ですね。
さっき言った週1リリースやめて、
で、都度リリースにする。
何リリースって言うんですかね。
トランクベース開発とか。
ちょっと言い方わかんないですけど。
これもほぼほぼ達成できましたね。
これを?フローの改善ってのは何すること?
週1リリースを都度リリースに変えるために、
コミットがあるたびにステージング環境みたいな動作確認環境があるんですけど、
そこでE2Eテストを全部回したりとか。
なるほど。
都度コミットがあるたびにね。
今までデイリーで1回だけ回すみたいな感じでやったんですよね。
月曜日のリリース前に回すみたいなのをやってたんですけど。
もっと頻度高く。
頻度高くね。
コミットがあるたびに全部チェックしますよっていう感じで今やろうとしてますしね。
E2Eテストって時間かかるイメージあって、
それで1日1回とかにしてたのかなと思ったんですけど、
そこらへんは問題なってないですか?
まだわかんないです。
やってみて。
やってみてって感じですね。
ちょうどそういう風に変えようとしてて。
確かにでもそれは多分ありますね。
E2E全部ほんまに回すと40分とか30分とか40分かかるんで。
ちょっとフィルターして本当に重要なやつだけ回すみたいなのも仕組みとしてはできるから。
1回全部回してみてって感じですね。
なるほど。
問題にならないかもしれないし。
そうなんですよね。
別にステージ環境って誰かの作業が止まるわけじゃないから、
各々の開発環境があるので、
別に回しててもいいかなっていう気はしますね。
なるほど。
しかも本当に全部のコミットっていうよりは、
アプリケーションコードとかに差分があったときだけとかなんで、
いけるかなとは思います。
こうやって並べるとテストは事前に風が入れないように防ぐみたいなのもあれば、
トレーシングとかってあれですよね。
バグったときに追跡しやすくして。
バグったときじゃないかな。
何か起きたときに原因を調べたりとかしやすくする。
デブコンテナみたいな開発環境の改善もあって、
結構いろいろ他ジャンルやってるっていうイメージですね。
そうですね。
こういう時間作るとあれもついでにやっとくか、これもついでにやっとくかで、
結局ちょっと伸びちゃったりはしたんですけど。
でも結構1、2ヶ月でやった割には、
かなりいろいろ改善できたかなと思いますね。
何を言おうとしたらいいんだろうな。
なので都度リリースするってなると品質がどうしても気になるとこですけど、
それを担保するために自動テストを再度カバレッジ高めようとか、
いついテストもうちょっと足りてないとこやろうとかっていうのも、
前半やって後半でリリースフロー周りを整え直したみたいな。
足元固めてチャレンジングなことするみたいな。
チャレンジングなことだけしてたらバグりそうなんですけど。
こういう開発環境の改善とかって普段からやってることではあったじゃないですか。
全員新規開発も止めて全員でそこやるみたいなのはやってよかったことですか。
めっちゃよかったですね。
普段やらないプロダクトエンジニアの人とかはバックエンドとかインフラとかデータベースとかあんまり
スクリプト書いて何かやるとか調査するとかなかったんですけど、
その辺やれるようになったエンジニアもいますし、いいですよね。
普段はちょっと領域分かれてるみたいなのがあるんですけど、
開発チームの新しい取り組み
こういう非日常のプロジェクトみたいなのをやると全然違う領域のタスクがあったりするんで、
こんな風になってたんだなとか分かったりもするんじゃないでしょうかね。
システム全体の理解度は上がるよね。
上がると思いますね。
そこで結局フロントエンドやってる人たちはフロントエンドの課題だけお願いしますみたいな、
結局そうやってたらあんまり伸びしろないと思うんですけど、
割とその辺はぐちゃぐちゃにやったんで。
あえて意識して。
意図してるか意図してないかちょっと分かんないですけど、
割と手空いていったら一旦これ調べてもらおうかなみたいなんで雑に。
でもそれでいいじゃないですか。
調べながら。
今チャットGPTもついてくれてるからすぐ分かるし。
社内に聞ける人もいるし。
だから個人的には開発チームバージョン2と思ってます。
メジャーバージョン。
メジャーバージョンアップしました。
勝手に。
それ楽しみですね。
2ヶ月やって、結局その都度リリースっていうのはできそうなんですか?
できると思います。
あとちょっとGitHubアクションを整えてる気がしますね。
すごいね。
なんか大事ですよね。
お客さんからここなんかちょっと変なんですけどみたいなのを
1時間後ぐらいに修正するみたいな個人開発でやってるようなこと。
大事ですよね。
やっぱいろんなサービスが超初期の頃は全員やってたことだと思うからね。
徐々にそれが腰が重くなっていくというか。
なってしまうものだと思うんですけど。
感性としては。
先に働くけど、ここでもう1回リリースサイクルを短くするという。
そうですね。
PM的にも嬉しいですね。
我々も実は1年前、週1リリースの前は
デイリーだったりとか。
それこそ都道リリースと言いますか。
やってはいました。
ただその時は足元あんまり固められてなかった。
不具合があったりとかして。
結構迷惑をかけてしまったというので。
一度引き締めるというか、週1リリースでちょっとゆっくり行こうかみたいな。
やりましたよね。去年はだから。
去年も安定性向上みたいな1ヶ月ぐらい手を止めてやったんですけど。
その時はほぼテストでしたかね。
自動テストを書くみたいな。
それだけをやってましたかね、その時は。
安定性の向上とテストの重要性
そうでしたね。
そこから皆さんのレベルも上がったんでできることも増えて。
今回はそういう風になったと。
今回は幅広くできましたかね。
去年に続いて開発止めて安定性向上というか改善するみたいなのが2回目だと思うんですけど。
今回のってきっかけみたいなのあったんでしたっけ。
きっかけはあんま覚えてないですね。
僕が不具合とかをちゃんとインシデント管理して再発防止みたいなのを管理してやってるんですけど。
再発防止が割と溜まり気味になっちゃってたとか。
なのでちょっと1回その辺全部分担してやろうかみたいな。
それがきっかけだったような記憶はあります。
手が回らなくなってきてた感もある。
そうですね。
消化するより溜まっていくスピードが速かったみたいなところがあったから。
再発防止って結構大変やからね。
同じようなコンポーネントで不具合出るみたいなのなくするのもあったんですか?
ありましたね。
ありました。
あります。
そこの一応テスト、児童テスト、E2テストとか書いたりしたし。
改善はされてると思います。
本質的な改善に時間を使ったら。
どうですか?PM的には週1リリースよりいいですか?
かなりいいんじゃないですかね。
自分も最初大西くん言ってくれた、ユーザーにすぐ届くっていうのとエンジニアの脳負荷。
脳負荷ってある言葉?大西くんが作った言葉?
多分わからないです。
脳負荷も下げられるし、外向きにも内向きにもいいっていう印象ありますね。
ただテストとかで品質どれくらいカバーできるのかとか。
週1でリリースタイミング少ない方がチェックポイントは作りやすいというかね。
そこで問題ないか見てとかはやりやすいから。
ここら辺のバランスは見ていかなあかんけど。
希望としては即時リリースなんで嬉しいです。
品質ですね。
自動テストやら何やらはもちろんやりましたが、
今後も手動のマニュアルの受け入れテストとかは都道リリースと言いつつも、
都道リリースの中で受け入れテストしなあかんやつはしていくので。
そこはそんなに変わらずですね。
確かに。
この受け入れテストが平松さんが今やってるから、
平松さんが早く終わらせないとその後のリリースに詰まっていくということにはなるんで、
プレッシャーはかなりある。
ボトルネックとして可視化されてしまう。
それは嬉しい悲鳴というかね。
確かに。
あとQAエンジニアも採用募集してますもんね。
そうですね。募集してます。
まさしくこの辺の品質保ちつつリリース早く早めるみたいなことに興味ある人にぜひ応募いただきたいなと思ってますね。
受け入れテストは平松さんの代わりにやるとか、それはもちろんあるかもしれないんですけど、
テストするだけじゃなくてね、
フロー全体を再起化するみたいなね。
何回も言うけど、品質を保ちつつデリバリーの頻度を上げるみたいな。
そこですかね。
今はまだうちQAエンジニアっていうポジションの人はいないので、1人目ですね。
1人目のQAエンジニアを大募集しております。
なんかいろいろ話しながらフローを整えてくれたりする、いい方が入ってくれるとありがたいです。
そうですね。
PMもエンジニアですし、僕もエンジニアなんですけど、
ほとんどエンジニアの会社なんで、
その辺の開発の解像度が高い人たち同士で喋ってフローを決めたりできるんで、
スムーズにその辺とかいけるんじゃないかなと思いますね。
確かに。
そんな感じですか。
そんなところですかね。
結構いろんなツールとかもサクッと導入したりする文化がありますので、
自分なりのQA理想像みたいな、こういうツール使ってこういう風にフローを組んでこういう風にやるのがいいんだ、
みたいな思ってる人とかはかなり実現しやすいんじゃないかなって思います。
そういうの聞きたいよね。
言いたいですよね。
これがいいんですよ、みたいな。
やっぱ品質保つ、担保するみたいなのめっちゃ難しいことだと思うから、
それの、なんていうのかな、ベストプラクティスじゃないけど観点というかね、
こういう風にしたらいいんだみたいな。
品質品質って言っても不具合とかのダメな方のあれと、
ボタンの押し心地とかUIの分かりやすさとかね、
そういうユーザビリティというかユーザ体験的なところもあるし。
確かに。
いろいろあります。その辺も専門家が欲しいですね。
言葉の整理とかもね。
新品を出してくれる人が欲しいですよね。
一緒に働きたいですね。
そうですね。
ありがとうございます。
じゃあ今回はそんな感じですかね。
ありがとうございました。
ありがとうございました。
