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
ソフトウェア開発の生産性と信頼性向上に取り組んだ結果、どうなった?/What has ch...
Search
Genki Ogasawara
February 09, 2024
0
85
ソフトウェア開発の生産性と信頼性向上に取り組んだ結果、どうなった?/What has changed as a result of efforts to improve software development productivity and reliability?
Genki Ogasawara
February 09, 2024
Tweet
Share
More Decks by Genki Ogasawara
See All by Genki Ogasawara
サーバレスで挑む IoT プロジェクトの現実解 / Real solutions for the IoT project using serverless service
genkiogasawara
1
180
クラウドのスケーリングの力で5時間 かかるバッチジョブを10分に短縮する / Reduce the batch job time by a 36th using the power of scaling in the public cloud
genkiogasawara
1
16
IT知識ゼロからのスタートで、 事業部における内製開発をどうやって 推進してきたか?/How did we promote in-house development by starting from scratch?
genkiogasawara
1
190
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achieving BizDevOps in in-house development of cloud-native energy-saving services
genkiogasawara
2
810
エンジニアゼロの組織から内製開発の DX をどう実現したのか / How did we achieve DX in in-house development in an organization with zero engineers?
genkiogasawara
9
4.1k
入門 AWS Amplify Gen2 / Introduction to AWS Amplify Gen2
genkiogasawara
1
830
「魔の川」「死の谷」をクラウド ネイティブなチーム作りで越境する / Crossing the "Devil River" and "Death Valley" by building cloud-native teams
genkiogasawara
2
500
Amazon CodeCatalyst で実現!開発環境とCI/CDパイプライン
genkiogasawara
0
7.7k
Featured
See All Featured
Gamification - CAS2011
davidbonilla
80
5k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
860
Scaling GitHub
holman
458
140k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Speed Design
sergeychernyshev
24
610
The Cost Of JavaScript in 2023
addyosmani
45
6.7k
Building Your Own Lightsaber
phodgson
103
6.1k
Writing Fast Ruby
sferik
627
61k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
ソフトウェア開発の生産性と信頼性 向上に取り組んだ結果、どうなった? Genki Ogasawara 2024.2.9 KGX MAIN TALK
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
ソフトウェア開発の前提知識 ◆ 開発 機能要件に従いプログラミング ◆ ビルド プログラムを最適化したファイルに出力 ◆ デプロイ ファイルをサーバに展開する
Development Build Deployment
{ } … 個人開発とチーム開発の違い 複雑なバージョン管理 開発する機能ごとにタスクが 割り当てられるため、コードの バージョン管理が必要になる。さ らに、クラウドとローカルの開発 環境で同期を取る必要が
ある。 合意形成と履歴 組織単位の合意形成に時間を 要する。開発者は機能開発後に プルリクエストでレビューを 依頼する必要がある。レビューの 履歴は後から追跡できる必要が ある。 コードと環境の共有 ソフトウェアのコードおよび開発 環境の設定は共有する必要があ り、素早くセットアップできる必要 がある。場合によっては、クラウド の開発環境を用いることもある。
{ } … 個人開発とチーム開発の違い 複雑なバージョン管理 開発する機能ごとにタスクが 割り当てられるため、コードの バージョン管理が必要になる。さ らに、クラウドとローカルの開発 環境で同期を取る必要が
ある。 合意形成と履歴 組織単位の合意形成に時間を 要する。開発者は機能開発後に プルリクエストでレビューを 依頼する必要がある。レビューの 履歴は後から追跡できる必要が ある。 コードと環境の共有 ソフトウェアのコードおよび開発 環境の設定は共有する必要があ り、素早くセットアップできる必要 がある。場合によっては、クラウド の開発環境を用いることもある。 開発以外にもやることが意外とあるな・・・? 🤔
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
What is “Reliability” and “Productivity”?
Bedrock に聞いてみよう
ソフトウェア開発における信頼性と生産性とは何か? ◆ 信頼性 - Reliability • 想定通り機能する • エラーがない •
セキュリティリスクが少ない • 脆弱性が少ない ◆ 生産性 - Productivity • 自動化されている • チームメンバーの支援 • 試験的な取り組みができる • 変更が容易
ソフトウェア開発における信頼性と生産性とは何か? ◆ 信頼性 - Reliability • 想定通り機能する • エラーがない •
セキュリティリスクが少ない • 脆弱性が少ない プロダクトとして各機能が問題なく動くためのアプ ローチ、セキュリティに対するアプローチが必要に なる ◆ 生産性 - Productivity • 自動化されている • チームメンバーの支援 • 試験的な取り組みができる • 変更が容易
ソフトウェア開発における信頼性と生産性とは何か? ◆ 信頼性 - Reliability • 想定通り機能する • エラーがない •
セキュリティリスクが少ない • 脆弱性が少ない プロダクトとして各機能が問題なく動くためのアプ ローチ、セキュリティに対するアプローチが必要に なる ◆ 生産性 - Productivity • 自動化されている • チームメンバーの支援 • 試験的な取り組みができる • 変更が容易 開発者の煩わしさを取り除くアプローチ、実験する ことが許容されるような環境を作るためのアプロー チが必要になる
DevOps
DevOps 生産性と信頼性向上のためのアプローチ
DevOps 生産性と信頼性向上のためのアプローチ DevOps は、ソフトウェア デリバリーの速度とサービスの信頼性の向上、 ソフトウェアの関係者間の共有オーナーシップの構築を目的とする、組織 的で文化的な取り組みです。(Google より)
DORA Core Model DevOps Research & Assessment (DORA) DORA Core
Model ◆ ソフトウェアのパフォーマンス測定 - デプロイ頻度 - 変更のリードタイム - 変更失敗率 - 復元時間 優れている組織は、この4つの指標について高レベルである DevOps Four Keys Deployment frequency Lead time for changes Time to restore service Change failure rate
速度と安定性は両立する
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 チームによる正常な本番環境へのリリースの頻度
◆ 変更のリードタイム 開発者によるプルリクエストがレビューされ本番環境で 稼働するまでの所要時間 ◆ 変更失敗率 デプロイが原因で本番環境で障害が発生する割合 ◆ 復元時間 本番環境における障害が発生してからシステムが正常 な状態に復元するまでにかかる時間 {…} 開発者 レビュー 承認 レビュワー ステージング 環境 本番環境
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 チームによる正常な本番環境へのリリースの頻度
◆ 変更のリードタイム 開発者によるプルリクエストがレビューされ本番環境で 稼働するまでの所要時間 ◆ 変更失敗率 デプロイが原因で本番環境で障害が発生する割合 ◆ 復元時間 本番環境における障害が発生してからシステムが正常 な状態に復元するまでにかかる時間 ステージング 環境 本番環境 {…} 開発者 デプロイ デプロイ レビュー 承認 レビュワー
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 チームによる正常な本番環境へのリリースの頻度
◆ 変更のリードタイム 開発者によるプルリクエストがレビューされ本番環境で 稼働するまでの所要時間 ◆ 変更失敗率 デプロイが原因で本番環境で障害が発生する割合 ◆ 復元時間 本番環境における障害が発生してからシステムが正常 な状態に復元するまでにかかる時間 ステージング 環境 本番環境 {…} 開発者 デプロイ デプロイ レビュー 承認 レビュワー
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 チームによる正常な本番環境へのリリースの頻度
◆ 変更のリードタイム 開発者によるプルリクエストがレビューされ本番環境で 稼働するまでの所要時間 ◆ 変更失敗率 デプロイが原因で本番環境で障害が発生する割合 ◆ 復元時間 本番環境における障害が発生してからシステムが正常 な状態に復元するまでにかかる時間 ステージング 環境 本番環境 {…} 開発者 デプロイ デプロイ レビュー 承認 レビュワー
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった 環境ごとの自動デプロイ レビューの簡素化 失敗の検知
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった ステージング 環境 本番環境 開発環境 開発者 Deploy Command Deploy Command Deploy Command Login Login
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった ステージング 環境 本番環境 開発環境 開発者 Workflow Workflow Workflow Amazon CodeCatalyst の Workflow 機能を使って自動化
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった 開発者 Requierd Reviewer 全員が実装内容を確認したい という狙いもあった
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった 開発者 Requierd Reviewer 速度を優先しレビュアーを削減 コードレビューで実装内容を確認 Optional Reviewer
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった 開発者 Requierd Reviewer 速度を優先しレビュアーを削減 コードレビューで実装内容を確認 Optional Reviewer 自分の開発よりもレ ビュー優先
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった ステージング 環境 本番環境 開発環境 各環境を見に行くまで エラーが検知できない状態
DORA Core Model - DevOps Four Keys ◆ デプロイ頻度 手動デプロイによるビッグバンデプロイ
◆ 変更のリードタイム レビュアーが多いため開発者がプルリクエスト してから承認まで時間がかかっていた ◆ 変更失敗率 環境ごとに手動でコマンドを打ちデプロイをしなければ らなずデプロイによる失敗が頻発していた ◆ 復元時間 エラーが発生した場合に検知できていなかった ステージング 環境 本番環境 開発環境 各環境のログからメトリクスを 作成しSlack経由で通知 通知
アジェンダ 2 4 3 ソフトウェアのチー ム開発と 前提知識 ソフトウェア開発に おける生産性と信 頼性とは?
DORA Core Model DevOps Four Keys 改善のプラクティス 5 Future work & Summary 1
How have they changed to? 結局、どうなったの?
DevOps Four Keys Quick Check In 2019
DevOps Four Keys Quick Check In 2024
DevOps Four Keys Quick Check In 2024 🏻 🏻 業界平均を上回り、50ポイント近く改善
体感としてどうか? ◆ チームの変化 ・できるだけ自動化する文化が根付いた ・品質を担保することを意識するようになった ◆ 副次的な効果 ・変更失敗率低減のため、テストも導入できた ・開発サーバを立ち上げる速度が2分から数秒になった
Future works & Summary ・Quick Check のための定量的な計測をする 現在は感覚的に回答しているためメトリクスを取る仕組みを導入したい ・手動でシステムを復元しているため自動化する 失敗を検知した後に自動で前のバージョンにロールバックする
仕組みを導入し、復元までの時間を短縮したい
Thank you!