次の方法で共有

開発ライフサイクル

  • [アーティクル]

開発ライフサイクル戦略では、ランディング ゾーンの自動作成中にリポジトリ、ブランチ、自動ビルド、デプロイ、ロールバックの各戦略に関する重要な設計上の考慮事項と推奨事項を提供します。

リポジトリ戦略

設計上の考慮事項

  • Git などのバージョン管理システムを導入して、チームに柔軟なコード共有と管理を提供することを検討します。

    • Git は、業界標準のバージョン管理システムです。 分散型バージョン管理システムであり、コードのローカル コピーが完全なバージョンのリポジトリになります。

  • mono-repo と multirepo を比較するリポジトリ構造を理解します。

    • mono-repo 構造では、すべてのソース コードが 1 つのリポジトリに存在します。
    • multirepo 構造では、すべてのプロジェクトが個別のリポジトリに編成されます。

  • お使いのリポジトリの内容に適した可視性の設定を選択してください。

    • パブリック リポジトリには匿名でアクセスできます。
    • プライベート リポジトリーでは、ユーザーはリポジトリへのアクセス権が付与され、サインインしてサービスにアクセスする必要があります。
    • Azure DevOps Projects と GitHub リポジトリに対してパブリックとプライベートの可視性を設定できます。

  • ソース コードに投稿し、他の機能を管理できるユーザーの制御に役立つ、リポジトリのアクセス許可の設定を検討します。

    • リポジトリのアクセス許可は、Azure DevOps と GitHub に対して設定できます。

  • Azure へのコードとしてのインフラストラクチャ (IaC) リソースのデプロイを使用することを検討します。 IaC を使用すると、宣言型モデルでインフラストラクチャを管理でき、構成作業の軽減、デプロイ間の一貫性の確保、環境の手動構成の回避に役立ちます。

  • Azure では、以下を使用してランディング ゾーンの IaC がサポートされます。

設計の推奨事項

  • バージョン管理システムとして Git を使用します。

  • Azure ランディング ゾーンの作成時にプライベート リポジトリを使用します

  • 自動化の例、パブリック ドキュメント、オープンソース コラボレーション資料などの非機密情報を共有する場合は、パブリック リポジトリを使用します。

  • クラウド リソースをデプロイ、管理、サポートするための IaC アプローチを導入します。

ブランチ戦略

設計上の考慮事項

  • チームがより良い共同作業を行い、効率よくバージョン管理を行うことができるブランチ戦略の使用を検討します。

  • ブランチに特定の名前付け規則を使用することを検討します。

  • ユーザー機能の制御にブランチのアクセス許可を使用してすることを検討します。

  • チームが開発の重要なブランチを保護するのに役立つブランチ ポリシーの使用を検討します。 役立つポリシーによって、コード品質と変更管理の基準が適用されます。 ブランチ ポリシーの例を以下に示します。

  • プル要求戦略を採用すると、ブランチにマージされるコード変更の制御に役立ちます。

    • マージ戦略を定義します。
    • プル要求はシンプルであり、レビュー担当者がコミットと変更をより効率よく検証できるようにファイル数を最小限に抑える必要があります。
    • レビュー担当者がコードのレビュー時に予期される事柄を把握できるように、プル要求には明確なタイトルと説明が必要です。
    • プル要求テンプレートを使用できます。
    • プル要求が完了した後に元のブランチを削除できます。これにより、制御が強化され、ブランチ管理が向上します。

設計の推奨事項

  • 開発者が単一のブランチにコミットするトランク ベースの開発モデルを導入します。 このモデルでは、継続的インテグレーションが円滑化されます。 すべての機能の作業がトランク内で実行され、マージの競合が生じてもコミット時に解決されます。

  • 行われた作業を識別するために、チームがブランチに対して一貫性のある名前付け規則を定義して使用するようにします。

  • Git リポジトリのブランチでコードの読み取りと更新を実行できるユーザーを制御するためにアクセス許可を設定します。 個々のユーザーとグループに対してアクセス許可を設定できます。

  • ブランチ ポリシーを設定するには:

    • メイン ブランチへのブランチ マージにプル要求の使用を要求します。
    • プル要求に対して最小数のレビュー担当者を要求します。
    • すべての承認投票を削除する承認投票をすべてリセットしますが、ソース ブランチが変更されるたびに拒否または待機する投票を保持します。
    • コードのレビュー担当者を自動的に含めます。
    • [コメント解決の有無を確認する]。

  • スカッシュをマージ戦略として設定します。これにより、プル要求の実行時にトピック ブランチの Git 履歴を要約できます。 トピック ブランチの各コミットを既定ブランチの履歴に追加する代わりに、スカッシュ マージによって、既定ブランチ上の単一の新しいコミットにすべてのファイル変更が追加されます。

自動ビルド

設計上の考慮事項

  • 継続的インテグレーション (CI) の実装を検討します。 CI では、一元化されたコードベースに対し、開発者のすべてのコードが定期的にマージされ、標準的なビルド プロセスとテスト プロセスが自動的に実行されます。

  • CI トリガーの使用を検討するには:

    • Azure Repos Git。 ブランチ、パス、タグを CI ビルドを実行するトリガーとして構成できます。
    • GitHub。 CI ビルドを実行するためにブランチ、パス、タグのトリガーを構成できます。

  • 構文を検証するために、ビルド プロセスに IaC 単体テストを含めることを検討します。

  • アプリケーション ビルド プロセスに単体テストを含めることを検討します。 Azure DevOps パイプラインで使用できるタスクを確認します。

  • Azure DevOps サービス接続または GitHub シークレットを使用して、Azure との接続を管理します。 各接続には、Azure リソースへの正しい特権アクセスが必要です。

  • パスワード、API キー、証明書などの機密情報の格納と管理に、Azure Key Vault シークレットを使用することを検討します。

  • Azure DevOps エージェントは、セルフホステッドまたは Microsoft ホステッド エージェントにすることができます。

    • Microsoft によってホストされているエージェントを使用する場合、メンテナンスとアップグレードが自動的に行われます。 ビルド ジョブが実行されるたびに、新しい仮想マシンが作成されます。
    • ビルド ジョブを実行するには、セルフホステッド エージェントを自分で設定して管理します。

設計の推奨事項

  • チームのメンバーがバージョン コントロールに対する変更をコミットするたび、コードのビルドとテストを自動化するのに CI を使用します。

  • IaC とアプリケーション コードの単体テストを、ビルド プロセスの一部として含めます。

  • 可能であれば、セルフホステッド プールではなく Microsoft によってホストされているプールを使用します。これは、パイプラインの実行ごとに分離とクリーンな VM が提供されるためです。

  • サービス接続または GitHub シークレットを使用して Azure DevOps または GitHub を Azure に接続する場合は、必ずスコープを定義して、必要なリソースのみにアクセスできるようにしてください。

  • 資格情報 (仮想マシンのユーザー パスワード)、証明書、キーなどの機密情報のハードコーディングを回避するには、Key Vault シークレットを使用します。 次に、ビルド ジョブとリリース ジョブで変数としてシークレットを使用します。

展開戦略

設計上の考慮事項

  • 継続的デリバリー (CD) の使用を検討します。 CD には、ビルド、テスト、構成、およびビルドから環境へのデプロイが含まれます。

  • 環境の使用を検討します。 環境を使用すると、配信ジョブからのリソースのコレクションをターゲットにすることができます。 一般的な環境名の例は次のとおりです。

    • Dev
    • テスト
    • QA
    • ステージング
    • Production

  • デプロイ前の変更を検証して確認するために、戦略の一環として IaC を使用することを検討します。

設計の推奨事項

  • CD を使用して、運用環境と同様の環境に対してコードのビルド、テスト、デプロイを自動的に行うことでコードが常時デプロイ可能であることを確保します。 可能な限り早くコードの欠陥を検出し、適切にテストされた更新プログラムをすばやくリリースできるようにする完全な CI/CD 統合を作成するために、継続的デリバリーを追加します。

  • デプロイ戦略の一部として環境を使用します。 環境には、次のような利点があります。

    • デプロイ履歴
    • コミットと作業項目の追跡可能性
    • 診断リソースの正常性
    • セキュリティ

  • IaC の配置前チェックを含め、変更をプレビューしたり、リソースが作成、変更、削除されたかどうかの詳細を確認したりできます。

ロールバック戦略

設計上の考慮事項

  • ロールバック計画の作成を検討します。 デプロイをロールバックするには、デプロイを既知の良好な状態に戻す必要があり、失敗したデプロイから回復するための重要な機能が提供されます。

  • コミットの変更を元に戻すか、変更を破棄するか、またはブランチを以前の状態にリセットする必要がある場合は、Git で変更を元に戻すの使用を検討します。

設計の推奨事項

  • コミットされたファイルの変更を元に戻すか、コミットされていない変更を破棄するか、またはブランチを以前の状態にリセットする必要がある場合は、Git で変更を元に戻す機能の使用を導入します。