Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ACES Meet におけるリリース作業改善の取り組み
Search
Masashi Fukuzawa
October 02, 2024
Programming
0
270
ACES Meet におけるリリース作業改善の取り組み
Presenting at the following event on October 2, 2024
https://cybozu.connpass.com/event/328524/
Masashi Fukuzawa
October 02, 2024
Tweet
Share
More Decks by Masashi Fukuzawa
See All by Masashi Fukuzawa
ACES Meet の「2025年」を振り返る
fukucheee
0
35
Other Decks in Programming
See All in Programming
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
730
セキュリティマネジャー廃止とクラウドネイティブ型サンドボックス活用
kazumura
1
160
OpenNext + Hono on Cloudflare でイマドキWeb開発スタックを実現する
rokuosan
0
120
UPDATEがシステムを複雑にする? イミュータブルデータモデルのすすめ
shimomura
1
520
ReadMoreTextView
fornewid
0
250
TypeScript を活かしてデザインシステム MCP を作る / #tskaigi_after_night
izumin5210
5
520
赤裸々に公開。 TSKaigiのオフシーズン
takezoux2
0
110
FastMCPでMCPサーバー/クライアントを構築してみる
ttnyt8701
2
130
Cursor Meetup Tokyo ゲノミクスとCursor: 進化と制約のあいだ
koido
2
950
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
890
レガシーシステムの機能調査・開発におけるAI利活用
takuya_ohtonari
0
560
iOSアプリ開発もLLMで自動運転する
hiragram
6
2.3k
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
7
470
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.8k
The Language of Interfaces
destraynor
158
25k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
RailsConf 2023
tenderlove
30
1.1k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Transcript
ACES, Inc. AI ソフトウェア事業部 福澤 将史 ACES Meet における リリース作業改善の取り組み
2 CONFIDENTIAL 自己紹介 福澤 将史 Masashi Fukuzawa 所属: 株式会社ACES /
AIソフトウェア事業部 ポジション: サーバーサイドエンジニア / テックリード 出身: 福岡 好きなラーメン屋: 一九ラーメン (粕屋店) その他: 社会人学生としてCSを学び直し中
3 CONFIDENTIAL 会社紹介 / サービス紹介
4 CONFIDENTIAL AI研究と社会実装をリードする東大松尾研究室メンバーを中心に創業。 AIアルゴリズムという独自の視点から事業を創出 東大松尾研AIベンチャー …
5 CONFIDENTIAL 活用が困難だったお客様とのやり取りをデータベース化し、 営業力を強化する活動に活用できる営業支援AIツールです。 ACES Meetとは お客様とのやり取り お客様とのやり取りをDB化・活用する 営業支援AIツール 営業力の強化
DB スキルアップ・育成 商談記録・引継ぎ 勝ちパターン 活用
6 CONFIDENTIAL ACES Meet におけるリリース作業改善の取り組み
7 CONFIDENTIAL ACES Meet はまだプロダクトマーケットフィット (PMF) したとは言えない 高速にリリースを回し、フィードバックをもらう機会を増やすことが重要 前提: ACES
Meet の プロダクト状況について 出典: https://knowledge-bridge.info/marketing/2038/
8 CONFIDENTIAL PMF に向けてリリース頻度を上げていきたいが、リリース前準備が煩雑 リリース頻度が増えるとその分リリース作業に時間が奪われ、開発生産性が低下 リリース作業に関する課題感
9 CONFIDENTIAL 手作業で実施している リリース作業 様々な歴史的経緯で複雑化した運用を簡易化・効率化したいと考え、黄色の ハイライト箇所から改善に取り組み始めた ▪ デプロイ前 - リリース時の注意事項のリストアップ・確認
- PR 一覧の抽出 & 貼り付け => 改善1 - DB マイグレーションの有無 & 対象テーブルのレコード数の確認 => 改善2 - リポジトリ間のリリース順の確認 - AIのモデルアップデートの有無 - etc... ▪ デプロイ - 手動タグ打ち & Push による CI/CD のトリガー => 改善3 - Slack でデプロイ開始報告 => 改善3 ▪ デプロイ後 - リリース内容の共有 => 改善3
10 CONFIDENTIAL ▪ デプロイ前 - リリース時の注意事項のリストアップ・確認 - PR 一覧の抽出 &
貼り付け => 改善1 - DB マイグレーションの有無 & 対象テーブルのレコード数の確認 => 改善2 - リポジトリ間のリリース順の確認 - AIのモデルアップデートの有無 - etc... ▪ デプロイ - 手動タグ打ち & Push による CI/CD のトリガー => 改善3 - Slack でデプロイ開始報告 => 改善3 ▪ デプロイ後 - リリース内容の共有 => 改善3 手作業で実施している リリース作業 様々な歴史的経緯で複雑化した運用を簡易化・効率化したいと考え、黄色の ハイライト箇所から改善に取り組み始めた
11 CONFIDENTIAL 改善1: PR の洗い出し作業の 簡易化 Squash merge を強制 &
デプロイ用の PR を作成する運用に変更することで、リ リース対象を正しく・自動的にリストアップできるようにし、余計な作業を削減 before after
12 CONFIDENTIAL ▪ デプロイ前 - リリース時の注意事項のリストアップ・確認 - PR 一覧の抽出 &
貼り付け => 改善1 - DB マイグレーションの有無 & 対象テーブルのレコード数の確認 => 改善2 - リポジトリ間のリリース順の確認 - AIのモデルアップデートの有無 - etc... ▪ デプロイ - 手動タグ打ち & Push による CI/CD のトリガー => 改善3 - Slack でデプロイ開始報告 => 改善3 ▪ デプロイ後 - リリース内容の共有 => 改善3 手作業で実施している リリース作業 様々な歴史的経緯で複雑化した運用を簡易化・効率化したいと考え、黄色の ハイライト箇所から改善に取り組み始めた
13 CONFIDENTIAL 改善2: DB マイグレーションの 事前検知 元々、ALTER 文実行時のトラブル (*) を未然に防ぐために、変更対象のテーブルの
リストアップおよびデータ容量・レコード数を手動で確認していた デプロイ用 PR 作成時に、アラートコメントが自動生成されるようにした (*) 例えば、MySQL では ALTER 文を実行する時、テーブルのコピーが作られるが、この仕組みを知らずにデータ容量の多いテーブルに ALTER 文を実行してしまうと、 DB のストレージを一時的に枯渇させる危険がある。
14 CONFIDENTIAL 手作業で実施している リリース作業 様々な歴史的経緯で複雑化した運用を簡易化・効率化したいと考え、黄色の ハイライト箇所から改善に取り組み始めた ▪ デプロイ前 - リリース時の注意事項のリストアップ・確認
- PR 一覧の抽出 & 貼り付け => 改善1 - DB マイグレーションの有無 & 対象テーブルのレコード数の確認 => 改善2 - リポジトリ間のリリース順の確認 - AIのモデルアップデートの有無 - etc... ▪ デプロイ - 手動タグ打ち & Push による CI/CD のトリガー => 改善3 - Slack でデプロイ開始報告 => 改善3 ▪ デプロイ後 - リリース内容の共有 => 改善3
15 CONFIDENTIAL 改善3: CI/CD のアップデート デプロイ用 PR が特定のブランチにマージされたらタグ打ち・リリースノート生成・ デプロイ開始通知が実行される GitHub
Actions を実装 これにより、デプロイ自体の簡易化も実現
16 CONFIDENTIAL before / after まとめ リリース作業を簡易化することで作業時間を削減 リリース頻度が上がっても開発生産性を低下させないプロセスにアップデートできた
17 CONFIDENTIAL チームの反応 / 所感 ▪ チームの反応 (Slack / レトロスペクティブ)
▪ 所感 - 今回の改善を通じて、確認作業系は際限なくToDoを増やせるうえ、困ったときにはダブルチェックに逃げやすい性質が あることを改めて感じました。歴史を繰り返さないよう、今後は運用負荷を上げずに課題を解決できるアイデアを出し合 えるチームにしていきたいです。
None
19 CONFIDENTIAL (参考) テーブルのデータ容量・ レコード数を取得するSQL MySQL では information_schema.TABLES から各テーブルのメタデータの 取得が可能