説明/参照:
継続的デリバリーを実装する
テストレット1
ケーススタディ
これはケース スタディです。ケース スタディは個別に時間制限がありません。各ケースを完了するのに必要なだけの試験時間を使用できます。ただし、この試験には追加のケース スタディとセクションが含まれる場合があります。与えられた時間内にこの試験に含まれるすべての質問を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示物やその他のリソースが含まれている場合があります。各質問は、このケース スタディの他の質問とは独立しています。
このケース スタディの最後に、確認画面が表示されます。この画面では、試験の次のセクションに進む前に回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを始めるには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケース スタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケース スタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に回答する準備ができたら、[質問] ボタンをクリックして質問に戻ります。
概要
Litware, Inc. は独立系ソフトウェア ベンダー (ISV) です。Litware には本社と 5 つの支社があります。
既存の環境
アプリケーションアーキテクチャ
同社の主なアプリケーションは、VB.NET で記述されたロジックを使用する ASP.NET Web フォームに基づく単一のモノリシック退職基金管理システムです。アプリケーションの新しいセクションの一部は C# で記述されています。
アプリケーションのバリエーションは個々の顧客向けに作成されます。現在、アプリケーションのコード ベースには 80 を超えるライブ コード ブランチがあります。
アプリケーションは、Microsoft Visual Studio を使用して開発されました。ソース コードは、本社の Team Foundation Server (TFS) に保存されています。支社は、TFS プロキシ サーバーを使用してソース コードにアクセスします。
アーキテクチャ上の問題
Litware は、顧客向けの新しいコードの作成に重点を置いています。既存のコードをリファクタリングまたは削除するためのリソースは提供されていません。依存関係が個々の開発者にとって明らかではないため、コード ベースの変更には長い時間がかかります。
コードのマージ操作には数か月かかることが多く、多くの開発者が関与します。コードのマージにより、見つけて解決するのが難しいバグが頻繁に発生します。
顧客からは、退職基金管理システムの所有コストが継続的に増加しているとの報告があります。関連のないコードをマージする必要があるため、小さなコード変更でもコストがかかります。
顧客からは、バグ報告が複雑すぎるという報告があります。
要件
計画されている変更
Litware は、投資計画用の新しいアプリケーション スイートを開発する予定です。投資計画アプリケーションでは、既存の退職基金管理システムとのわずかな統合のみが必要になります。
投資計画アプリケーション スイートには、1 つの多層 Web アプリケーションと 2 つの iOS モバイル アプリケーションが含まれます。1 つのモバイル アプリケーションは従業員が使用し、もう 1 つは顧客が使用します。
Litware は、よりアジャイルな開発手法に移行する予定です。共有コードは一連のパッケージに抽出されます。
Litware は社内のクラウド変革プロセスを開始しており、適切な場合にはクラウドベースのサービスを使用する予定です。
Litware は、常に顧客からのバグ報告を待つのではなく、積極的に障害を検出したいと考えています。
技術要件
会社の投資計画アプリケーション スイートは、次の要件を満たす必要があります。
* ファイアウォールを介した新しい着信接続を最小限に抑える必要があります。
* Developers というグループのメンバーはパッケージをインストールできる必要があります。
* すべての権限の割り当てには、最小権限の原則を適用する必要があります。
* 新しい機能を個別に開発することをサポートする分岐戦略を使用する必要があります。
* チーム リーダーというグループのメンバーは、新しいパッケージを作成し、パッケージ フィードの権限を編集できる必要があります。
* モバイル アプリケーションのクラッシュと使用中のデバイスの種類のレポートを一元管理するには、Visual Studio App Center を使用する必要があります。
* デフォルトでは、すべてのリリースは 30 日間利用可能な状態にしておく必要があります。ただし、製品リリースは 60 日間保持する必要があります。
* コードの品質とリリースの品質は重要です。リリース中に、リリースに対してアクティブなバグが記録されている場合は、ステージ間でデプロイメントを進めてはなりません。
* モバイル アプリケーションは、既存の退職基金管理システムの株価設定サービスを呼び出すことができる必要があります。システムがアップグレードされるまで、サービスは HTTPS 経由の基本認証のみをサポートします。
* テスト サーバーに必要なオペレーティング システムの構成は毎週変更されます。Azure Automation State Configuration を使用して、サーバーの作成時および定期的なチェック時に、各テスト サーバーのオペレーティング システムが同じ方法で構成されていることを確認する必要があります。
現在の技術的な問題
テスト サーバーは最初に展開されたときには正しく構成されていますが、時間の経過とともに構成がずれることがあります。
Azure Automation State Configuration は構成を修正できません。
Azure Automation State Configuration ノードは、次のコマンドを使用して登録されます。