Share via

ツールとプロセスを標準化するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework オペレーショナル エクセレンスチェックリストの推奨事項に適用されます。

OE:04 開発とテストに関する業界で実証済みのプラクティスに従って、ソフトウェア開発と品質保証プロセスを最適化します。 明確なロールの指定については、ツール、ソース管理、アプリケーション設計パターン、ドキュメント、スタイル ガイドなどのコンポーネント間でプラクティスを標準化します。

関連ガイド: ビルド速度の | 向上継続的インテグレーションを使用する

このガイドでは、ソフトウェア開発ツールとプロセスの標準を定義するための推奨事項について説明します。 一貫したプラクティスを定義すると、効率的なワークロード チームと高品質の作業が行われます。 パフォーマンスの高いチームは、業界で実証済みのツールとプロセスを使用して、無駄な作業と潜在的なコード エラーを最小限に抑えます。

主要な設計戦略

開発プラクティスを最適化する最初のステップは、ツールとプロセスの標準化です。 可能であれば、社内ソリューションを開発するのではなく、業界で実証済みのソリューションを使用します。 プラクティスをさらに最適化するには、ローコードツールとノーコードツールを採用します。 これらのツールを使用すると、アプリケーションに集中し、時間の節約に役立ちます。 標準化するすべてのツールとプロセスに対して、トレーニングを実装して、チームがそれらを効率的に理解して使用できるようにします。 開発プラクティスの最適化に役立つ標準を定義するには、次の推奨事項を検討してください。

よく知られている、成熟した既製ツールを使用する

よく知られている成熟した既製のツールを使用し、その使用を標準化します。 非常に効果的なエンジニアリング チームは、クラス最高のツールを採用しています。 このアプローチにより、計画、開発、テスト、コラボレーション、継続的インテグレーションと継続的デリバリー (CI/CD) のためのソリューションを開発する必要性が最小限に抑えられます。 多くの企業では、開発者にいくつかのツールを選択できますが、すべてのオプションはorganizationの標準ツールであり、内部的に検証されます。 最も重要なのは、ワークロードの要件を満たすツールを選択することです。 市販のツールでは、次の機能を提供する必要があります。

  • 作業計画とバックログ管理

  • バージョン管理とリポジトリ

  • CI/CD パイプライン

  • 統合、煙、合成ユーザー、シミュレーション、カオス、その他の品質テストなどのテスト

  • コード開発

場合によっては、1 つのツールまたはツール スイートで複数の機能が提供される場合があります。 ツールの機能とその制限事項を理解し、機能全体の要件を満たしていることを確認します。

高価なツールまたは Premium バージョンのツールに投資する必要があるかどうかを判断します。 Premium ツールが提供する機能と比較して、独自のソリューションを開発する時間と労力を考慮してください。 1 回限りのコストと定期的なコストを考慮してください。 ほとんどの場合、既製のツールはチームにより高い価値を提供します。

実用的な場合は、ローコード、ノーコード、AI ツールを使用します。 ローコードツールとノーコードツールを使用すると、コード開発プロセス全体を実行するのではなく、機能を簡単にプラグインできるため、経験豊富な開発者の時間を節約できます。 これらのツールを使用すると、トレーニングされた開発者ではない可能性があるワークロード チーム メンバーがワークロードの運用に貢献することもできます。 AI ツールは、コード開発、レビュー、最適化に役立ちます。

ブランチ戦略を標準化する

可能な場合は、トランクベースのモデルを選択します。 トランクベースの分岐により、ワークロード開発チームの同期が維持され、継続的デリバリーが促進されます。 メイン ブランチなど、重要なブランチを保護するためのブランチ ポリシーを定義します。 詳細については、「 Git ブランチ戦略を採用する 」および「 ブランチのポリシーと設定」を参照してください。

メトリックを評価して開発の有効性を定量化する

ソフトウェア開発チームと品質保証チームは、その有効性を定量化できる場合にのみ改善できます。 有効性を定量化するには、 開発者の速度 を測定するメトリックを特定し、KPI を定義する必要があります。 これらのメトリックの例を次に示します。

  • デプロイ頻度: 各開発者が毎日デプロイするデプロイの数。

  • リード タイム: タスクまたはユーザー ストーリーがバックログから運用デプロイに移行するまでにかかる時間。

  • 平均解決時間: コード内のバグや欠陥の修正に費やされた平均時間。

  • 変更の失敗率: 失敗の原因となる変更の割合。

利害関係者とワークロード チームが速度を簡単に追跡できるように、ダッシュボードやその他のレポート ツールを使用して KPI を視覚化します。

ワークロード チームによるコードの記述、レビュー、ドキュメントの方法を標準化する

スタイル ガイドを使用して、ワークロード チームがコードの記述、レビュー、ドキュメントを行う方法を標準化します。 標準的なスタイルを使用すると、コラボレーションが簡単になり、オンボードの新しい開発者に役立ちます。 効果的に作業するには、新しい開発者がワークロード チームがどのように動作するかを知る必要があります。 明確に定義された標準を備えたスタイル ガイドを使用すると、トレーニング プロセスを容易にすることができます。 スタイル ガイドで、開発言語、ライブラリ、フレームワーク、およびその他の規則の標準を定義します。

実用的な場合は、ツールを使用してコード形式の標準を適用します。 たとえば、Visual Studio には、スタイル、品質、保守容易性、設計、その他の問題についてコードをスキャンするいくつかの ツール が用意されています。 コードとしてのインフラストラクチャ (IaC) の場合は、Checkov または Terrascan for Terraform を使用できます。

一貫性を確保し、混乱を避けるために、スタイル ガイドには、成果物、環境、ブランチ、ビルド、および実行の標準の名前付け規則を含める必要があります。

また、環境で許容される分散の程度に関するガイドラインと標準も設定する必要があります。 ワークロード チーム メンバーが標準リストに追加する新しい言語、フレームワーク、またはその他のテクノロジがある場合は、サンドボックスまたは下位環境でこれらのツールを使用するためのプロセスを実装します。 その実行可能性をテストし、必要に応じて既存のテクノロジを置き換えます。

アーキテクチャ決定レコード (ADR) を使用して 、ワークロード チームの設計上の決定の履歴を保持します。 ADR は、チームがワークロードを新たに理解するのに役立ちます。 また、新しいチーム メンバーが、ワークロードのライフサイクル中に行われる設計上の決定について学習するのにも役立ちます。 ADR がバージョン管理されていることを確認します。

ADR には、次のものが含まれます。

  • チームが選択する特定のツールとテクノロジ (SQL や NoSQL の使用など)。

  • チームが決定する理由。

  • 考慮されたその他のオプション。最終的な決定をコンテキスト化するのに役立ちます。

  • 決定に組み込まれる機能要件と非機能要件。

  • 対処された問題など、意思決定プロセスのコンテキスト。

技術的負債に対処するための標準を実装する

技術的負債は意図的であり、ワークロード チームの成果物に必要であるという考え方を採用します。 この考え方により、チームは蓄積を避けるために技術的負債を定期的に検討し、対処する動機が得られます。 バックログで定期的に繰り返されるタスクとして技術的負債に対処します。

たとえば、チームがライブラリで標準化されたとします。 時間の経過とともに、ワークロードの新機能のために別のライブラリに切り替える必要があります。 その移行により、技術的負債が発生する可能性があります。 このような移行は、2 つのテクノロジをスムーズに完全に移行できないため、ワークロード チームが 2 つのテクノロジをサポートする可能性が高い場合があります。 ワークロードが新しい機能を達成すると、利害関係者は満足し、技術的負債を考慮する可能性が低くなるため、ワークロード チームは移行の完了に優先順位を付ける必要があります。

成果物にバージョン管理を適用する方法を標準化する

成果物にバージョン管理を適用する方法と、内部および外部でバージョン管理を公開する方法を標準化します。 たとえば、クライアント側のシステムでは、ユーザー インターフェイスで実行中のバージョンを公開する必要があります。 この手法は、お客様が使用するバージョンを簡単に伝えることができるため、ワークロード チームが問題をトラブルシューティングするときに役立ちます。 REST インターフェイスでは、特定のコンポーネントまたはデータベースのバージョンを公開できます。 スキーマのメタデータ内の特定のテーブルを使用して、スキーマのバージョンを公開できます。

業界で実証済みのアプリケーション設計パターンを使用して、アプリケーションが信頼性が高く、パフォーマンスが高く、セキュリティで保護されていることを確認します。 これらのパターンを使用して、アプリケーション用の独自のソリューションを開発する場合と比較して、時間と労力を節約します。 ワークロードに役立つパターンを選択します。 設計パターンを定期的に確認して、ワークロードの進化に合わせて適切なパターンを使用していることを確認します。

テストにシフトレフトアプローチを実装する

開発プロセス全体を通して早く、頻繁に単体テストを実行することで、テストへのシフトレフト アプローチを実装します。 各開発環境で頻繁にテストすると、開発者はアプリケーションに対する信頼を得ることができます。 シフトレフト アプローチを使用してテスト戦略を作成するには、次の原則を考慮してください。

  • 可能な限り低いレベルでテストを記述します。 外部依存関係が最も少ないテストを優先し、ビルドの一部としてテストを実行します。

  • テストを 1 回記述し、運用環境を含むすべての場所でテストを実行します。 暗号化されたシークレットや構成など、1 つの環境に固有の要因を考慮せずに、すべての開発環境で実行できるテストを記述します。

  • テスト用にワークロードを設計します。 アプリケーションを開発するときは、テスト可能性を要件にします。

  • テスト コードをアプリケーション コードとして扱います。 同じ品質と開発標準をアプリケーション コードとテスト コードに適用します。 テスト コードをアプリケーション コードと共に格納します。 アプリケーション コードを使用してテスト コードを開発および保守する。 テストの品質を確保するには、信頼できないテストを破棄します。

  • ワークロードの所有権に基づくテスト所有権を検討してください。 ワークロード チームはテストを所有しており、他のチームに依存してコードをテストしないでください。

  • テストを可能な限り自動化します。 自動化されたコードにより、ワークロード チームの負担が軽減され、一貫した品質が適用されます。

DevOps テスト戦略の実装に関する詳細なガイダンスについては、「 単体テストを残したシフト テスト」を参照してください。

標準の運用手順の一部として DevSecOps プラクティスが必要です。 ワークロード チームは、ソフトウェア開発と品質保証に関連するセキュリティ プラクティスを理解する必要があります。 例外なくこれらのプラクティスに従う必要があります。 詳細については、「 セキュリティ開発ライフサイクル ガイド」を参照してください。

リソースの名前付けとタグ付けの標準を実装する

タグ付けと名前付け規則の実装は、Azure リソースを管理および整理するためのベスト プラクティスです。 タグ付けと名前付け規則は、環境、アプリケーション、所有者、コスト センターなどの一般的な属性に基づいてリソースを識別、分類、グループ化するのに役立ちます。 また、サブスクリプションとリソース グループ全体のリソースのセキュリティ、自動化、レポート、ガバナンスも可能になります。

標準化されたタグ付けと名前付け規則を使用する利点の一部は次のとおりです。

  • リソースの識別と管理の一貫性と明確さが提供され、Azure portal、PowerShell、CLI、API 全体での検出と検索が容易になります。
  • 課金、監視、セキュリティ、コンプライアンスの目的でリソースのフィルター処理とグループ化が可能になります。
  • プロビジョニング、使用停止、バックアップ、回復などのリソース ライフサイクル管理をサポートします。
  • これらは、セキュリティ上の目的で不可欠です。 セキュリティ インシデントが発生した場合は、影響を受けるシステム、それらのシステムがサポートする機能、および潜在的なビジネスへの影響を迅速に特定することが重要です。

クラウド リソースに名前付け規則を使用する方法の詳細については、「 名前付け規則を定義する」を参照してください。 クラウド リソースにメタデータ タグを適用する方法の詳細については、「 タグ付け戦略を定義する」を参照してください。

Azure ファシリテーション

  • Azure DevOps は、コラボレーション、効率的、一貫性のある開発プラクティスを構築するために使用できるサービスのコレクションです。 Azure DevOps には、次のソリューションがバンドルされています。

    • Azure Pipelines には、アプリケーションの CI/CD をサポートするためのビルド サービスとリリース サービスが用意されています。

    • Azure Boardsは、スクラムやかんばんなどのアジャイル プラクティスをサポートする Web ベースの作業管理ツールです。

    • Azure Reposは、Git 分散バージョン管理システムとTeam Foundation バージョン管理 システムをサポートするバージョン管理ツールです。

    • Azure Test Plansは、計画的な手動テスト、ユーザー受け入れテスト、探索的テスト、利害関係者からのフィードバックの収集に必要な機能を提供するブラウザーベースのテスト管理ソリューションです。

    • Azure Artifacts は、開発者がコードを効率的に共有し、パッケージを管理できるようにするために使用されます。

  • GitHub Actions for Azure は、CI/CD プロセスを自動化するために使用できるツールです。 デプロイを簡略化するために、Azure と直接統合されます。 リポジトリに対するすべての pull request をビルドしてテストするワークフローを作成したり、マージされた pull request を運用環境にデプロイしたりできます。

  • GitHub Projects は、かんばんボード、レポート、ダッシュボード、その他の機能を作成するために使用できる作業管理ツールです。

  • ローコード ツールとコードなしのツールには、次のものが含まれます。

  • Azure Resource Manager テンプレートと Bicep は、IaC のデプロイに使用できる Azure ネイティブ ツールです。 Terraform は、インフラストラクチャのデプロイと管理に使用できる Azure でサポートされているもう 1 つの IaC ツールです。

  • Visual Studio は、Azure と統合され、多くの言語をサポートする堅牢な開発ツールです。

  • GitHub Copilotは、ペア プログラマとして機能し、コーディング時にオートコンプリート スタイルの提案を提供する AI サービスです。 Copilot は、Visual Studio および他のいくつかの開発ツールの拡張機能として使用できます。

  • Azure Load Testing は、アプリケーションのホスト場所に関係なく、アプリケーションのトラフィックをシミュレートすることで、高スケールの負荷を生成するために使用できるフル マネージドのロード テスト サービスです。

オペレーショナル エクセレンスチェックリスト

推奨事項の完全なセットを参照してください。

オペレーショナル エクセレンスチェックリスト