リリース改善会でのリリース作業改善の取り組み

リリース改善会での リリース作業改善の取り組み ida.（@tech_ida）

自己紹介 ida. (@tech_ida) 1996年生まれ 九州出身 エンジニア歴：10年くらい チーム：SRE 最近のブーム：禁煙（コツコツ53日目） 日本シリーズの観戦（美破!）

リリース改善の 取り組みについて 01 02 03 リリース改善会 立ち上げの経緯 リリース改善に行う にあたり注意した かった点 リリース改善の あれこれ 04 05 やってみた結果 のびしろ

当初のリリースワークフローについて 入社した時のツクリンクのリリースフロー 重い。エラー連発で安定しない 開始 Jiraでリリース作成、リ リース用チケットの作成 テストの実施結果の 確認 Testrailでリリース用の テストセクションを作成 リリース実施 リリース用PRの作成 リリース後の動作確認 GitHubでリリースノート、 リリースタグの作成 Git、Jiraでリリースを 発行! 50分の待機時間が発生 また、この過程のほとんどが手作業での作成、実施 Slackで検証環境で テストを実施依頼 TestRailの後片付け 重い。エラー連発で安定しない 終了

当初のリリースワークフローについて めっちゃめんどくさい。。。

具体的にどう面倒なのか。 • リリース作業に半日くらい要する （当初のリリース頻度は2〜3日に1回とそこまで頻度が高くなかった） • ほとんど手作業で実施する • 決まった手作業を毎回やるので開発体験としてあまり快くはない • 慣れたらマニュアルを見なくなるので、作業漏れや誤りが発生 • ちょうど社員が増えてきており、都度この手順をラーニングしていた • メンバーの増加とともに生産性も上がりリリース頻度が1日に1回程度になって きた。 リリース当番の負荷が高く、また頻度も増えてきたことで 開発生産性のボトルネックとなるようになってきていた。

リリースフローを改善したいけど ツクリンクは絶賛グロース中！ （価値提供を優先に開発をしている） 今回のリリース改善を行うことによるビジネスインパク ト、実施効果が今開発しているものと比べたら軽薄 そのため、比較してどうしても優先度が下がる 主業務と切り離して、社内委員会活動として チームから有志で参加して改善活動を行う リリース改善会を立ち上げる

リリース改善に行うにあたり注意してたかった点 検証環境へのリリースと同じ感覚で本番リリースを行なって欲しくない！ リリース作業に工数を取られてしまったり開発体験が良くないのは事実。 ここに対して改善していくことが本来の目的なので、ここを否定してはいない。 ただ、ボタンひとつで本番リリースできる環境が出来上がった先に、 本番リリースへの意識が薄れ、確認やレビューが疎かになるような風潮は作りた くない。 本番リリースがどういうことかは意識させるようにする （これは本番でのワーニングやアラートにおいても同じことだよね。）

リリース改善に行うにあたり注意してたかった点 ただ、こちらは今回の本線ではないので先に結論から 各チーム検証環境での動作確認後の報告は自動化しない 各チーム検証環境での検証が問題なかった際に、 チーム毎に責任を持って本番稼働に向けたOKを出してほして欲しく 報告いただく従来のフローをそのまま利用 リードメンバーによるレビューを必ず実施する 当たり前ですが、 本番稼働判定を兼ねて、本番リリース前にはリソースを固めて全体的なレビューを リードメンバーで必ず実施する。

マニュアルをslackワークフローに移行する ワークフローに移行することで、マニュアルの廃止、通知作業の自動化を実現 ・自動で手順が通知されることにより、作業漏れ、メンション漏れの防止 ・ドキュメントの廃止（形骸化への対策）

オートメーションツール等による自動化 規則性のあり、自動化できる作業を自動化。 これにより作業負荷の低減、ヒューマンエラーの回避 リリースPR作成スクリプト作成、発行 Gitのリリースの自動作成 GHAで実装

テストケース管理ツールを変更 （使い方なのが悪いのか）Testrailがよくエラーになったり固まったりということ が多くあり無駄に時間がかかっていた。 • ツクリンクはエンジニアのテストと別にQAチームによるQAテスト • リリース作業の中ではエンジニアの簡易的なテストのみ実施、管理している エンジニア側のテストはケースを羅列して、実施結果を記録しているだけ • リスト化できれば問題ないので、notionに変更 これが結構好評！

CI/CDの改善 昨年AWS移行したが、そこからかなりCI/CDが遅くなっていた。 当初は50分かかっており、リリース開始してからリリース完了まで長く、 リリース完了が忘れたりしていた。 ここはSREチームのタスクにも落とし込み対応を実施した。 リソースクラスの最適化 テストで利用しているコンテナのリソースクラスをスケールアップ （medium -> large） 5分間の短縮 ワークフローの並列実行 ・テストと本番ビルドを直列にして実行していたので、テストと本番ビルド 10分間の短縮 を並列で実行する。テストと本番ビルドはどちらも10分かかっていたので10 分の短縮 ・デプロイ前に実行するRUNタスクをひとつにまとめることでFargateの起 10分間の短縮 動、停止時間の削減 コンパイル位置の変更 当初はアプリケーション上の制約があり、ビルド時にassets:precompileを 実施できずサーバ起動時に実行していた。 これをアプリケーションの制約を解消し、ビルド時に実施するように変更 3分間の短縮

やってみた結果 作業時間の短縮割合 リリース改善会前は1回に4時間程度かかっていた 作業がリリース改善後は1時間程度に短縮！ 改善前後で 75%削減 さらに ・自動化やストレスポイントの削減により、リリース作業に対する開発体験の向上 ・毎日のリリースに耐えうるリリース作業に！

のびしろ（残課題） リリース後の動作確認 リリースワークフロー完了後、現在手動で反映確認、正常稼働確認を行なっている。 ここは自動化できそう。(AWS Syntheticsで自動化検証中) アプリ間のシームレス連携 Slackワークフロー、Jira、Gitがまだ独立しており、各サービスに対して 作業を行なっている。シームレスに連携して動作することで、 さらにヒューマンエラーの確率低下と、開発体験の向上が期待できる。

Thank you for your attention!