説明/参照:
Explanation:
Visual Designer では、次の方法で継続的インテグレーション (CI) を有効にします。
1. 「トリガー」タブを選択します。
2. 継続的インテグレーションを有効にします。
ビルド パイプラインの継続的インテグレーション トリガーは、コード変更がコミットされるたびにシステムが新しいビルドを自動的にキューに入れる必要があることを示します。
参考文献:
https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-designer テストレット 1 ケース スタディ これはケース スタディです。ケース スタディは個別に時間制限されません。各ケースを完了するのに必要なだけの試験時間を使用できます。ただし、この試験には追加のケース スタディとセクションがある場合があります。与えられた時間内にこの試験に含まれるすべての質問を完了できるように、時間を管理する必要があります。
ケース スタディに含まれる質問に答えるには、ケース スタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示物やその他のリソースが含まれている場合があります。各質問は、このケース スタディの他の質問とは独立しています。
このケース スタディの最後に、確認画面が表示されます。この画面では、試験の次のセクションに進む前に回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを始めるには
このケース スタディの最初の質問を表示するには、[次へ] ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケース スタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケース スタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に回答する準備ができたら、[質問] ボタンをクリックして質問に戻ります。
アプリケーションアーキテクチャ
同社の主なアプリケーションは、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

サーバーが作成され、定期的にチェックされるときに、各テスト サーバーのオペレーティング システムが同じ方法で構成されていることを確認するには、状態構成を使用する必要があります。
現在の技術的な問題
テスト サーバーは最初にデプロイされたときには正しく構成されていますが、時間の経過とともに構成のずれが生じます。Azure Automation State Configuration では構成を修正できません。
Azure Automation State Configuration ノードは、次のコマンドを使用して登録されます。