プロダクトの価値から考える（LeanとDevOpsの科学編）
たなかゆうきすごく簡潔にまとめられている
たなかゆうき何故
・デプロイの頻度
・変更のリードタイム
・MTTR
・変更失敗率
が重要なのか、元論文を探して読みたい
↓
SDOパフォーマンスと可用性が高いチームは組織的な目標を達成する可能性が約２倍高かった
DORA の調査は、業界で適⽤されているソフトウェア開発と DevOps プラクティスへの洞察を提供し、6 年間に及ぶ科学的調査と、働く専⾨家からの 31,000 を超える調査回答に裏付けられています。今年は、世界中のさまざまな業界から約 1,000² の個⼈が参加しました。
過去 6 年間にわたり、ソフトウェアの配信とパフォーマンスの⾼レベルのシステム ビューを提供し、⽬標を達成する組織の能⼒を予測する 4 つの指標を開発および検証してきました。昨年、私たちは運⽤能⼒に焦点を当てた追加の指標を追加し、この指標が組織が優れた成果をもたらすのに役⽴つことを発⾒しました.これらの 5 つの指標は、システム レベルの結果に焦点を当てたソフトウェア デリバリーおよび運⽤
(SDO) パフォーマンスと呼ばれます。
速度と安定性に加えて、可⽤性は運⽤パフォーマンスにとって重要です。⼤まかに⾔えば、可⽤性とは、技術チームや組織が、運⽤しているソフトウェアに関する約束や主張を守る能⼒を表しています。特に、可⽤性とは、製品または製品を保証することです。また、より優れたソフトウェア配信はより⾼い可⽤性と密接に関連しているという昨年の調査結果も確認しました。分析によると、可⽤性の測定値はソフトウェア配信のパフォーマンス プロファイルと有意に相関しており、エリートおよびハイ パフォーマーは⼀貫
して優れた可⽤性を報告しており、エリート パフォーマーは強⼒な可⽤性を実践している可能性が 1.7 倍⾼くなっています
パフォーマンスを上げるための依存関係
エンジニアの生産性に関する依存関係
たなかゆうき以下の画像の一つ一つの要素を深堀（以下の画像は2019年のものなので、最新はURLから）
2022/11/23時点の最新
たなかゆうきバージョン管理
目的
- 再現性：完全に自動化された方法で、あらゆる環境をプロビジョニング（準備）できる必要があります。
- トレーサビリティ（追跡可能性）：どの環境を選んでも、その環境を作成するために使用するすべての依存関係のバージョンをすばやく正確に判断できなければなりません。また、環境の 2 つのバージョンを比較し、その環境間の変更点を理解する必要があります。
何につながるのか
- 障害復旧
- 監査可能性
- 品質の向上
- 容量管理
- 不具合に対する対応
方法論
注意点
- バージョン管理への commit のたびに、バージョン管理の情報のみを使用して環境にデプロイされるパッケージの自動作成がトリガーされるようにします。
- バージョン管理のスクリプトおよび構成情報のみを使用して、本番環境に似たテスト環境をオンデマンドで作成できるようにします。また、自動プロセスを使用してパッケージを作成できるようにします。
- 容量追加および障害復旧が完全に自動化された方法でできるように、テストおよび本番環境のインフラストラクチャのスクリプトを作成します。
https://cloud.google.com/architecture/devops/devops-tech-version-control
たなかゆうき継続的インテグレーション
in XP , out トランクベース開発
概要
継続的かつ緩やかにコードを統合しコードを成長させること。
目的
関連するシステムで多数のデベロッパーが作業している場合、コードの更新を調整するのは難しい問題であり、異なるデベロッパーによる変更に互換性がなくなる可能性があります。
これらの問題に対処するために、継続的インテグレーション（CI）が作成されました。CI は、なんらかの処理に多大な労力と時間がかかる場合、それを行う頻度を増やし、苦痛を軽減する必要があるという原則に従っています。
何につながるのか
進行中のソフトウェアの開発と保守に要するコストを削減して、チームの生産性を高められるようにします
- コンフリクトの軽減(リードタイムが長いPRが並行すると、コンフリクトが発生しやすい)
方法論
- 各 commit によって、ソフトウェアのビルドがトリガーされる必要があります。
- 各 commit によって、数分以内にフィードバックを提供する一連の自動テストがトリガーされる必要があります。
できるようにするために以下が必要。
- 自動ビルドプロセス。CI の最初のステップは、任意の環境にデプロイできるパッケージを作成する自動スクリプトを用意することです。
- 一連の自動テスト。まだ持っていない場合は、システムの価値の高い機能を網羅した少数の単体テストと受け入れテストを作成します。テストが信頼できることを確認します。
- チェックインごとにビルドテストと自動テストを実行する CI システム。また、システムでチームにステータスが表示されるようにする必要もあります。この処理については、少し遊び心を持って行うことができます。たとえば、クラクションや信号を使って、ビルドが失敗したことを示すことができます。メール通知は使用しないでください。多くのユーザーはメール通知を無視するか、通知を非表示にするフィルタを設定しています。うまく伝達できる、より利用しやすい方法はチャット システムの通知機能です。
- トランクベース開発の実施。デベロッパーは小さなバッチでトランク / メインラインを処理します。有効期間が長い機能ブランチで作業するのではなく、少なくとも 1 日 1 回、共有されたトランク / メインラインに作業をマージします。
- ビルドが中断した場合、その修正は他の作業よりも優先される必要があるという意見の合致。
CIって本当に有用なの？
ある程度纏まった機能を統合していった方が、効率が良いのではないか？
多くの場合、ブランチで実行されるように、デベロッパーが大規模な機能を宣言できるスピードを最適化する必要はありません。そうではなく、可能な限り迅速に変更のレビュー、統合、テスト、デプロイを行える必要があります。このプロセスにより、変更の規模が小さく、自己完結型であり、それらが適用されるブランチの有効期限が短い場合、より高速で安定した（PDF）ソフトウェアの開発と配信を行えます。また、小さなバッチで作業することで、他のデベロッパー、テスター、お客様から、あるいは自動化されたパフォーマンス テストやセキュリティ テストから、作業がシステム全体に及ぼす影響に対するフィードバックを定期的に得ることができます。これにより、問題の検出、優先順位付け、修正をより簡単に、すばやく行えるようになります。
→CIを導入することで、設計からリリースまでのフローのなるべく前段階でミスに気付けることがいいことが価値！！！！
計測方法
たなかゆうきトランクベース開発
概要
目的
実施方法
実際何がいいの？反対派意見への反論