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

  • [アーティクル]

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

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

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

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

主要な設計戦略

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

既知の成熟した既製ツールを使用する

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

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

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

  • CI/CD パイプライン

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

  • コード開発

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

高価なツールやプレミアム バージョンのツールに投資する必要があるかどうかを判断します。 プレミアム バージョンのツールが提供する機能と、独自のソリューション開発に費やす時間と労力を比較し、検討してください。 1 回使用した場合のコストと繰り返し使用することで発生するコストについて検討します。 ほとんどの場合、チームに対してより高い価値を提供するのは、既製のツールです。

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

ブランチ戦略の標準化

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

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

有効性を数値化すれば、ソフトウェア開発チームと品質保証チームを強化できます。 有効性を数値化するには、開発者のベロシティを測定するメトリックを特定し、KPI を定義する必要があります。 これらのメトリックの例は次のとおりです。

  • 開発頻度: 各開発者が日々行っている開発の数。

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

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

  • 変更失敗率: 失敗となった変更の割合。

関係者やワークロード チームがベロシティを簡単に追跡できるように、ダッシュボードなどのレポート ツールを使用して KPI を視覚化します。

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

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

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

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

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

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

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

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

  • チームの決定理由。

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

  • 決定の一因となった機能要件および非機能要件。

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

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

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

たとえば、チームがライブラリで標準化されたとします。 時間の経過とともに、ワークロードで新機能に対応する別のライブラリに切り替える必要が生じます。 このような移行によって、技術的負債が発生する可能性があります。 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 プロジェクトは、かんばんボード、レポート、ダッシュボードなどの機能を作成するために使用できる作業管理ツールです。

  • ロー コード ツールとノー コード ツールには、次の内容が含まれます。

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

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

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

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

組織の配置

Azure のクラウド導入フレームワークには、Azure リソースのタグ付けと名前付けに関する一般的なガイドラインと推奨事項、およびさまざまなリソースの種類に対する具体的な規則と例が用意されています。

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

レコメンデーションの完全なセットを参照してください。

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