開発チームの成功は、リリースの頻度と成功に依存します。リリースが遅すぎるチームはビジネスの需要やイノベーションに追いつくことができず、失敗したリリースが多すぎるチームは顧客満足度、収益、全体的なシステムの安定性に悪影響を及ぼします。
Google のDevOps Research and Assessment （DORA）チームは、ソフトウェア開発組織のパフォーマンスを示す 4 つの主要な指標を特定しました。 当社のInnovation and Growthバリュー ドライバーは、これらのメトリックを使用して、より効率的で応答性の高い開発チームと、より信頼性の高いアプリケーションを作成する全体的なプログラムを作成します。 このリリース品質ガイドは、アプリケーションのリリース頻度、アプリケーションのパフォーマンス、およびアプリケーションの信頼性を向上させるのに役立ちます。
重要な概念
Kepの概念は次のとおりです。
伝える、修正する、革新する
New Relic の可観測性成熟度実践の中心テーマの 1 つは、「コミュニケーション、修復、革新」です。私たちは、特定の KPI を使用して開発実践の現状を関係者に伝達できるようにすることで、このテーマをサポートします。次に、これらの KPI を使用して開発慣行を調整し、遅くて信頼性の低いアプリケーション コンポーネントを特定して、後続の開発スプリントで修正できるようにします。最後に、これらの KPI を使用して開発実践をより効率化し、チームがイノベーションに費やす時間を追加します。
トランクベースの開発
トランクベースの開発は、「ソース管理の分岐モデルであり、開発者はtrunkと呼ばれる単一のブランチでコードに共同作業を行い、文書化された手法を使用して、他の長期開発ブランチを作成するというプレッシャーに抵抗します。」と定義されています。 つまり、開発作業を単一のトランクのブランチに対して実行される小さなバッチに分割します。 1 つの作業バッチが完了するとすぐに、ブランチはトランクにマージされます。 各ブランチの有効期間は短いため、トランクへのマージが簡単になり、すべての開発者がコードベースの最新リリースで作業できるようになります。
この実践は、DevOps Research and Assessment (DORA) 組織によって、より迅速な提供と組織のパフォーマンスの向上を促進する重要な機能であると認識されています。これは CI/CD の必須の実践です。
ITサービスバウンダリー
リリース品質の向上は、IT サービス境界のレベルで機能します。境界でサービスを測定することで、その上流で何が起こっているかを把握できます。
サービス レベル管理ガイドでは、サービス境界の概念を使用して、特定のサービスの応答時間とエラー率を測定します。このガイドでは、同じ概念を使用して、開発実践がサービスに与える影響を測定し、開発チームの応答性、革新能力、アプリケーションの安定性を向上させます。
主要業績評価指標
開発品質プロセスを使用して、次のKPIを収集および測定します。
アプリケーションの特定
最初のステップは、改善プロセスの最初の反復の対象となるアプリケーションを特定することです。含めるのに適したアプリケーションは、次のようなアプリケーションです。
- 積極的に開発中
- 重要なオペレーションサービスである
- 開発サイクルが遅い
- 導入に失敗した実績がある
必要なKPIを収集する
次に、CI/CD プラットフォーム、ソース リポジトリ、可観測性ソリューションなどのソースから定義された KPI を収集する必要があります。KPI のソースを特定したら、それらを抽出して New Relic プラットフォームにインポートする方法を特定する必要があります。
KPI と最低限必要な属性については、上記の主要業績評価指標のセクションで確認できます。通常は、開発ツールチェーンの API を使用して KPI とその属性を抽出し、カスタム イベント APIを使用してそれらを New Relic に送信します。
カスタム統合作業を開始する前に、目標を満たすすぐに使用できる統合が存在するかどうかを判断する必要があります。
ダッシュボードの実装
当社の品質改善プロセスの主な推進力です。 KPI と傾向が表示されるので、改善の取り組みを特定して優先順位を付けることができます。 サンプルダッシュボードは、GitHub のオバハビリティ成熟度リソース センターにあります。
ダッシュボードに表示される情報は開発ツールチェーンによって異なるため、正確な仕様に合わせ てダッシュボードをカスタマイズする必要があります。
リリースのベースラインを確立する
初期有効化を実行する前に、ベースラインを形成するのに十分なデータが必要であるため、開発アクティビティのサンプルから構成されるベースラインを確立する必要があります。通常、これには最低 2 週間かかりますが、現在の開発ペースによっては最大 6 週間かかる場合があります。これを行う簡単な方法の 1 つは、ベースラインの収集と評価サイクルをアジャイル スプリントに合わせることです (該当する場合)。
ベースラインを確立する間、イベント データが New Relic に期待どおりに蓄積されていることを定期的に確認する必要があります。
チームと会う
ベースラインを確立したら、開発チームやその他の関係者に、収集されたデータと、従うことになる継続的な改善プロセスを紹介します。
このプロセスは4つのアクティビティで構成されています。
Introduce the concepts of trunk-based development
: あなたと関係者は、トラックベースの開発の中核となる概念を確認し、現在の実践と異なる点を特定し、それを実装するための戦略を作成します。
Review your release KPIs and trends
: リリース率、リリース サイズ、およびスコープの KPI を確認して、トランクベースの開発の実装に向けて進捗していることを確認します。 目標は、新しいリリースのサイズと範囲を縮小しながら、リリース率を上げることです。
Review your application KPIs and trends
ここでは、アプリケーションのパフォーマンスとエラーの KPI を確認して、アプリケーションの信頼性とパフォーマンスの向上に向けた取り組みを特定し、優先順位を付けます。
Make technical recommendations
: ここでは、あなたと関連する利害関係者が、リリース ワークフローや可用性戦略の変更などの技術的な推奨事項を特定して確認します。
改善プロセスを開始する
この最後のステップは継続的な改善プロセスです。このフェーズでは、チームと会い、ベースラインに対する進捗状況を確認し、望ましい改善を実現できるように戦略を調整します。改善プロセスの各サイクルは、開発プロセスを数回繰り返した後に行う必要があります。通常、これらはすべてのアジャイル スプリントの中間点と終了時に発生します。
この段階では、あなたは
- KPI を毎週関係者に報告して、チームが作業に適切な優先順位を付けていることを確認し、約束されたビジネス成果に向けた進捗状況を示します。
- 新しいベースラインを確立し、改善率を示すために、毎週の KPI を長期間にわたって記録して保持します。