--- title: リリース改善会でのリリース作業改善の取り組み tags: author: [ida.](https://www.docswell.com/user/2314923968) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/DEY2X239EM.jpg?width=480 description: 『Tsukulink Tech Talk 〜業務をちょっと良くする話〜 #3』 https://tsukulink.connpass.com/event/330631 published: October 31, 24 canonical: https://www.docswell.com/s/2314923968/5MXLDX-2024-10-31-111218 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/DEY2X239EM.jpg) リリース改善会での リリース作業改善の取り組み ida.（@tech_ida） # Page. 2 ![Page Image](https://bcdn.docswell.com/page/VJN818VD78.jpg) 自己紹介 ida. (@tech_ida) 1996年生まれ 九州出身 エンジニア歴：10年くらい チーム：SRE 最近のブーム：禁煙（コツコツ53日目） 日本シリーズの観戦（美破!） # Page. 3 ![Page Image](https://bcdn.docswell.com/page/YE9K5K68E3.jpg) リリース改善の 取り組みについて 01 02 03 リリース改善会 立ち上げの経緯 リリース改善に行う にあたり注意した かった点 リリース改善の あれこれ 04 05 やってみた結果 のびしろ # Page. 4 ![Page Image](https://bcdn.docswell.com/page/GE8RYRZZJD.jpg) 当初のリリースワークフローについて 入社した時のツクリンクのリリースフロー 重い。エラー連発で安定しない 開始 Jiraでリリース作成、リ リース用チケットの作成 テストの実施結果の 確認 Testrailでリリース用の テストセクションを作成 リリース実施 リリース用PRの作成 リリース後の動作確認 GitHubでリリースノート、 リリースタグの作成 Git、Jiraでリリースを 発行! 50分の待機時間が発生 また、この過程のほとんどが手作業での作成、実施 Slackで検証環境で テストを実施依頼 TestRailの後片付け 重い。エラー連発で安定しない 終了 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/LELK4KD1JR.jpg) 当初のリリースワークフローについて めっちゃめんどくさい。。。 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/4JM2K2P5JW.jpg) 具体的にどう面倒なのか。 • リリース作業に半日くらい要する （当初のリリース頻度は2〜3日に1回とそこまで頻度が高くなかった） • ほとんど手作業で実施する • 決まった手作業を毎回やるので開発体験としてあまり快くはない • 慣れたらマニュアルを見なくなるので、作業漏れや誤りが発生 • ちょうど社員が増えてきており、都度この手順をラーニングしていた • メンバーの増加とともに生産性も上がりリリース頻度が1日に1回程度になって きた。 リリース当番の負荷が高く、また頻度も増えてきたことで 開発生産性のボトルネックとなるようになってきていた。 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/PJRMXM1ZE9.jpg) リリースフローを改善したいけど ツクリンクは絶賛グロース中！ （価値提供を優先に開発をしている） 今回のリリース改善を行うことによるビジネスインパク ト、実施効果が今開発しているものと比べたら軽薄 そのため、比較してどうしても優先度が下がる 主業務と切り離して、社内委員会活動として チームから有志で参加して改善活動を行う リリース改善会を立ち上げる # Page. 8 ![Page Image](https://bcdn.docswell.com/page/PEXV6VY17X.jpg) リリース改善に行うにあたり注意してたかった点 検証環境へのリリースと同じ感覚で本番リリースを行なって欲しくない！ リリース作業に工数を取られてしまったり開発体験が良くないのは事実。 ここに対して改善していくことが本来の目的なので、ここを否定してはいない。 ただ、ボタンひとつで本番リリースできる環境が出来上がった先に、 本番リリースへの意識が薄れ、確認やレビューが疎かになるような風潮は作りた くない。 本番リリースがどういうことかは意識させるようにする （これは本番でのワーニングやアラートにおいても同じことだよね。） # Page. 9 ![Page Image](https://bcdn.docswell.com/page/3EKQ1Q3MED.jpg) リリース改善に行うにあたり注意してたかった点 ただ、こちらは今回の本線ではないので先に結論から 各チーム検証環境での動作確認後の報告は自動化しない 各チーム検証環境での検証が問題なかった際に、 チーム毎に責任を持って本番稼働に向けたOKを出してほして欲しく 報告いただく従来のフローをそのまま利用 リードメンバーによるレビューを必ず実施する 当たり前ですが、 本番稼働判定を兼ねて、本番リリース前にはリソースを固めて全体的なレビューを リードメンバーで必ず実施する。 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/L73PQPG2E5.jpg) マニュアルをslackワークフローに移行する ワークフローに移行することで、マニュアルの廃止、通知作業の自動化を実現 ・自動で手順が通知されることにより、作業漏れ、メンション漏れの防止 ・ドキュメントの廃止（形骸化への対策） # Page. 11 ![Page Image](https://bcdn.docswell.com/page/87DL9L16EG.jpg) オートメーションツール等による自動化 規則性のあり、自動化できる作業を自動化。 これにより作業負荷の低減、ヒューマンエラーの回避 リリースPR作成スクリプト作成、発行 Gitのリリースの自動作成 GHAで実装 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/VJP2Z25ZJ8.jpg) テストケース管理ツールを変更 （使い方なのが悪いのか）Testrailがよくエラーになったり固まったりということ が多くあり無駄に時間がかかっていた。 • ツクリンクはエンジニアのテストと別にQAチームによるQAテスト • リリース作業の中ではエンジニアの簡易的なテストのみ実施、管理している エンジニア側のテストはケースを羅列して、実施結果を記録しているだけ • リスト化できれば問題ないので、notionに変更 これが結構好評！ # Page. 13 ![Page Image](https://bcdn.docswell.com/page/2EVDWDPMEQ.jpg) CI/CDの改善 昨年AWS移行したが、そこからかなりCI/CDが遅くなっていた。 当初は50分かかっており、リリース開始してからリリース完了まで長く、 リリース完了が忘れたりしていた。 ここはSREチームのタスクにも落とし込み対応を実施した。 リソースクラスの最適化 テストで利用しているコンテナのリソースクラスをスケールアップ （medium -> large） 5分間の短縮 ワークフローの並列実行 ・テストと本番ビルドを直列にして実行していたので、テストと本番ビルド 10分間の短縮 を並列で実行する。テストと本番ビルドはどちらも10分かかっていたので10 分の短縮 ・デプロイ前に実行するRUNタスクをひとつにまとめることでFargateの起 10分間の短縮 動、停止時間の削減 コンパイル位置の変更 当初はアプリケーション上の制約があり、ビルド時にassets:precompileを 実施できずサーバ起動時に実行していた。 これをアプリケーションの制約を解消し、ビルド時に実施するように変更 3分間の短縮 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/57GYDYPX7L.jpg) やってみた結果 作業時間の短縮割合 リリース改善会前は1回に4時間程度かかっていた 作業がリリース改善後は1時間程度に短縮！ 改善前後で 75%削減 さらに ・自動化やストレスポイントの削減により、リリース作業に対する開発体験の向上 ・毎日のリリースに耐えうるリリース作業に！ # Page. 15 ![Page Image](https://bcdn.docswell.com/page/4EQM1M25JP.jpg) のびしろ（残課題） リリース後の動作確認 リリースワークフロー完了後、現在手動で反映確認、正常稼働確認を行なっている。 ここは自動化できそう。(AWS Syntheticsで自動化検証中) アプリ間のシームレス連携 Slackワークフロー、Jira、Gitがまだ独立しており、各サービスに対して 作業を行なっている。シームレスに連携して動作することで、 さらにヒューマンエラーの確率低下と、開発体験の向上が期待できる。 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/KJ4VRVLVE1.jpg) Thank you for your attention!