AZ-400受験するので、受かるまでOpenしてます。

Microsoft learnを読みながらキャッチアップ
https://learn.microsoft.com/ja-jp/certifications/exams/az-400/

範囲を確認

プロセスと通信を構成する (10-15%)

ソース管理の設計と実装 (15-20%)

ビルドおよびリリース パイプラインの設計と実装 (40 ～ 45%)

セキュリティとコンプライアンスの計画を作成する (10 ～ 15%)

インストルメンテーション戦略を実装する (10-15%)

サイクル タイムは、チームが作業項目に積極的に取り組み始めてから、作業項目を完了するまでにかかる時間を測定します。

リード タイムウィジェットとサイクルタイム ウィジェットはどちらもチームにとって便利です。 どちらも、開発パイプラインを通じて作業が流れるまでの時間を示します。 リード タイムは、作業項目の作成から完了までの合計経過時間を測定します。 サイクル時間は、チームが作業項目に積極的に取り組み始めた後に作業項目を完了するのにかかる時間を測定します。

https://learn.microsoft.com/ja-jp/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azure-devops&viewFallbackFrom=vsts

Azure DevOps を利用してビルド パイプラインを管理し、パイプラインをデプロイしています。開発チームは非常に大規模で、定期的に追加されています。ユーザーとライセンスの管理は可能な限り自動化する必要があることをお知らせしました。自動化できないタスクは次のうちどれですか?

ライセンスの調達は自動化できない模様。

CI/CD での検証は、開発者がコードをコミットする前に始まります。IDE の静的コード分析ツールは、セキュリティの脆弱性が CI/CD プロセスに持ち込まれないようにするための防御の第一線を提供します。

静的コード分析

https://learn.microsoft.com/ja-jp/azure/devops/pipelines/security/overview?view=azure-devops&viewFallbackFrom=vsts

移行プロジェクトのフェーズ 3 では、Team Foundation Server を Azure DevOps サービスの 1 つにアップグレードする作業を行います。

TFSデータベースインポートサービスなるものがある

AzureDevOpsには以下の４つのWITがある。

• Basic
• アジャイル
• スクラム
• CMMI

CMMI：チームが、プロセス改善のためのフレームワークと監査可能な意思決定の記録を必要とする、より正式なプロジェクト手法に従っている場合は、CMMI を選択してください。このプロセスにより、要件、変更リクエスト、リスク、レビューを追跡できます。

チームが課題、タスク、エピックを使用して作業を追跡する最も単純なモデルを必要とする場合は、「基本」を選択します。

アジャイル: このプロセスは、カンバン ボードでユーザー ストーリーと (オプションで) バグを追跡する場合、またはタスクボードでバグとタスクを追跡する場合に最適です。

スクラム: このプロセスは、カンバン ボードで製品バックログ項目 (PBI) とバグを追跡する場合、または PBI とバグをタスクボードでタスクに分割する場合に最適です。

https://docs.microsoft.com/ja-jp/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops

GitHub Enterprise は、GitHub.com のオンプレミス バージョンです。GitHub Enterprise には、GitHub.com と同じ優れた機能セットが含まれていますが、組織のローカル ネットワーク上で実行できるようにパッケージ化されています。すべてのリポジトリ データは管理するマシンに保存され、アクセスは組織の認証システム (LDAP、SAML、または CAS) と統合されます。
参考
https://www.azuredevopslabs.com/labs/azuredevops/yaml/

Atlassian の Jira Software は、チームがソフトウェア リリースを計画、追跡、管理するのに役立つ人気のあるアプリケーションですが、Octopus Deploy は、チームが開発プロセスと運用プロセスを迅速かつ再現可能で信頼性の高い方法で自動化するのに役立ちます。これらを組み合わせることで、チームはアイデアから実稼働に至るソフトウェア パイプラインのエンドツーエンドの可視性を向上させることができます。
参考
https://octopus.com/blog/octopus-jira-integration

レッド・ブラック・デプロイメント：
ローリング・デプロイメント：
ビックバン・デプロイメント：
カナリア・デプロイメント：

Deploy gate

https://learn.microsoft.com/ja-jp/azure/devops/pipelines/release/approvals/gates?view=azure-devops

WhiteSource は、継続的なオープンソース ソフトウェアのセキュリティとコンプライアンス管理のリーダーです。WhiteSource は、プログラミング言語、ビルド ツール、開発環境に関係なく、ビルド プロセスに統合されます。バックグラウンドで自動的、継続的、サイレントに動作し、WhiteSource の常に更新されるオープン ソース リポジトリの決定的なデータベースと照合して、オープン ソース コンポーネントのセキュリティ、ライセンス、品質をチェックします。
Azure DevOps と WhiteSource Bolt の統合により、次のことが可能になります。

1. 脆弱なオープンソース コンポーネントを検出して修復します。
2. プロジェクトまたはビルドごとに包括的なオープンソース インベントリ レポートを生成します。
3. 依存関係のライセンスを含め、オープンソース ライセンスのコンプライアンスを強制します。
4. 更新すべき推奨事項とともに、古いオープンソース ライブラリを特定します。

Black Duck は、組織がアプリケーションとコンテナのポートフォリオ全体でオープンソースのセキュリティ、ライセンス コンプライアンス、コード品質のリスクを特定し、軽減するのに役立ちます。
Black Duck Hub とその Team Foundation Server (TFS) 用プラグインを使用すると、ビルド プロセス中にオープンソースのセキュリティの脆弱性を自動的に検出して修正できるため、リスクをプロアクティブに管理できます。この統合により、Black Duck Hub ポリシー違反が発生した場合にアラートを受信し、ビルドを失敗させることができます。
参照
https://marketplace.visualstudio.com/items?itemName=black-duck-software.hub-tfs

コンピューティング サービスとアプリ サービスを監視する: [コンピューティングとアプリ] には [App Services] タブが含まれます。このタブには、App サービス環境のリストとそれぞれの現在のセキュリティ状態が表示されます。
推奨事項
このセクションには、セキュリティ センターが監視する各 VM とコンピューター、Web ロールとワーカー ロール、Azure App Service Web Apps、および Azure App Service 環境に関する一連の推奨事項が記載されています。最初の列には推奨事項がリストされています。2 番目の列には、その推奨事項の影響を受けるリソースの合計数が表示されます。3 番目の列は問題の重大度を示します。

Application Insights は、パフォーマンスの問題や例外を通知し、根本原因の発見と診断に役立ちます。
Application Insights は、Java と ASP.NET の両方の Web アプリケーションとサービス、WCF サービスを監視できます。これらは、オンプレミス、仮想マシン、または Microsoft Azure Web サイトとしてホストできます。
クライアント側では、Application Insights は Web ページや、iOS、Android、Windows ストア アプリなどのさまざまなデバイスからテレメトリを取得できます。

「Exploratory Testing」拡張機能は「Test & Feedback」となり、一般利用可能になりました。
誰でも、Windows、Mac、Linux などのプラットフォーム上のブラウザから直接、Web アプリをテストしてフィードバックを送信できるようになりました。現在、 Google Chrome および
Mozilla Firefox (バージョン 50.0 以降が必要) で利用できます。Microsoft Edge のサポートは進行中であり、Edge が Chromium 互換の Web プラットフォームに移行すると有効になる予定です。

Application Insights の可用性テストには 3 種類あります。
URL ping テスト: Azure portal で作成できる簡単なテスト。
マルチステップ Web テスト
カスタム トラック可用性テスト
注 Web アプリ/Web サイトを展開した後、可用性と応答性を監視するための繰り返しテストを設定できます。Azure Application Insights は、世界中の地点から定期的に Web 要求をアプリケーションに送信します。アプリケーションが応答しない場合、または応答が遅すぎる場合に警告を発することができます。
パブリック インターネットからアクセス可能な HTTP または HTTPS エンドポイントの可用性テストを設定できます。テストしている Web サイトに変更を加える必要はありません。実際、自分が所有するサイトである必要さえありません。サービスが依存する REST API の可用性をテストできます。
参考
https://docs.microsoft.com/en-us/azure/azure-monitor/app/monitor-web-app-availability#create-a-url-ping-test

Application Insights は、パフォーマンスの問題や例外を通知し、根本原因の発見と診断に役立ちます。
Application Insights は、Java と ASP.NET の両方の Web アプリケーションとサービス、WCF サービスを監視できます。これらは、オンプレミス、仮想マシン、または Microsoft Azure Web サイトとしてホストできます。
クライアント側では、Application Insights は Web ページや、iOS、Android、Windows ストア アプリなどのさまざまなデバイスからテレメトリを取得できます。

IT サービス管理コネクタ (ITSMC) を使用すると、Azure とサポートされている IT サービス管理 (ITSM) 製品/サービスを接続できます。
ITSMC は、次の ITSM ツールとの接続をサポートしています。
ServiceNow
System Center Service Manager
Provance
Cherwell
ITSMC を使用すると、Azure アラート (メトリック アラート、アクティビティ ログ アラート、および Log Analytics アラート) に基づいて ITSM ツールで作業項目を作成できます。オプションで、インシデントと変更要求データを ITSM ツールから Azure Log Analytics ワークスペースに同期できます。

Azure Monitor Logs は Azure Data Explorer に基づいており、ログ クエリは同じ Kusto クエリ言語 (KQL) を使用して作成されます。これは、読みやすく、作成しやすいように設計された機能豊富な言語であり、最小限のガイダンスで使い始めることができるはずです。

問題分析のためにクラッシュ レポートを収集する。

Microsoft Visual Studio Centerの統合

スマート検出は、Web アプリケーションの潜在的なパフォーマンス上の問題や障害の異常を自動的に警告します。アプリが Application Insights に送信するテレメトリのプロアクティブな分析を実行します。障害率が突然上昇したり、クライアントまたはサーバーのパフォーマンスに異常なパターンが発生した場合は、アラートが表示されます。

Azure Pipelines と Microsoft Teams を統合することも可能

Microsoft Teamsからコネクタを構成すればOK

Azure Service Health を使用した計画メンテナンス アラートの作成

1. Azure portal にログインし、[Service Health] を選択します。
2. 右側のウィンドウの上部から [ヘルス アラート] を選択し、続いて [+ サービス ヘルス アラートの作成] を選択します。
3. [アラートの編集] ブレードで、アラートに名前と説明を入力し、サブスクリプションが正しいことを確認して、リソース グループを選択します。
4. 次のステップでは、「基準」セクションで、監視するサービス、リージョン、およびイベント アラートの種類を選択します。この記事の目的上、すべてのサービスとリージョンがチェックされていますが、計画されているメンテナンス イベントのみがチェックされています。
5. アクション グループを選択または作成します。(アクション グループは、イベントが記録される場合に実行されるアクションのグループです。)
6. 実行するアクションを設定します。ここでは電子メール アラートのみを設定しているため、最初にアクションに名前を付けてから、ドロップダウン リストから [電子メール/SMS/プッシュ/音声] を選択します。
   注: Azure Service Health を使用すると、クラウド サービスに影響を与える可能性がある Azure サービスの問題を表示できます。サービスの正常性では、次の 3 種類の正常性イベントが監視されます。
   サービスの問題 現在問題が発生している Azure サービス
   計画されたメンテナンス サービスの可用性に影響を与える可能性がある将来の既知のメンテナンス
   正常性に関する勧告 サービスの変更 (非推奨の機能やクォータ使用量の超過など)。

スマート検出
https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/proactive-diagnostics

Azure Application Insights 可用性テストを構成します。可用性が低下した場合は、会社のカスタマー サービス部門に電子メールで通知する必要があります。電子メールとフォローアップ アクションを処理する Azure ロジック アプリを作成します。ロジック アプリを呼び出すにはどの種類のトリガーを使用する必要がありますか?

リクエストトリガー

Azure SQL や Web サイト (Web アプリ) などの Azure Platform as a Service (PaaS) リソースは、パフォーマンス メトリック データをネイティブに Log Analytics に出力できます。
プレミアム プランでは最大 12 か月のデータが保持され、優れたベースライン機能が提供されます。
Azure portal では、Log Analytics に保存されているデータを分析するためと、アドホック分析用のクエリを作成するために 2 つのオプションを使用できます。
Intelligent Insights は、過去 1 時間のデータベース ワークロードと過去 7 日間のベースライン ワークロードを比較することにより、データベースのパフォーマンスを分析します。
ただし、アプリケーションのメトリクスも処理する必要があります。

プロジェクトに Application Insights を設定した後、アプリが特定の最小量のデータを生成する場合、障害異常のスマート検出は、アプリがオンになってアラートを送信できるようになるまで、アプリの通常の動作を学習するのに 24 時間かかります。

https://docs.microsoft.com/en-us/azure/azure-monitor/app/proactive-failure-diagnostics

スマート検出により、Web アプリケーションの潜在的なパフォーマンスの問題や失敗の異常に関する警告を自動的に受け取ることができます。 スマート検出では、アプリから Application Insights に送信されるテレメトリがプロアクティブに分析されます。

アプリケーションの健全性を監視することは、展開を管理およびアップグレードするための重要なシグナルです。Azure 仮想マシン スケール セットは、OS イメージの自動アップグレードを含むローリング アップグレードのサポートを提供します。これは、個々のインスタンスの正常性監視に依存してデプロイをアップグレードします。正常性拡張機能を使用して、スケール セット内の各インスタンスのアプリケーションの正常性を監視し、自動インスタンス修復を使用してインスタンスの修復を実行することもできます。

ゲートのシナリオと使用例には以下が含まれます。
品質検証。合格率やコード カバレッジなどのビルド アーティファクトに関するテストのメトリクスをクエリし、それらが必要なしきい値内にある場合にのみデプロイします。
Quality Gates を使用して、導入前または導入後に監視を統合します。
これにより、アプリケーションが開発から運用に移行する際に重要な健全性/パフォーマンス指標 (KPI) を確実に満たすことができ、インフラストラクチャ環境や規模の違いが KPI に悪影響を与えることはありません。
注: ゲートを使用すると、外部サービスから正常性シグナルを自動的に収集でき、すべてのサインが同時に成功した場合にリリースを促進するか、タイムアウトでデプロイメントを停止します。通常、ゲートはインシデント管理、問題管理、変更管理、監視、および外部承認システムと関連して使用されます。

Azure DevOps でプロジェクトを管理します。プロジェクトの構成が時間の経過とともに変更されないようにする必要があります。解決策: コード カバレッジ ステップをビルド パイプラインに追加します。これは目標を達成していますか?

プロジェクトに継続的保証を実装します。

Azure portal の App Configuration 用の機能マネージャーは、アプリケーションで使用する機能フラグを作成および管理するための UI を提供します。
App Configuration には次の利点があります。
数分でセットアップできるフルマネージド サービス
柔軟なキー表現とマッピング
ラベルによるタグ付け
設定のポイントインタイムの再生
機能フラグ管理用の専用 UI カスタム
設定の 2 セットの構成の比較定義されたディメンション
Azure マネージド ID によるセキュリティの強化 保存
中および転送中の機密情報の暗号化
一般的なフレームワークとのネイティブ統合
App Configuration は、アプリケーション シークレットを保存する Azure Key Vault を補完します。
参考
https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview

https://docs.microsoft.com/en-us/azure/container-instances/container-instances-readiness-probe

readiness probe

トラフィックを処理するコンテナー化されたアプリケーションの場合、コンテナーが受信要求を処理する準備ができているかどうか確認したほうがいいです。 Azure Container Instances は、特定の条件下でコンテナーにアクセスできないようにする構成を組み込む、readiness probe をサポートしています。 readiness probe は、Kubernetes readiness probe のように動作します。 たとえば、コンテナー アプリケーションが起動時に大規模なデータセットを読み込む必要があり、この間は要求を受信したくない場合があります。

Azure DevOps のプロジェクト内で発生するアクティビティについて、あなたとあなたのチームが最新の情報を入手できるようにします。次の項目に変更が発生したときに通知を受け取ることができます:
作業項目
コード レビュー プル
リクエスト
ソース コントロール ファイルの
ビルド
リファレンス
https://docs.microsoft.com/en-us/azure/devops/notifications/about-notifications?view=azure -devops

Azure Active Directory を使用するためにアプリケーションを登録します。アプリケーションを登録すると、開発者は Azure AD を使用してユーザーを認証し、電子メール、カレンダー、ドキュメントなどの有用なリソースへのアクセスを要求できるようになります。
参考
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/developer-guidance-for-integrating-applications

パーソナル アクセス トークン (PAT) を使用すると、ユーザー名とパスワードを直接使用せずに、Azure DevOps および Team Foundation Server (TFS) にアクセスできるようになります。
これらのトークンには、作成時からの有効期限があります。アクセスできるデータの範囲を制限できます。システムに SSH キーがまだ設定されていない場合、または資格情報によって付与されるアクセス許可を制限する必要がある場合は、PAT を使用して認証します。
不正解:
B: Azure DevOps は、2020 年 3 月 2 日以降、代替資格情報認証をサポートしなくなりました。まだ代替資格情報を使用している場合は、
より安全な認証方法 (たとえば、個人アクセス トークン)。
参照
https://docs.microsoft.com/en-us/azure/devops/repos/git/auth-overview

コンピューティング サービスとアプリ サービスを監視する: [コンピューティングとアプリ] には [アプリ サービス] タブが含まれており、どのアプリ サービス: App サービス環境のリストとそれぞれの現在のセキュリティ状態が表示されます。
推奨事項 このセクションには、セキュリティ センターが監視する各 VM とコンピューター、Web ロールとワーカー ロール、Azure App Service Web Apps、および Azure App Service 環境に関する一連の推奨事項が記載されています。最初の列には推奨事項がリストされています。2 番目の列には、その推奨事項の影響を受けるリソースの合計数が表示されます。3 番目の列は問題の重大度を示します。
スマート検出は、Web アプリケーションのセキュリティ上の問題ではなく、潜在的なパフォーマンス上の問題を自動的に警告します。
参考
https://docs.microsoft.com/en-us/azure/azure-monitor/app/proactive-diagnostics

Microsoft Visual Studio App Center 配布グループ- 配布グループは、リリースへのアクセスを制御するために使用されます。配布グループは、共同で管理でき、リリースに共通のアクセス権を持つことができるユーザーのセットを表します。配布グループの例としては、QA チームや外部ベータ テスターなどのユーザーのチーム、またはステージングなどのリリースの段階やリングを表すことができます。

共有- 共有配布グループは、単一組織内の複数のアプリ間で共有されるプライベートまたはパブリック配布グループです。共有配布グループを使用すると、複数のアプリ間で配布グループをレプリケートする必要がなくなります。

注: Visual Studio Team Services の App Center でデプロイ タスクを使用すると、Azure DevOps (旧名 VSTS) から AppCenter にアプリをデプロイできます。App Center にデプロイすると、ビルドをユーザーに配布できるようになります。

参考
https://docs.microsoft.com/en-us/appcenter/distribution/groups

これが機能する前に、ビルドには Azure Key Vault にアクセスするためのアクセス許可が必要です。これは Azure ポータルに追加できます。Key Vault でアクセス ポリシーを開き、新しいアクセス ポリシーを追加します。DevOps ビルドで使用される原則を選択します。
参考
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/azure-key-vault

条件付きアクセスは、Azure Active Directory の機能です。条件付きアクセスを使用すると、条件に基づいてクラウド アプリにアクセスするための自動アクセス制御の決定を実装できます。
条件付きアクセス ポリシーは、第一要素認証が完了した後に適用されます。
参考
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

変数グループを使用して、制御したい値を保存し、複数のパイプライン間で利用できるようにします。
参考
https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups

WhiteSource Bolt

オープン ソースの脆弱性を見つけ出して修正し、使用しているビルドのすべてのオープン ソース コンポーネントに関する包括的なインベントリとライセンスのレポートを作成します。 Visual Studio Enterprise サブスクリプションでは、6 か月の無制限のスキャンを受けられます

Git クライアントから初めて Git リポジトリに接続すると、資格情報マネージャーによって資格情報の入力が求められます。Microsoft アカウントまたは Azure
AD 資格情報を入力します。
注: Git Credential Manager は、Azure Repos Git リポジトリでの認証を簡素化します。資格情報マネージャーを使用すると、Azure DevOps Services Web ポータルに使用するものと同じ資格情報を使用できます。資格情報マネージャーは、Microsoft アカウントまたは Azure Active Directory (Azure
AD) を介した多要素認証をサポートします。資格情報マネージャーは、Azure Repos での多要素認証をサポートするだけでなく、GitHub リポジトリでの 2 要素認証もサポートします。
参考
https://docs.microsoft.com/en-us/azure/devops/repos/git/set-up-credential-managers

https://octopus.com/docs/packaging-applications

Octopus Deploy

あなたは、Azure DevOps のプロジェクトのセキュリティ検証戦略を設計しています。既知のセキュリティ問題があり、更新によって解決できるパッケージの依存関係を特定する必要があるときに使用

代わりに、継続的インテグレーションの実装を使用してください。
WhiteSource は、継続的なオープンソース ソフトウェアのセキュリティとコンプライアンス管理のリーダーであることに注意してください。WhiteSource は、プログラミング言語、ビルド ツール、開発環境に関係なく、ビルド プロセスに統合されます。バックグラウンドで自動的、継続的、サイレントに動作し、WhiteSource の常に更新されるオープン ソース リポジトリの決定的なデータベースと照合して、オープン ソース コンポーネントのセキュリティ、ライセンス、品質をチェックします。

ソナーキューブ

Azure DevOps のプロジェクトのセキュリティ検証戦略を設計しています。既知のセキュリティ問題があり、更新によって解決できるパッケージの依存関係を特定する必要があります。何を使えばいいのでしょうか？

https://qiita.com/teradonburi/items/776e4735395af872320a

WhiteSource は、継続的なオープンソース ソフトウェアのセキュリティとコンプライアンス管理のリーダーです。WhiteSource は、プログラミング言語、ビルド ツール、開発環境に関係なく、ビルド プロセスに統合されます。バックグラウンドで自動的、継続的、サイレントに動作し、WhiteSource の常に更新されるオープン ソース リポジトリの決定的なデータベースと照合して、オープン ソース コンポーネントのセキュリティ、ライセンス、品質をチェックします。
Azure DevOps と WhiteSource Bolt の統合により、次のことが可能になります。

1. 脆弱なオープンソース コンポーネントを検出して修復します。
2. プロジェクトまたはビルドごとに包括的なオープンソース インベントリ レポートを生成します。
3. 依存関係のライセンスを含め、オープンソース ライセンスのコンプライアンスを強制します。
4. 更新すべき推奨事項とともに、古いオープンソース ライブラリを特定します。
   注：黒いアヒルも良い答えですが、ここでは選択肢にはなりません。

オープンソース ソフトウェアの保護と管理
Black Duck は、組織がアプリケーションとコンテナのポートフォリオ全体でオープンソースのセキュリティ、ライセンス コンプライアンス、コード品質のリスクを特定して軽減するのに役立ちます。
Black Duck Hub とその Team Foundation Server (TFS) 用プラグインを使用すると、ビルド プロセス中にオープンソースのセキュリティの脆弱性を自動的に検出して修正できるため、リスクをプロアクティブに管理できます。この統合により、Black Duck Hub ポリシー違反が発生した場合にアラートを受信し、ビルドを失敗させることができます。
参照

「Exploratory Testing」拡張機能は「Test & Feedback」となり、一般利用可能になりました。
誰でも、Windows、Mac、Linux などのプラットフォーム上のブラウザから直接、Web アプリをテストしてフィードバックを送信できるようになりました。現在、 Google Chrome および
Mozilla Firefox (バージョン 50.0 以降が必要) で利用できます。Microsoft Edge のサポートは進行中であり、Edge が Chromium 互換の Web プラットフォームに移行すると有効になる予定です。

Application Insights の可用性テストには 3 種類あります。
URL ping テスト: Azure portal で作成できる簡単なテスト。
マルチステップ Web テスト
カスタム トラック可用性テスト
注 Web アプリ/Web サイトを展開した後、可用性と応答性を監視するための繰り返しテストを設定できます。Azure Application Insights は、世界中の地点から定期的に Web 要求をアプリケーションに送信します。アプリケーションが応答しない場合、または応答が遅すぎる場合に警告を発することができます。
パブリック インターネットからアクセス可能な HTTP または HTTPS エンドポイントの可用性テストを設定できます。テストしている Web サイトに変更を加える必要はありません。実際、自分が所有するサイトである必要さえありません。サービスが依存する REST API の可用性をテストできます。

Azure Boards を GitHub.com に接続するには、Azure Boards から接続して構成します。または、GitHub から Azure Boards アプリをインストールして構成します。
どちらの方法も合理化されており、個人ではなくアプリを介した認証と操作をサポートしています。
注 (以下のステップ 4 を参照):
GitHub 接続を追加します。

1. Azure Boards にサインインします。
2. (1) プロジェクト設定を選択し、(2) GitHub 接続を選択してから、(3) GitHub アカウントに接続します。
3. Azure Boards から GitHub に初めて接続する場合は、GitHub 資格情報を使用してサインインするように求められます。接続するリポジトリの管理者であるアカウントを選択します。
4. [GitHub リポジトリの追加] ダイアログが自動的に表示され、管理者であるすべての GitHub.com リポジトリが選択されます。統合に参加したくないリポジトリの選択を解除します。

Azure SQL や Web サイト (Web アプリ) などの Azure Platform as a Service (PaaS) リソースは、パフォーマンス メトリック データをネイティブに Log Analytics に出力できます。
プレミアム プランでは最大 12 か月のデータが保持され、優れたベースライン機能が提供されます。
Azure portal では、Log Analytics に保存されているデータを分析するためと、アドホック分析用のクエリを作成するために 2 つのオプションを使用できます。
Intelligent Insights は、過去 1 時間のデータベース ワークロードと過去 7 日間のベースライン ワークロードを比較することにより、データベースのパフォーマンスを分析します。
ただし、アプリケーションのメトリクスも処理する必要があります。

BlackDuckとは？

Black Duck（ブラックダック）とは、アプリケーションに含まれるオープンソース（OSS）に起因するセキュリティ脆弱性や、ライセンス違反などのリスクを管理するOSS管理ツールです。オープンソース関連のリスクを、アプリケーションライフサイクル全体を通して管理します。

https://marketplace.visualstudio.com/items?itemName=black-duck-software.hub-tfs

Git 履歴: ファイル履歴はクライアント開発マシンにレプリケートされ、サーバーに接続していないときでも表示できます。Visual Studio および Web ポータルで履歴を表示できます。

IOS デバイスのビルドが成功すると、IPA ファイルが生成されます。デバイスにビルドをインストールするには、有効なプロビジョニング プロファイルと証明書で署名する必要があります。
ブランチから生成されたビルドに署名するには、構成ペインでコード署名を有効にし、プロビジョニング プロファイル (.mobileprovision) と有効な証明書 (.p12) を証明書のパスワードとともにアップロードします。

Azure Artifacts Credential Provider は、.NET 開発ワークフローの一部として NuGet パッケージを復元するために必要な資格情報の取得を自動化します。MSBuild、dotnet、NuGet(.exe) と統合されており、Windows、Mac、Linux 上で動作します。Azure Artifacts フィードのパッケージを使用する場合は常に、
使用している NuGet クライアントに代わって、資格情報プロバイダーがトークンを自動的に取得し、安全に保存します。

Azure Pipelines アプリは OAuth 認証プロトコルを使用しており、組織が有効にするには OAuth 経由のサードパーティ アプリケーション アクセスが必要です。この設定を有効にするには、[組織の設定] > [セキュリティ] > [ポリシー] に移動し、組織の設定の [OAuth を介したサードパーティ アプリケーション アクセス] を [オン] に設定します。

GitHub アプリは Azure Pipelines ID を使用します。個人アクセス トークンと OAuth は個人の GitHub ID を使用します。

YAML ファイルにシークレット変数を設定しないでください。オペレーティング システムは、実行するプロセスのコマンドをログに記録することがよくありますが、入力として渡したシークレットがログに含まれることは望ましくありません。スクリプトの環境を使用するか、変数ブロック内の変数をマップして、シークレットをパイプラインに渡します。
コマンドラインでは決してシークレットを渡さないでください。プレフィックスを追加しても、変数はシークレットになりません。Secret プロパティによりシークレットになりますが、シークレットのログ記録は妨げられません。シークレットを出力としてエコーしないでください。

SonarCloud は、SonarSource が提供する SonarQube をベースとしたクラウド サービスです。SonarQube は、ソース コードの品質を継続的に検査し、20 以上の異なる言語でバグ、脆弱性、コードの臭いを検出するために広く採用されているオープンソース プラットフォームです。SonarCloud Azure DevOps 拡張機能は、SonarCloud でプロジェクトを迅速に分析するために必要なものすべてを提供します。テスト計画は、テスト スイートと個々のテスト ケースをグループ化するために使用されます。これには、静的テスト スイート、要件ベースのスイート、クエリベースのスイートが含まれます。

SonarQube の事前承認により、品質ゲートを設定できます。SonarQube と Azure DevOps を使用して技術的負債を管理できます。
技術的負債は、顧客価値の向上を非効率的に進める開発作業における一連の問題です。技術的負債は、コードを理解しにくく、脆弱にし、変更に時間がかかり、検証が困難にすることで生産性を低下させ、進捗を妨げる計画外の作業を生み出します。これらを管理しないと、技術的負債が蓄積し、長期的にはソフトウェア全体の品質や開発チームの生産性が損なわれる可能性があります。 SonarQube は、コード品質を継続的に検査し、コードの静的分析による自動レビューを実行するためのオープンソース プラットフォームです。
バグの検出
コードの臭い
セキュリティの脆弱性
品質の一元管理
このラボの内容

SonarQube は、コード内の改善点を特定するために使用できる静的アナライザーのセットです。これにより、プロジェクトの技術的負債を分析し、将来的にそれを追跡することができます。Maven および Gradle ビルド タスクを使用すると、新規または既存の Azure DevOps Services ビルド タスクで最小限のセットアップで SonarQube 分析を実行できます
。分析構成タスクを準備して、ビルドを実行する前に必要な設定をすべて構成します。
このタスクは必須です。
.NET ソリューションまたは Java プロジェクトの場合、MSBuild、M​​aven、Gradle タスクとシームレスに統合するのに役立ちます。
CocoaPods は、Swift および Objective-C Cocoa プロジェクトの依存関係マネージャーです。
注: 試験にはこの問題にはいくつかのバージョンがあります。質問には 3 つの正解があります。
MSBuild
Maven
Gradle
質問には、次のようなさまざまな誤った選択肢が含まれる場合もあります。

Chef
Octopus
xCODE
リファレンス

SonarQube と Azure DevOps を使用して技術的負債を管理できます。技術的負債は、顧客価値の向上を非効率的に進める開発作業における一連の問題です。技術的負債は、コードを理解しにくく、脆弱にし、変更に時間がかかり、検証が困難にすることで生産性を低下させ、進捗を妨げる計画外の作業を生み出します。これらを管理しないと、技術的負債が蓄積し、長期的にはソフトウェア全体の品質や開発チームの生産性が損なわれる可能性があります。 SonarQube は、
コードの静的分析による自動レビューを実行するために、コード品質を継続的に検査するためのオープンソース プラットフォームです。 to:
バグの検出
コードの臭い
セキュリティの脆弱性
品質の一元管理
このラボの内容

セキュリティ ツールを開発者の既存の Git ワークフローに直接プラグインすると、コミットとマージのたびにセキュリティ テストまたはレビューが自動でトリガーされます。これらのツールは、さまざまなプログラミング言語と統合開発環境をサポートしています。より一般的なセキュリティ コード ツールには、Gerrit、Phabricator、SpotBugs、PMD、CheckStyle、Find Security Bugs などがあります。

Azure DevOps (旧名 VSTS) インスタンス内でカスタム NuGet パッケージ フィードを使用すると、組織内でパッケージを簡単に配布できます。まず、新しいフィードを作成します。
ビルドされたプロジェクトを公開、パックし、NuGet フィードにプッシュできます。プライベート NuGet フィードを使用する
Azure DevOps の [パッケージ] 領域に戻り、フィードを選択して、[フィードに接続] をクリックします。フィードに関する手順がいくつか表示されますが、設定は非常に簡単です。
パッケージのソース URL をコピーし、Visual Studio に移動して、NuGet パッケージ マネージャーを開き、その設定に移動して、新しいソースを追加するだけです。派手な名前を選択し、ソース URL を挿入します。終わり。
NuGet パッケージ マネージャーでパッケージを検索すると、そこにパッケージが表示され、インストールできる状態になります。右上の選択ボックスから適切なフィード (またはすべてのフィードのみ) を必ず選択してください。

リポジトリの履歴から不要なファイルを完全に削除するには、git filter-branch コマンドまたは BFG Repo-Cleaner オープンソース ツールを使用できます。

既存の Git リポジトリを、GitHub、Bitbucket、GitLab、または別の場所から、Azure DevOps のプロジェクト内の新しいリポジトリまたは空の既存リポジトリにインポートできます。
新しいリポジトリにインポートする [リポジトリ]
、[ファイル] の順に選択します。
リポジトリのドロップダウンから、[リポジトリのインポート] を選択します。
ソース リポジトリが公開されている場合は、ソース リポジトリのクローン URL と新しい Git リポジトリの名前を入力するだけです。

https://docs.microsoft.com/en-us/azure/devops/boards/backlogs/define-features-epics
https://docs.microsoft.com/en-us/azure/devops/boards/work-items/about-work-items

https://docs.microsoft.com/en-us/azure/devops/boards/sprints/best-practices-scrum

GitHub Codespaces 拡張機能を GitHub 上のアカウントに接続すると、Visual Studio Code でコードスペースで直接開発できます。

あなたの会社は、開発者がオープンソース ライブラリを導入すると、ライセンス コンプライアンスの問題が発生することを懸念しています。一般的なオープンソース ライブラリがコード ベースに追加されたときを検出するには、自動プロセスをビルド パイプラインに追加する必要があります。何を使えばいいのでしょうか？

ブラックダック
Black Duck（ブラックダック）とは、アプリケーションに含まれるオープンソース（OSS）に起因するセキュリティ脆弱性や、ライセンス違反などのリスクを管理するOSS管理ツールです。オープンソース関連のリスクを、アプリケーションライフサイクル全体を通して管理します。

Git 履歴: ファイル履歴はクライアント開発マシンにレプリケートされ、サーバーに接続していないときでも表示できます。Visual Studio および Web ポータルで履歴を表示できます。

IOS デバイスのビルドが成功すると、IPA ファイルが生成されます。デバイスにビルドをインストールするには、有効なプロビジョニング プロファイルと証明書で署名する必要があります。
ブランチから生成されたビルドに署名するには、構成ペインでコード署名を有効にし、プロビジョニング プロファイル (.mobileprovision) と有効な証明書 (.p12) を証明書のパスワードとともにアップロードします。

Azure Artifacts Credential Provider は、.NET 開発ワークフローの一部として NuGet パッケージを復元するために必要な資格情報の取得を自動化します。MSBuild、dotnet、NuGet(.exe) と統合されており、Windows、Mac、Linux 上で動作します。Azure Artifacts フィードのパッケージを使用する場合は常に、
使用している NuGet クライアントに代わって、資格情報プロバイダーがトークンを自動的に取得し、安全に保存します。

Azure Pipelines アプリは OAuth 認証プロトコルを使用しており、組織が有効にするには OAuth 経由のサードパーティ アプリケーション アクセスが必要です。この設定を有効にするには、組織設定 > セキュリティ > ポリシーに移動し、組織設定の OAuth を介したサードパーティ アプリケーション アクセスをオンに設定します。

GitHub アプリは Azure Pipelines ID を使用します。個人アクセス トークンと OAuth は個人の GitHub ID を使用します。

YAML ファイルにシークレット変数を設定しないでください。オペレーティング システムは、実行するプロセスのコマンドをログに記録することがよくありますが、入力として渡したシークレットがログに含まれることは望ましくありません。スクリプトの環境を使用するか、変数ブロック内の変数をマップして、シークレットをパイプラインに渡します。
コマンドラインでは決してシークレットを渡さないでください。プレフィックスを追加しても、変数はシークレットになりません。Secret プロパティによりシークレットになりますが、シークレットのログ記録は妨げられません。シークレットを出力としてエコーしないでください。

SonarCloud は、SonarSource が提供する SonarQube をベースとしたクラウド サービスです。SonarQube は、ソース コードの品質を継続的に検査し、20 以上の異なる言語でバグ、脆弱性、コードの臭いを検出するために広く採用されているオープンソース プラットフォームです。SonarCloud Azure DevOps 拡張機能は、SonarCloud でプロジェクトを迅速に分析するために必要なものすべてを提供します。テスト計画は、テスト スイートと個々のテスト ケースをグループ化するために使用されます。これには、静的テスト スイート、要件ベースのスイート、クエリベースのスイートが含まれます。

あなたの会社の主任開発者は、大量の技術的負債が蓄積されているため、新しいアプリケーション機能の追加に予想よりも時間がかかると報告しています。蓄積された技術的負債を減らすために変更を推奨する必要があります。
解決策 コードの結合と依存関係のサイクルを減らすことをお勧めしますか?
これは目標を達成していますか?

はい。

SonarQube の事前承認により、品質ゲートを設定できます。SonarQube と Azure DevOps を使用して技術的負債を管理できます。
技術的負債は、顧客価値の向上を非効率的に進める開発作業における一連の問題です。技術的負債は、コードを理解しにくく、脆弱にし、変更に時間がかかり、検証が困難にすることで生産性を低下させ、進捗を妨げる計画外の作業を生み出します。これらを管理しないと、技術的負債が蓄積し、長期的にはソフトウェア全体の品質や開発チームの生産性が損なわれる可能性があります。 SonarQube は、コード品質を継続的に検査し、コードの静的分析による自動レビューを実行するためのオープンソース プラットフォームです。
バグの検出
コードの臭い
セキュリティの脆弱性
品質の一元管理
このラボの内容

https://qiita.com/omix222/items/42479f14ba50f9f6f69b

SonarQube は静的コード分析ツール

SonarQube は、コード内の改善点を特定するために使用できる静的アナライザーのセットです。これにより、プロジェクトの技術的負債を分析し、将来的にそれを追跡することができます。Maven および Gradle ビルド タスクを使用すると、新規または既存の Azure DevOps Services ビルド タスクで最小限のセットアップで SonarQube 分析を実行できます
。分析構成タスクを準備して、ビルドを実行する前に必要な設定をすべて構成します。
このタスクは必須です。
.NET ソリューションまたは Java プロジェクトの場合、MSBuild、M​​aven、Gradle タスクとシームレスに統合するのに役立ちます。
CocoaPods は、Swift および Objective-C Cocoa プロジェクトの依存関係マネージャーです。
注: 試験にはこの問題にはいくつかのバージョンがあります。質問には 3 つの正解があります。
MSBuild
Maven
Gradle
質問には、次のようなさまざまな誤った選択肢が含まれる場合もあります。

Chef
Octopus
xCODE
リファレンス
https://docs3.sonarqube.org/latest/analysis/scan/sonarscanner-for-azure-devops/
https://docs.microsoft.com/en-us/azure/devops/java/sonarqube? view=azure-devops

SonarQube と Azure DevOps を使用して技術的負債を管理できます。技術的負債は、顧客価値の向上を非効率的に進める開発作業における一連の問題です。技術的負債は、コードを理解しにくく、脆弱にし、変更に時間がかかり、検証が困難にすることで生産性を低下させ、進捗を妨げる計画外の作業を生み出します。これらを管理しないと、技術的負債が蓄積し、長期的にはソフトウェア全体の品質や開発チームの生産性が損なわれる可能性があります。 SonarQube は、
コードの静的分析による自動レビューを実行するために、コード品質を継続的に検査するためのオープンソース プラットフォームです

開発チームは、Microsoft Visual Studio 統合開発環境 (IDE) を使用して、新しい Web ソリューションを構築しています。すべての開発者がカスタム パッケージを利用できるようにする必要があります。パッケージは一元管理する必要があり、最新バージョンが Visual Studio で自動的に使用できるようにする必要があります。どの 3 つのアクションを実行する必要がありますか?

• パッケージをフィードに公開する
• Azure Artifactsで新しいフィードを作成する
• VisualStudioのNuGetパッケージマネージャー設定にパッケージURLを追加します。

リポジトリの履歴から不要なファイルを完全に削除するには、git filter-branch コマンドまたは BFG Repo-Cleaner オープンソース ツールを使用できます。

既存の Git リポジトリを、GitHub、Bitbucket、GitLab、または別の場所から、Azure DevOps のプロジェクト内の新しいリポジトリまたは空の既存リポジトリにインポートできます。
新しいリポジトリにインポートする [リポジトリ]
、[ファイル] の順に選択します。
リポジトリのドロップダウンから、[リポジトリのインポート] を選択します。
ソース リポジトリが公開されている場合は、ソース リポジトリのクローン URL と新しい Git リポジトリの名前を入力するだけです。

Azure Artifacts
Azure DevOpsが提供しているサービスの一つで、NuGetやnpmなど著名なパッケージマネージャのフィード(パッケージを配信するサーバー)を簡単に作成し、公開することができます。nuget.orgで配信されているようなサードパーティ製だけではなく、チーム内のみで使う自家製ライブラリもパッケージマネージャで管理したい時に便利です。

Azure DevOps はパイプライン キャッシュをサポートしていますが、GitHub はサポートしていません。パイプライン キャッシュは、以前の実行からのファイルを再利用するため、ビルド時間を短縮します。キャッシュ パイプライン タスクは、パイプラインにキャッシュを追加し、ジョブのステップ セクションに追加されます。キャッシュ ステップが見つかった場合、キャッシュ パイプライン タスクは、提供された入力に基づいてキャッシュを復元します。キャッシュが見つからない場合、ステップは完了します。ジョブ内のすべてのステップが実行された後でジョブが正常に実行されると、スキップされなかったすべての「キャッシュの復元」ステップに対して「キャッシュの保存」ステップが実行されます。このステップではキャッシュを保存します。

Azure DevOps は、公開プロセスの YAML スクリプトをサポートしていません。

Azure DevOps は、組み込みのシークレット管理システムを提供しません。Azure DevOps では Azure Key Vault サービスを使用できますが、DevOps 自体は統合シークレット管理システムを提供しません。

GitLab には、既知の脆弱性についてソース コードを分析するための静的アプリケーション セキュリティ テスト (SAST) が含まれています。Azure DevOps ではサードパーティのスキャン システムを使用できますが、組み込みの安全性アナライザー自体は提供されていません。

WhiteSource は、オープン ソース コンポーネントのセキュリティと品質だけでなく、ライセンスの問題も継続的にチェックするオープン ソース ツールであるため、WhiteSource を使用することになります。オープンソース リポジトリの最終的なデータベースに対して検証されます。

Visual Studio コード分析はローカル開発環境の機能であるため、選択しないでください。これは、古いライブラリのチェックや脆弱なオープン ソース コンポーネントの検出などのセキュリティ問題に特化した静的ツールではありません。

SonarQube はコードの品質をチェックし、技術的負債を管理するためのオープンソース ツールであるため、選択することはありません。

OWASP ZAP はセキュリティ問題に特化しており、SQL インジェクションやクロスサイト スクリプティングなどの脆弱性を検出するため、これを選択することはありません。

一元化されたバージョン管理により、ファイル レベルでのアクセス許可の制御が可能になります。Team Foundation Version Control (TFVC) の集中バージョン管理機能を使用すると、ファイル レベルでアクセス許可を適用できますが、分散バージョン コントロール モデル (Git) では、最も詳細なアクセス許可をブランチ レベルで適用できます。

クロスプラットフォームのサポートは、分散バージョン管理の利点です。

プル リクエストによるオープンソース フレンドリーなコード レビュー モデルは、分散バージョン管理の利点です。

完全なオフライン サポートは、分散バージョン管理の利点です。

同じデプロイ方法を使用して、デプロイされたアプリが同じように動作するようにするため、クローン ステージオプションを使用します。既存のステージを複製すると、両方のターゲットに同じ設定を適用できます。デプロイメントターゲットを変更するだけで済みます。

カスタム条件では新しいステージを追加できないため、カスタム条件は使用しません。

YAML ファイル内で dependsOn キーワードを使用すると、依存関係の動作を定義できますが、追加のリリース ターゲットを追加することはできないため、DependsOn は使用しません。

すでに 1 つのステージがあり、それを別のステージのベースとして使用できるため、[新しいステージ] オプションは使用しません。まったく新しいステージを作成した場合、自動的には既存のステージと同じ設定にはなりません。

WhiteSource Bolt は、オープンソースの依存関係の脆弱性とライセンスをスキャンするためのツールであるため、これを使用します。200 以上のプログラミング言語をサポートしており、脆弱性を修正するためのガイダンスを提供します。脆弱性、ライセンス、およびインベントリに関するレポートがあります。その Azure Pipelines 拡張機能を使用すると、広範なポリシー構成が可能になるだけでなく、Azure Pipelines ポータルから結果を表示することもできます。

Synopsys の Black Duck はオープンソースの依存関係を独自のデータベースに対してスキャンするため、Black Duck を使用する必要はありません。最新の脆弱性を含む最新のデータベースを維持し、修正、回避策、悪用に関する情報をタイムリーに提供します。彼らは 80 以上のプログラミング言語をカバーしており、多くの情報源から情報を入手しています。

GitLab は、GitLab リポジトリからのコード内の依存関係をスキャンできる CI/CD パイプライン ツールであるため、使用しません。JavaScript、Ruby、Python、PHP、および Java のみをサポートします。

Sonatype Nexus は、既知の脆弱性、ライセンス、古いコンポーネントやサポートされていないコンポーネントの依存関係をスキャンするため、使用しないでください。Azure Pipelines 拡張機能を使用すると、アーティファクトを Sonatype Nexus にアップロードしてスキャンできるようになります。

Veracode は、重大なセキュリティ リスクがある場合に Azure Pipelines 拡張機能がビルド プロセスを停止し、脆弱性を見つけて修正するためのガイダンスを提供するため、使用しないでください。

変数テンプレートを使用すると、制御したい値を保存し、複数のパイプライン間で利用できるようになります。変数グループなど、コードとしてのパイプラインの利点の一部が失われることはありません。

変数グループは使用しないでください。コードとしてのパイプラインの利点の一部が失われるためです。パイプライン ジョブ プロセスをコードで定義し、ソース リポジトリに保存してバージョン管理できるようになります。

変数の 1 つが変更されると、多大な作業が発生し、必要な更新が 1 つ以上欠落するリスクが生じるため、変数を個々のパイプラインごとに手動でコピーすることはありません。

YAML ファイルにはシークレット変数を設定しないため、シークレット変数は設定されません。オペレーティング システムは、プロセスによって実行されたコマンドをログに記録することがよくありますが、入力として渡したシークレットをログに含めたくない場合があります。パイプラインの設定 UI でシークレット変数を構成する必要があります。変数グループでシークレット変数を構成することもできます。

WhiteSource は、オープン ソース コンポーネントのセキュリティと品質だけでなく、ライセンスの問題も継続的にチェックするオープン ソース ツールであるため、WhiteSource を使用することになります。オープンソース リポジトリの最終的なデータベースに対して検証されます。

同じデプロイ方法を使用して、デプロイされたアプリが同じように動作するようにするため、クローン ステージオプションを使用します。既存のステージを複製すると、両方のターゲットに同じ設定を適用できます。デプロイメントターゲットを変更するだけで済みます。

カスタム条件では新しいステージを追加できないため、カスタム条件は使用しません。

YAML ファイル内で dependsOn キーワードを使用すると、依存関係の動作を定義できますが、追加のリリース ターゲットを追加することはできないため、DependsOn は使用しません。

すでに 1 つのステージがあり、それを別のステージのベースとして使用できるため、[新しいステージ] オプションは使用しません。まったく新しいステージを作成した場合、自動的には既存のステージと同じ設定にはなりません。

WhiteSource Bolt は、オープンソースの依存関係の脆弱性とライセンスをスキャンするためのツールであるため、これを使用します。200 以上のプログラミング言語をサポートしており、脆弱性を修正するためのガイダンスを提供します。脆弱性、ライセンス、およびインベントリに関するレポートがあります。その Azure Pipelines 拡張機能を使用すると、広範なポリシー構成が可能になるだけでなく、Azure Pipelines ポータルから結果を表示することもできます。

変数テンプレートを使用すると、制御したい値を保存し、複数のパイプライン間で利用できるようになります。変数グループなど、コードとしてのパイプラインの利点の一部が失われることはありません。

変数グループは使用しないでください。コードとしてのパイプラインの利点の一部が失われるためです。パイプライン ジョブ プロセスをコードで定義し、ソース リポジトリに保存してバージョン管理できるようになります。

インクリメンタル ビルドを選択することになります。セルフホスト型エージェントを使用すると、増分ビルドを実行できます。Microsoft がホストするエージェントを使用する場合、エージェントはビルドまたはリリース パイプラインの完了後に破棄されます。自己ホスト型エージェントの場合はそうではありません。クリーン ビルドの代わりに増分ビルドを実行するか、リポジトリをクリーンアップするパイプラインを定義すると、通常はより速く実行されます。

Wiki を選択するのは、顧客向けのリリース ノートを保存するために使用される最も一般的な方法だからです。ドキュメントの代わりに Wiki を使用する最大の利点は、関係者全員が Wiki にアクセスできることです。

ドキュメント ストアは Azure DevOps の外部の外部システムであるため、選択しません。

リリース ノートをコードベースに保存することは選択しません。お客様は、メモが存在するソース コードにアクセスできなくなります。

環境内のこのビューには、リソースにマップされた名前空間内のオブジェクトのステータスが表示されるため、Kubernetes リソース ビューを使用します。これらのオブジェクトに対するパイプライン トレーサビリティを備えているため、Kubernetes オブジェクトからパイプラインまでトレースバックし、その後コミットに戻ることができます。

[プル リクエストのレビュー アプリを有効にする] 設定をオンにすると、後続の手順で自動生成されるパイプライン YAML にレビュー アプリ関連の構成を含めることができます。

パーソナル アクセス トークン (PAT) を使用します。Azure AD 認証または Microsoft アカウントを使用した Azure DevOps との統合が環境にない場合、解決策は PAT を使用してリポジトリに接続することです。

仮説主導の開発戦略を使用します。機能がカプセル化されると、実稼働の準備が整うまで、その機能を使用して製品またはサービスを開発、テスト、再構築できます。機能フラグを使用すると、実際のメトリクスを使用できます。それらを使用して、機能がエンゲージメントに役立ったか、または収益の向上に貢献したかを知ることができます。機能の影響を確認したら、すべてのユーザーに対してその機能をオンまたはオフに切り替えることができます。

このツールは Visual Studio 内の Azure DevOps サービスのステータスのみを表示するため、Azure DevOps Status Monitor を選択します。

動的条件タイプを使用してアラート ルールを作成します。動的ルールを作成すると、機械学習アルゴリズムを使用して利用可能な履歴データを取得し、メトリック系列の動作パターンに最適なしきい値を計算し、新しいデータに基づいて継続的に学習してしきい値の精度を高めます。

あなたならChocolateyを選ぶでしょう。Chocolatey は、PowerShell 上に構築されたソフトウェア管理ソリューションであり、Windows パッケージ マネージャーとして機能します。

ログ データは、オンプレミスのリソースと Azure プラットフォーム内の両方のさまざまなソースから収集できます。これらは、次のレベルでアクセスして構成できます。

Azure テナントとサブスクリプション: これは管理レベルです。このレベルで取得されるログは、Azure Active Directory 監査ログとアクティビティ ログです。

リソース レベル: このレベルでは、リソース診断、監視ソリューション、メトリック、および Azure テーブル ストレージからデータが取得されます。

仮想マシン レベル: エージェント、データ ソース、運用管理スイートは、Linux および Windows オペレーティング システムからログを取得するために使用されます。

アプリケーション レベル: パフォーマンス メトリックや可用性テストなどのログがこのレベルで収集されます。

コンテナーおよびソフトウェアのレベルは、ログにアクセスして構成できるレベルではありません。コンテナはアプリケーション レベルに分類できます。アプリケーション レベルはソフトウェアからメトリクスを収集します。

プロファイラーを有効にします。Profiler は、Azure の運用環境で実行されているアプリケーションのパフォーマンス トレースを提供する Application Insights の機能です。プロファイラーは、ユーザーに悪影響を与えることなく、大規模なデータを自動的にキャプチャします。これは、特定の Web リクエストを処理するときに最も時間がかかる「ホット」コード パスを特定するのに役立ちます。

このセクションではタグを作成できないため、「プッシュ」ビューから「タグの作成」を選択する必要があります。

タグは履歴ビューから作成できます。

タグはタグビューから作成できます。

タグはコミットビューから作成できます

アクセス モードは、ユーザーが Log Analytics ワークスペース内のログにアクセスできる方法であり、ユーザーがアクセスできるデータの範囲を定義します。Log Analytics ワークスペースのデータにアクセスするには、次の 2 つの方法があります。

ワークスペース コンテキスト モード: このアクセス モードを使用すると、ユーザーは権限のあるワークスペース内のすべてのログを表示できます。

リソースコンテキストモード: このアクセスモードでは、リソースまたはリソースグループ内のすべてのログを表示する権限がユーザーに与えられます。このレベルのクエリのスコープは、そのリソース グループに関連付けられたデータに限定されます。

このサービスからデータを Power BI に取得して分析できるため、Azure Analytics ビューを選択する必要があります。Azure DevOps から Power BI にデータを取得するには 3 つの方法があり、推奨される方法は OData クエリを使用する方法です。

Azure Boards は他のツールと統合する方法がないため、選択しないでしょう。クエリを保存するオプションのみを備えたフィルターを使用できるクエリ機能があります。

Azure Wiki はチームのドキュメントに使用され、作業項目がないため、選択しないでしょう。

Azure Repos はコードのバージョン管理に使用され、Azure Boards で管理される作業項目を使用しないため、選択しません。

アプリケーションを Azure AD に登録します。App Service のアプリ証明書とシークレット ID を生成するには、アプリケーションを Azure AD に登録する必要があります。これは、API トークンを取得するときにアプリケーションがそれ自体を識別して認証できるようにするために必要です。

サービス エンドポイントは作成しません。サービス エンドポイントは、App サービスとその接続先の認証メカニズムを識別するために使用されます。アプリの証明書とシークレットの生成には使用できません。

あなたはアーティファクトを選択するでしょう。コードはコンポーネントにパッケージ化して、パッケージ管理ソリューションである Azure DevOps のアーティファクトにプッシュできます。これは、Azure DevOps でパッケージを作成および使用するための中心的な場所であり、継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインと統合されています。

Azure Repos はコード パッケージの管理ではなく、コードのソース管理に使用されるため、選択しません。

KubernetesManifest タスクは、ベイク、拒否、デプロイ、プロモート、createSecret、スケール、パッチ、および削除のアクションを提供するため、Kubernetes クラスターの Azure パイプライン デプロイに使用します。ベイク アクションは KubernetesManifest タスクで使用でき、テンプレートを Kubernetes マニフェスト ファイルにベイクします。このアクションでは、Helm、Compose、カスタマイズなどのツールを使用します。ベイク処理を行うと、これらの Kubernetes マニフェスト ファイルをクラスターへのデプロイメントに使用できるようになります。KubernetesManifest タスクは、タスクを成功/失敗としてマークする前にオブジェクトの安定性をチェックし、imagePullSecret の作成と参照を簡素化し、アーティファクト置換を実行し、デプロイされたオブジェクトにパイプライン トレーサビリティ関連の注釈を追加し、Helm、kustomization.yaml、または Docker Compose を使用してマニフェストをベイクすることができます。ファイルを作成し、展開戦略の展開を支援します。

パーソナル アクセス トークン (PAT) とエージェント プール名を定義する必要があります。PAT は、仮想マシン上のセルフホステッド エージェントと Azure DevOps の間の認証に使用されます。セルフホステッド エージェントを Azure DevOps のエージェント プールに追加する必要があるため、エージェント プール名が必要です。

Agent.version および Agent.name 環境変数は JSON ファイルで定義する必要があるため、選択しないでください。PowerShell スクリプトは、JSON ファイルのデータに基づいて環境変数を動的に作成します。

この統合により、GitHub コミットと Azure Boards の作業項目のプル リクエストがリンクされるため、GitHub Marketplace から Azure Boards をインストールすることを選択する必要があります。

Azure Pipelines はコード リポジトリを Azure DevOps のビルドおよびリリースと統合するために使用されるため、GitHub Marketplace から Azure Pipelines をインストールすることは選択しません。

Application Insights のアプリケーション マップ機能を使用します。このシナリオでは、Azure SQL データベースの 1 つまたはその依存関係の 1 つが失敗したときにデータベース管理者に通知する必要があります。ステータス200以外のレスポンスが返された場合はエラーの可能性があります。アプリケーション マップでは、健全性 KPI とアラート ステータスを表示できるほか、SQL データベースや HTTP リクエストなど、分散アプリケーションのすべてのコンポーネントにわたるパフォーマンスの問題や障害を特定できます。アプリケーション マップのコンポーネントをクリックすると、アプリケーション イベントやその他の詳細情報が表示されます。アプリで Azure サービスを使用している場合は、SQL Database Advisor の推奨事項などの Azure 診断を確認できます。

Microsoft Teams と YellowAnt を選択する必要があります。ChatOps は会話主導の開発です。Azure DevOps と YellowAnt の統合により、リポジトリに関する通知を受信し、Microsoft Teams から直接アクションを実行できるようになります。主なアイデアは、チャット ルーム内の人々やメンバーを結び付けて、チャットボットによって実行されるコマンドを作成するコラボレーション モデルです。

Azure DevOps で Slack を運用するには、Slack 統合をインストールする必要があるため、Slack を選択することはありません。

Azure DevOps と Skype には ChatOps サポートがないため、Skype を選択することはありません。

SonarCloud を選択するでしょう。SonarQubeをベースにSonarSourceが提供するクラウドサービスで、コードの品質やセキュリティのチェックに利用されます。その主な目的は、バグや脆弱性を含む技術的負債を管理することです。

Git LFS はバイナリ ファイルをリモート ストレージに保存し、コードを別の Git リポジトリに保存するため、すべてのファイルが Azure Repos に保存されることを選択する必要があります。

チームが使用するすべての Git クライアントは、Git LFS クライアントをインストールする必要があります。クライアントが Git LFS ではない場合、Git LFS を通じてコミットされたバイナリ ファイルは表示されません。

この記事の執筆時点では、Azure Repos は Git LFS を使用したリポジトリでの SSH の使用をサポートしていません。

Git LFS は Azure DevOps Services で無料です。

次の方法でログを保存できます。

Azure ストレージ アカウントにアーカイブします。

Log Analytics に送信します。

EventHub にストリーミングします。

メトリクスは、特定の時点におけるシステムの特定の側面を説明する数値です。メトリクスは定期的に収集され、アラートに役立ちます。これらの値を必要なときにいつでも (過去 24 時間、過去 15 日間など) 利用できるようにするには、値をどこかに保存する必要があります。

YAML パイプラインにはタスク グループを使用できません。

ステップ テンプレートを YAML ビルドに統合できます。変数グループには、制御可能で複数のパイプライン間で使用できる値が配置されます。変数グループを使用して、YAML パイプラインに渡す必要があるシークレットなどの値を保存することもできます。YAML ビルドと YAML パイプラインを一緒に使用できます。

このオプションでは、ソース管理で作成されたマークダウン ドキュメントに基づいて構造化ドキュメントが生成されるため、[コードを wiki として公開] 機能を選択する必要があります。マークダウン ファイルは Wiki 内のページとして公開されます。順序を変更してフォルダーをページに昇格させることもできます。コンテンツの更新とドキュメントは Azure Repos で直接管理されます。

Azure Boards の目的は作業項目を管理することであり、コード ドキュメントを保存することではないため、Azure Boards は選択しないでしょう。

Azure Repos の目的はコードの変更をビルドしてリリースすることであり、コード ドキュメントを保存することではないため、Azure Repos は選択しないでしょう。

プロビジョニングされた Wiki は一般的なドキュメントを目的としており、Wiki 内で直接管理する必要があるため、プロビジョニングされた Wiki は選択しません。

リソースを別の Azure テナントにデプロイするため、サービス プリンシパル (手動) を選択します。サービス接続のアクセス許可を管理する場合、または別の Azure テナントにリソースをデプロイする場合は、サービス プリンシパルを手動で構成する必要があります。

サービス プリンシパル (自動) は自動的に Azure テナントに接続し、アプリケーション登録を作成するため、選択しません。このオプションは、Azure サブスクリプションが Azure DevOps アカウントと同じテナントにある場合に使用されます。

マネージド ID は、Azure 内のリソースに ID を与えるために使用され、アプリケーションはその ID を使用して他の Azure リソースにアクセスできるため、選択しません。リソースを別の Azure テナントにデプロイする場合は、このオプションを選択しないでください。

次の機能を使用できます。

一般的な劣化

スマート検出 – パフォーマンスの異常

スマート検出 – 障害の異常

スマート検出は、Web アプリケーションの潜在的な障害の異常やパフォーマンスの問題を自動的に通知する Azure Application Insights の機能です。アプリが Application Insights に送信するテレメトリを積極的に分析します。障害率が上昇したり、クライアントまたはサーバーのパフォーマンスに異常なパターンが発生したりすると、アラートが表示されます。

スマート検出機能を使用すると、次の 3 つの問題が検出されます。

一般的な機能低下: これは、トレースの機能低下、メモリ リーク、例外量の異常な増加、セキュリティ アンチパターンなどの問題を検出し、それに応じてユーザーに通知します。

スマート検出 – パフォーマンスの異常: 応答時間の遅さやページの読み込み時間などの問題を検出します。アプリケーションの動作を監視し、履歴データを使用してそこから学習します。

スマート検出 – 障害異常: これは、機械学習スタジオを使用して、負荷やその他の要因と相関させて、アプリケーションの失敗したリクエストの予想率を設定します。故障率が予想されるエンベロープを超えると、アラートがトリガーされます。

スマート検出 - 稼働時間ステータスは選択しないでしょう。稼働状況などの問題はありません。ただし、稼働時間ステータスはパフォーマンス異常に含まれる可能性があります。

「スマート検出 – ネットワーク応答時間」を選択することはありません。ネットワークの応答時間などの問題はありません。ただし、応答時間はネットワーク異常に含まれる可能性があります。

[Azure DevOps] > [ダッシュボード]に移動し、Azure DevOps ダッシュボードにウィジェットを追加する必要があります。Azure DevOps ダッシュボードに配置できる Azure Cost Insights というウィジェットがあり、これを Azure サブスクリプションに接続し、さまざまな種類のグラフを使用して日ごとの Azure コストを表示します。

コスト分析ブレードは Azure DevOps と直接統合されていないため、[Azure portal] -> [コスト分析] には移動しません。メンバーは毎日、Azure portal を開いて支出コストを確認する必要があります。

このブレードは特定のスコープの専用予算を作成し、支出制限に達したときに管理者に通知するために使用されるため、「Azure portal」→「予算」には移動しません。

このページはAzure DevOps サブスクリプションの請求に使用され、Azure のリソースとコストには使用されないため、[Azure DevOps 組織設定] -> [請求]には移動しません。

SonarCloud を選択するでしょう。SonarQubeをベースにSonarSourceが提供するクラウドサービスで、コードの品質やセキュリティのチェックに利用されます。その主な目的は、バグや脆弱性を含む技術的負債を管理することです。

WhiteSource は、オープン ソース コンポーネントのセキュリティと品質だけでなく、ライセンスの問題も継続的にチェックするオープン ソース ツールであるため、WhiteSource を使用することになります。オープンソース リポジトリの最終的なデータベースに対して検証されます。

Visual Studio コード分析はローカル開発環境の機能であるため、選択しないでください。これは、古いライブラリのチェックや脆弱なオープン ソース コンポーネントの検出などのセキュリティ問題に特化した静的ツールではありません。

SonarQube はコードの品質をチェックし、技術的負債を管理するためのオープンソース ツールであるため、選択することはありません。

OWASP ZAP はセキュリティ問題に特化しており、SQL インジェクションやクロスサイト スクリプティングなどの脆弱性を検出するため、これを選択することはありません。

一元化されたバージョン管理により、ファイル レベルでのアクセス許可の制御が可能になります。Team Foundation Version Control (TFVC) の集中バージョン管理機能を使用すると、ファイル レベルでアクセス許可を適用できますが、分散バージョン コントロール モデル (Git) では、最も詳細なアクセス許可をブランチ レベルで適用できます。

クロスプラットフォームのサポートは、分散バージョン管理の利点です。

プル リクエストによるオープンソース フレンドリーなコード レビュー モデルは、分散バージョン管理の利点です。

完全なオフライン サポートは、分散バージョン管理の利点です。

同じデプロイ方法を使用して、デプロイされたアプリが同じように動作するようにするため、クローン ステージオプションを使用します。既存のステージを複製すると、両方のターゲットに同じ設定を適用できます。デプロイメントターゲットを変更するだけで済みます。

カスタム条件では新しいステージを追加できないため、カスタム条件は使用しません。

YAML ファイル内で dependsOn キーワードを使用すると、依存関係の動作を定義できますが、追加のリリース ターゲットを追加することはできないため、DependsOn は使用しません。

WhiteSource Bolt は、オープンソースの依存関係の脆弱性とライセンスをスキャンするためのツールであるため、これを使用します。200 以上のプログラミング言語をサポートしており、脆弱性を修正するためのガイダンスを提供します。脆弱性、ライセンス、およびインベントリに関するレポートがあります。その Azure Pipelines 拡張機能を使用すると、広範なポリシー構成が可能になるだけでなく、Azure Pipelines ポータルから結果を表示することもできます。

Synopsys の Black Duck はオープンソースの依存関係を独自のデータベースに対してスキャンするため、Black Duck を使用する必要はありません。最新の脆弱性を含む最新のデータベースを維持し、修正、回避策、悪用に関する情報をタイムリーに提供します。彼らは 80 以上のプログラミング言語をカバーしており、多くの情報源から情報を入手しています。

SonarCloud を選択するでしょう。SonarQubeをベースにSonarSourceが提供するクラウドサービスで、コードの品質やセキュリティのチェックに利用されます。その主な目的は、バグや脆弱性を含む技術的負債を管理することです。

アクセス モードは、ユーザーが Log Analytics ワークスペース内のログにアクセスできる方法であり、ユーザーがアクセスできるデータの範囲を定義します。Log Analytics ワークスペースのデータにアクセスするには、次の 2 つの方法があります。

ワークスペース コンテキスト モード: このアクセス モードを使用すると、ユーザーは権限のあるワークスペース内のすべてのログを表示できます。

リソースコンテキストモード: このアクセスモードでは、リソースまたはリソースグループ内のすべてのログを表示する権限がユーザーに与えられます。このレベルのクエリのスコープは、そのリソース グループに関連付けられたデータに限定されます。

Log Analytics ワークスペースからロールベースのアクセス制御 (RBAC) を構成しません。Log Analytics からアクセス モードが有効になっていないため、オプションが正しくありません。RBAC を使用すると、ユーザーまたはグループのアクセスを、その役割に基づいて操作する必要があるワークスペース内のデータの監視のみに制限できます。

[Azure DevOps] > [ダッシュボード]に移動し、Azure DevOps ダッシュボードにウィジェットを追加する必要があります。Azure DevOps ダッシュボードに配置できる Azure Cost Insights というウィジェットがあり、これを Azure サブスクリプションに接続し、さまざまな種類のグラフを使用して日ごとの Azure コストを表示します。

以下は、Azure Automation PowerShell DSC で使用できない共有リソースです。

MOFファイル

ワークフロー

Webhook

DSC 構成は、ノードに適用する前に、まず管理対象オブジェクト フォーマット (MOF) ファイルにコンパイルする必要があります。MOF ファイルは、Runbook に関連付けることができる共有リソースではありません。

ワークフローは並列処理を使用して、複数のタスクを同時に完了できます。ワークフロー Runbook は実行前にコンパイルする必要があるため、PowerShell Runbook よりも起動に時間がかかります。ワークフローは、Runbook に関連付けることができる共有リソースではありません。

MOF ファイル

https://learn.microsoft.com/ja-jp/windows-hardware/drivers/devtest/trace-managed-object-format--mof--file

Git LFS を選択するでしょう。大きなファイルの場合、Git Large File Storage (LFS) を使用すると、大きなファイルをリポジトリから分離しながら、バージョン管理と比較のすべての利点を得ることができます。

Git は、小さいファイル (またはバイナリ) を含まないリポジトリで最もよく機能するため、Git を選択しないでしょう

REST API 呼び出しを使用するのは、強制モードは便利ですが、さまざまな条件下でポリシー定義を徹底的にテストすることに代わるものではないためです。ポリシー定義は、PUT および PATCH REST API 呼び出し、準拠リソースおよび非準拠リソース、リソースにプロパティが欠落しているなどのエッジ ケースを使用してテストする必要があります。

プロジェクト設定でエージェント プールを選択すると、プロジェクト内のすべての並列ジョブとキューに入れられたジョブを識別できるためです。

XML 変換を使用すると、ユーザーは指定された環境に基づいてパッケージを構成できるようになります。これは、Web.config変換構文を使用してファイルを変換し、Web パッケージが展開される環境に基づいています。XML 変換を使用して、デフォルトのパッケージを作成し、そのパッケージを複数のステージにデプロイできます。構成ファイルと変換ファイルが同じフォルダーにある場合、XML 変換が有効になります。

変更をコミットしてパイプラインをトリガーした後は、実際のシークレットは Azure Key Vault のログの一部ではないため、シークレットを表示するには Azure Key Vault CmdLine ジョブを選択します。

パイプラインの概要で公開されたアーティファクトのテキスト ファイルでシークレットを表示できるため、Azure パイプラインの概要で公開されたアーティファクトを選択することは選択しません。

Azure Container Registry タスクを選択します。Azure DevOps で使用して、Azure でコンテナー イメージを構築できます。これは Azure Container Registry 内の一連の機能であり、標準の Dockerfile を使用して、ローカルの Docker ツールを必要とせずに、Azure Container Registry にコンテナー イメージを作成して保存します。

GitOps の主な柱は、Kubernetes ベースのアプリケーションのコードとしてのインフラストラクチャ (IaC) に焦点を当てています。これはクラウド上の Kubernetes モデルであり、アプリケーションの導入、管理、監視を改善するための一連のプラクティスです。Git は、宣言型インフラストラクチャとアプリケーションをチェックするソースです。ソフトウェア エージェントは GitOps とともに使用され、Git とクラスター内で実行されているものとの間の相違をチェックします。違いが見つかると、Kubernetes リコンサイラーはクラスターを自動的に更新またはロールバックします。

Azure テスト プランから自動テストを実行するには、次のアクセス許可が必要です。

導入の管理

リリースの管理

リリースの作成

リリースステージを編集する

プロジェクト共同作成者は上記の権限を持っているため、プロジェクト共同作成者である場合も、自動テストを実行できます。

コンテナー グループを作成するときは、再起動ポリシーを指定する必要があります。Azure には 3 つの既定の再起動ポリシーがあり、それらは次のとおりです。

Always : これは、再起動ポリシーが適用されていない場合にコンテナー グループに適用されるポリシーです。Always に設定すると、このコンテナー グループ内のコンテナーは常に再起動されます。

OnFailure : このグループのコンテナーは、プロセスが失敗した場合にのみ再起動されます。

Never : このコンテナー グループ内のコンテナーは再起動されません。

Windows ログを確認する場合、重大度レベルは「重大」、「警告」、および「エラー」ですが、「重大」、「警告」、および「エラー」という名前の再起動ポリシーはありません。したがって、これらのオプションは正しくありません。

ルーティング テーブルに到達不能の設定がありますが、これは再起動ポリシーではありません。

OData クエリを使用して接続することを選択する必要があります。Power BI は、集約されたデータを Power BI に返す前にフィルター処理する OData クエリを実行できます。これは、Boards データに関する複雑なレポートには推奨される方法ですが、より単純なレポートには推奨されません。OData クエリは SQL クエリと同じ方法で作成できます。

黄色のスティッキー演習は、チームが自ら形成するアイデアです。これは、開発者が興味を持ち、今後数年間の計画期間に取り組みたい製品分野を自由に選択できるアクティビティです。この演習では、開発者が作業内容を選択でき、チーム間のバランスが保たれるため、チームの自律性が実現します。Microsoft によると、この演習に参加した人の 80% は、最終的には現在働いているチームに戻りますが、選択の自由には満足しています。黄色のスティッキーな演習により、開発者は日々の活動や意思決定に大きな影響を与えていると感じることができます。

他の用語はアジャイルでは使用されません。

サービス フックは、 Teams や Slack などの目的のアプリケーションでサブスクリプションを作成し、通知するように構成したイベントのメッセージをチャネルに投稿するため、[プロジェクト設定] -> [サービス フック] を選択する必要があります。

このセクションは特定のイベントの電子メール通知を構成するために使用されるため、[プロジェクト設定] -> [通知] を選択することはありません。

プロジェクトごとに、そのプロジェクトをコンパイルして公開するために必要なすべての手順を含むテンプレートを 1 つ作成します。このソリューションには次の利点があります。

複数のパイプラインでテンプレートを再利用すると、複数のパイプラインでまったく同じタスク シーケンスを実行できるようになります。

別のパイプラインをトリガーするパイプラインのアプローチを回避すると、実行ごとに 2 つのライセンス (オーケストレーション パイプライン用とトリガーされたパイプライン用) が必要なくなります。

複数のジョブを含むビルドを使用すると、プロジェクトの実行ごとに結果が 1 つの結果ページに表示され、トリガーや使用されているプールなどのパイプライン構成から一連のタスクが切り離されます。

他の 6 つのパイプラインすべてをトリガーし、アーティファクトを取得し、すべてをまとめてパックするような、マスター ブランチで自動的にトリガーされる別のパイプラインを作成することはありません。リリースの最後には、パイプラインの結果は 6 つの異なるパイプライン実行とオーケストレーション パイプラインの結果に分散されます。

Azure Monitor for Containers は、プラットフォーム、コンテナー、オーケストレーター レベル、およびある程度のワークロード レベルで、すぐに使えるテレメトリを提供します。Prometheus からの追加のワークロード メトリックを使用すると、Azure Monitor for Container で Azure Kubernetes Services (AKS) のフルスタックのエンドツーエンド監視ビューを取得できます。ただし、Prometheus スクレイパーは次の Kubernetes クラスターのみをサポートします。

Azure Kubernetes サービス (AKS)

Azure Stack またはオンプレミス

Azure Red Hat OpenShift バージョン 3.x

Red Hat OpenShift バージョン 4.x

Azure DevOps フィード ビューを使用します。これにより、フィード内の npm、Maven、NuGet、Python パッケージ バージョンのサブセットをコンシューマーと共有できます。消費者には、テストおよび検証されたパッケージ版が表示されます。品質基準を満たしていないパッケージやまだ開発中のパッケージを保留することができます。ビューとアップストリーム ソースを一緒に使用して、エンタープライズ規模でパッケージを作成および使用できます。

OWASP ZAP を選択するでしょう。これは、インターネットの主要なセキュリティ脅威に対する OWASP 推奨事項に準拠するように機能する侵入ツールです。OWASP ZAP には、新しい定義で毎週更新される Docker コンテナ イメージがあり、展開プロセスに統合して脆弱性を見つけることができます。スキャン後、バックログにバグのリストが作成され、テストはアクティブまたはパッシブに行うことができます。

以下を推奨する必要があります。

バーンダウンチャート

サイクルタイム

速度

リードタイム

スプリントの進行状況を表示するにはバーンダウン チャートを選択し、1 つ以上のチーム、作業項目の種類、期間にまたがるように構成できます。

サイクル タイムは、プロジェクトの開始からタスクが完了するまでの経過時間の尺度として使用されるため、サイクル タイムを選択します。

ベロシティを選択するのは、ベロシティがチームの効率の尺度であり、スプリントごとにストーリー ポイントとして測定されるためです。

Azure リソース グループのデプロイ タスクを選択します。このシナリオでは ARM テンプレートを使用して Azure にデプロイするため、Azure リソース グループのデプロイ タスクが必要です。Override テンプレートのパラメーター フィールドで、Azure Key Vault からのキーを変数として渡します。

Azure Key Vault タスクは選択しないでしょう。これは、Azure リソース グループのデプロイ タスクの前に使用します。Azure Key Vault タスクは、Azure Key Vault からシークレットの最新の値を取得し、それらを次のタスクで使用できるタスク変数として設定します。

OWASP ZAP を選択するでしょう。インターネット上で知られている主な攻撃は、開発者向けの標準意識文書である OWAST Top 10 で調査され、報告されています。OWASP ZAP を使用するには、Azure パイプラインでそれを構成する必要があります。SQL インジェクションやクロスサイト スクリプティングなどのさまざまな種類の脆弱性を検出し、結果を HTML で公開します。

セルフホステッド エージェントと SQLPackage.exe を使用します。SQLPackage.exe を使用すると、PowerShell またはコマンド ライン スクリプトを使用して、データベース公開アクションによって行われた変更の XML レポートを作成できます。SQLPackage.exe を実行するには、セルフホステッド エージェントを使用し、エージェントにツールをインストールする必要があります。以下は XML レポートを作成します。

WhiteSource Bolt タスクをビルド パイプラインに追加します。WhiteSource Bolt は 5 GB を超えるスキャンが可能で、必要に応じてサブスキャンに分割できます。

WhiteSource Bolt は Azure DevOps と統合されており、ソフトウェア内のすべてのオープン ソース コンポーネントを検出するためにコードをスキャンする必要はありません。インベントリ、ライセンス、セキュリティに関する最新のレポートを生成します。また、脆弱で古いオープンソース コンポーネントに関するアラートもリアルタイムで受け取ります。プロジェクトは 1 日に最大 5 回スキャンできます。

オープンソース コンポーネントがビルドに追加されるか、脆弱性が発見されると、WhiteSource は即座にフィードバックを提供します。コピーレフトのオープン ソース ライセンスや古いライブラリに脆弱性が発見された場合、推奨される解決策が通知されます。

これは WhiteSource Bolt の無料バージョンであり、有料バージョンのすべての機能が含まれていないため、WhiteSource タスクをビルド パイプラインに追加しないでください。このバージョンでは、スキャンがサブスキャンに分割されません。

GitLab CI/CD パイプライン ツールをビルド パイプラインに追加することはありません。GitLab では、GitLab リポジトリからのコード内の依存関係のみをスキャンできます。

Black Duck で 5 GB を超えるサイズをスキャンする場合は、サブスキャンに分割する必要があるため、Black Duck タスクをビルド パイプラインに追加しません。

動的に割り当てられるグループを実装します。動的に割り当てられたグループは、ルールを使用して、プロファイルの特性に基づいてメンバーを割り当てます。ユーザーの役職に「マネージャー」という単語が含まれている場合、そのユーザーは自動的にマネージャー グループに割り当てられます。

直接割り当てられたグループは実装しません。直接割り当てられたグループには、特定のユーザーに割り当てられたメンバーシップがあります。管理者は、Azure AD のユーザーをマネージャー グループに追加するかどうかを決定できます。

RBAC が割り当てられたグループは実装しません。RBAC 割り当てグループは、ユーザーのロールに基づいて Azure リソースへのアクセスを管理するためのグループへのアクセスを許可する方法です。

分類法に割り当てられたグループは実装しません。これは、グループを順序または順序に従って整理する方法です。分類法で割り当てられたグループは動的ではありません。

Azure ポリシーに割り当てられたグループは実装しません。Azure ポリシーで定義されたグループは、同じルールの影響を受けるグループです。Azure ポリシーは、コンプライアンスを強制したり、条件を強制したりするために使用されます。グループは動的に作成されません。

Microsoft Teams と Slack はどちらも、Azure Boards で作業項目アクティビティを作成および更新し、プライベート チャネルで通知を提供できます。Microsoft Teams は、職場でのチャット、会議、メモ、添付ファイルの保存を組み合わせた場所を提供する Microsoft のグループ チャット アプリケーションです。Slack は、アジャイル チームや DevOps チームのコラボレーションによく使用されるツールです。

Microsoft Threat Modeling Tool を選択することになります。これはセキュリティ開発ライフサイクルのためのツールであり、アーキテクトや開発者が潜在的なセキュリティ問題を早期に軽減するのに役立ちます。

Azure でソリューション アーキテクチャを作成すると、ツールには重大度ごとに分類された脅威のリストとその軽減手順が表示されます。

Visual Studio コード分析はローカル開発環境の機能であり、セキュリティ問題に特化していない静的ツールであるため、選択しないでしょう。

SonarCloud は、SonarSource が提供する SonarQube ベースのクラウド サービスであるため、選択することはありません。コードの品質をチェックし、技術的負債を管理するために使用されます。

WhiteSource はオープンソースのセキュリティとライセンス コンプライアンスの問題を見つけるためのオープンソース ツールであるため、WhiteSource を選択することはありません。

git-tfs を使用して TFVC から Git に移行する必要があります。Git-TFS ツールは、Git と Team Foundation Server (TFS) リポジトリを接続するためのオープンソース プロジェクトです。コマンドを使用して移行を実行し、すべての履歴を移行できます。また、複数のブランチを移行し、ブランチ関係を保持することもできます。

ヒントはインポート リポジトリの同義語であるため、移行を選択しないでください。

インポート リポジトリは TFVC からコードと履歴を移行できるため、使用することは選択しませんが、履歴は過去 180 日間のみであり、それより古いものは存在しません。インポート リポジトリを使用すると、Git リポジトリをインポートすることもできます。これは、Git リポジトリを GitHub またはその他のパブリックまたはプライベート ホスティング スペースから Azure DevOps Server に移動する場合に特に便利です。

このシナリオの完全な解決策ではないため、新しい Git リポジトリを作成して TFVC からコピーすることはしません。イメージを Git リポジトリに保存できる場合もありますが、TFVC 履歴を保持するには Git-TFS ツールを使用する必要があります。

HTML ファイル形式を選択します。コード カバレッジ アーティファクトには、Cobertura または JaCoCo カバレッジ形式を使用してコード カバレッジを公開する場合にオフラインで表示できる HTML ファイルが含まれています。

補償範囲を選択することはありません。Visual Studio テスト タスクを使用して .NET および .NET Core アプリのカバレッジを収集する場合、アーティファクトには、ダウンロードして Visual Studio でさらに分析するために使用できるカバレッジ ファイルが含まれています。

Azure App Service から問題の診断と解決を選択し、自動修復を構成します。Azure App Service 診断は、推奨されるトラブルシューティングを使用して Web アプリの問題を診断し、解決するのに役立ちます。Azure App Service の問題の診断と解決機能から自動修復を有効にすることができます。

PowerShell、Azure CLI、またはストレージ SDK を使用して、ストレージ ログを有効にすることができます。

ローカル マシンから PowerShell を使用してログ記録を有効にすることができます。Get-AzureStorageServiceLoggingPropertyコマンドレットを使用して現在の設定を取得することも、 Set-AzureStorageLoggingPropertyを使用して変更することもできます。次のコマンド ログは、保持期間が 7 日に設定された既定のストレージ アカウントのキュー サービスでの要求の書き込みと削除を記録します。

変数グループを使用してシークレットを追加すると、複数のパイプラインから使用できる再利用可能な変数の構成が作成されます。Azure DevOps から変数グループを構成するには、[パイプライン] -> [ライブラリ] -> [変数グループの追加] に移動し、変数グループ名を入力して、[ Azure Key Vault からシークレットを変数としてリンクする] を選択します。

このタスクは、Azure Key Vault からシークレットをダウンロードし、パイプラインで使用される変数として設定するために使用されるため、ステージで Azure Key Vault タスクを使用してシークレットを追加することはありません。

Azure DevOps から Azure Key Vault にアクセスする必要がある場合、このアクションは推奨されないため、REST 呼び出しを使用してシークレットを追加しないでください。REST 呼び出しシナリオは、アプリケーションが Azure Key Vault からシークレットを取得するときに使用されます。

アクセス ポリシーは、誰にアクセスを許可するように Azure Key Vault で構成されているため、サービス プリンシパルにアクセス ポリシーを追加することはありません。

クエリ ベースのテスト スイートを選択するのは、クエリを使用して、特定の特性を持つテスト ケース (たとえば、Priority=1 のすべてのテスト) をグループ化できるためです。スイートには、定義したクエリによって返されるすべてのテスト ケースが自動的に含まれます。

[パイプライン] -> [オプション] -> [ボードへのデプロイメント ステータスのレポート]を選択する必要があります。これは、この機能により、関連するステージを含むデプロイメントの概要が作成され、ボード内の作業項目が含まれるためです。

リポジトリとして BitBucket を選択するのは、この統合では、GitHub および Azure Repos のコミットにのみリンクされている Azure Pipelines for Jira 課題で実行されたデプロイメントの追跡がサポートされているためです。BitBucket リポジトリのトレーサビリティは有効になりません。

現在、統合ではデプロイ (リリース) のトレーサビリティのみがサポートされているため、Jira でビルド情報を表示することを選択します。Jira でのビルド情報の表示はサポートされていません。

現在、統合ではクラシック リリースからのデプロイメントのトレーサビリティのみがサポートされているため、YAML パイプライン サポートを選択します。YAML パイプラインからのビルドとデプロイはサポートされていません。

Jira クラウドのアプリケーションの管理ページから複数の Azure DevOps 組織の統合を構成できるため、複数の Azure DevOps 組織を選択することはありません。

この統合では、GitHub および Azure Repos のコミットにリンクされた Azure Pipelines for Jira の問題で実行されるデプロイメントの追跡がサポートされているため、リポジトリとして GitHub を選択することはありません。

この統合では、GitHub および Azure Repos のコミットにリンクされた Azure Pipelines for Jira の問題で実行されたデプロイメントの追跡がサポートされているため、リポジトリとして Azure Repos を選択することはありません。

PowerShell を選択することになります。コマンドレットSet-AzureKeyVaultSecretを使用すると、キー コンテナーが存在しない場合はキー コンテナーにシークレットを追加し、存在する場合はシークレットの新しいバージョンを作成できます。

Azure Key Vault タスクは、Azure Key Vault からシークレットをダウンロードし、パイプラインのタスクで使用する変数として設定するために使用されるため、選択しません。

変数グループは、Azure Key Vault から値を取得し、複数のパイプラインで使用するために使用されるため、選択しません。

環境変数は Azure Key Vault から値を取得し、パイプラインで使用するために使用されるため、選択しません。

この問題を解決するには、Android ビルド オプションで [選択した ABI ごとに 1 つのパッケージ (.apk) を生成する]を無効にします。一部の Android 構成では複数の APK ファイルが作成されるため、どのバイナリをテストするかについてビルド サービスが混乱する可能性があります。Android アプリには起動テスト用のインターネット許可が必要であり、アプリのマニフェストでインターネット許可を宣言する必要があります。

アプリファイルのファイルサイズは減りません。アップロードされるファイルごとに 400 MB の制限があります。このシナリオでは、Android 構成では単一のファイルではなく、複数の APK ファイルが作成されます。アプリ ファイルまたは build-dir コンテンツのサイズは、サイズ制限を超えてはなりません。このシナリオでは、問題はファイル サイズではありません。

WhiteSource を選択すると、推移的な依存関係を含むオープンソース コンポーネントが自動的に検出され、ビルドを実行するたびにチェックされるためです。

この拡張機能はソース コードの脆弱性を特定するように設計されているため、Micro Focus Fortify を選択しないでください。

Fortify Static Code Analyzer は、ソフトウェアのセキュリティ脆弱性の根本原因を特定するように設計されているため、選択しないでください。

Checkmarx は、技術的および論理的なセキュリティ上の欠陥を特定、追跡、修正するように設計されているため、この拡張機能は選択しないでしょう。

Azure Resource Manager サービス エンドポイントを作成するのは、サービス プリンシパル認証 (SPA) を使用して Microsoft Azure サブスクリプションへの接続を定義し、セキュリティで保護するためです。このエンドポイントは、Azure DevOps と Azure を接続するために使用されます。

フィーチャー ブランチをマスター ブランチに直接マージすべきではないため、GitFlow ワークフローを選択する必要があります。GitFlow では、機能ブランチが作成され、開発ブランチにマージされます。フィーチャー ブランチがマスター ブランチまたはメイン ブランチに直接マージされることはありません。

トランクベースの開発は、変更のたびにマスターから新しいブランチを作成し、それをマスター ブランチにマージして戻すため、選択しないでしょう。

フォーク ワークフローは、開発者がプロ​​ジェクトにアクセスできず、プロジェクトをフォークして新しい変更を作成し、プロジェクトに貢献する状況を対象としているため、選択しません。

基本ワークフローは 1 つの中央リポジトリを使用するため、選択しません。すべての開発者はプロジェクトをローカルにクローンし、変更を中央リポジトリにコミットします。

Microsoft Teams と Slack はどちらも、Azure Boards での作業項目のアクティビティを監視できます。Microsoft Teams は、職場でのチャット、会議、メモ、添付ファイルの保存を組み合わせた場所を提供する Microsoft のグループ チャット アプリケーションです。Slack は、アジャイル チームや DevOps チームのコラボレーションによく使用されるツールです。

WhiteSource は、オープン ソース コンポーネントのセキュリティと品質だけでなく、ライセンスの問題も継続的にチェックするオープン ソース ツールであるため、WhiteSource を使用することになります。オープンソース リポジトリの最終的なデータベースに対して検証されます。

SonarQube はコードの品質をチェックし、技術的負債を管理するためのオープンソース ツールであるため、選択することはありません。

WhiteSource Bolt は、オープンソースの依存関係の脆弱性とライセンスをスキャンするためのツールであるため、これを使用します。200 以上のプログラミング言語をサポートしており、脆弱性を修正するためのガイダンスを提供します。脆弱性、ライセンス、およびインベントリに関するレポートがあります。その Azure Pipelines 拡張機能を使用すると、広範なポリシー構成が可能になるだけでなく、Azure Pipelines ポータルから結果を表示することもできます。

変数テンプレートを使用すると、制御したい値を保存し、複数のパイプライン間で利用できるようになります。変数グループなど、コードとしてのパイプラインの利点の一部が失われることはありません。

パーソナル アクセス トークン (PAT) を使用します。Azure AD 認証または Microsoft アカウントを使用した Azure DevOps との統合が環境にない場合、解決策は PAT を使用してリポジトリに接続することです。

仮説主導の開発戦略を使用します。機能がカプセル化されると、実稼働の準備が整うまで、その機能を使用して製品またはサービスを開発、テスト、再構築できます。機能フラグを使用すると、実際のメトリクスを使用できます。それらを使用して、機能がエンゲージメントに役立ったか、または収益の向上に貢献したかを知ることができます。機能の影響を確認したら、すべてのユーザーに対してその機能をオンまたはオフに切り替えることができます。

このサービスからデータを Power BI に取得して分析できるため、Azure Analytics ビューを選択する必要があります。Azure DevOps から Power BI にデータを取得するには 3 つの方法があり、推奨される方法は OData クエリを使用する方法です。

次の方法でログを保存できます。

Azure ストレージ アカウントにアーカイブします。

Log Analytics に送信します。

EventHub にストリーミングします。

以下は、Azure Automation PowerShell DSC で使用できない共有リソースです。

MOFファイル

ワークフロー

Webhook

Azure テスト プランから自動テストを実行するには、次のアクセス許可が必要です。

導入の管理

リリースの管理

リリースの作成

リリースステージを編集する

OWASP ZAP を選択するでしょう。これは、インターネットの主要なセキュリティ脅威に対する OWASP 推奨事項に準拠するように機能する侵入ツールです。OWASP ZAP には、新しい定義で毎週更新される Docker コンテナ イメージがあり、展開プロセスに統合して脆弱性を見つけることができます。スキャン後、バックログにバグのリストが作成され、テストはアクティブまたはパッシブに行うことができます。

以下を推奨する必要があります。

バーンダウンチャート

サイクルタイム

速度

リードタイム

スプリントの進行状況を表示するにはバーンダウン チャートを選択し、1 つ以上のチーム、作業項目の種類、期間にまたがるように構成できます。

サイクル タイムは、プロジェクトの開始からタスクが完了するまでの経過時間の尺度として使用されるため、サイクル タイムを選択します。

ベロシティを選択するのは、ベロシティがチームの効率の尺度であり、スプリントごとにストーリー ポイントとして測定されるためです。

リード タイムを選択するのは、リード タイムは作業項目に関係しており、作業項目の作成から完了までの存続期間を測定するのにかかる時間であるためです。

App Center で診断が有効になっている場合、アプリケーションのログとクラッシュ レポートが自動的に生成されます。アプリに対する App Center の診断を有効にするには、App Center SDK をアプリに統合する必要があります。

Azure portal からアラート ルールを作成しても、目標は達成されません。あなたには、アプリケーションがクラッシュしたときにクラッシュ ログを自動的に生成するソリューションを考え出すことが求められています。アラート ルールではこれは行われません。

Azure Monitor を使用すると、Azure 上のアプリケーションとサーバー、およびオンプレミス インフラストラクチャを監視できます。これは、Application Insights と統合され、アプリケーション全体や依存関係などの問題を検出および診断する Microsoft のネイティブ監視ソリューションです。

SonarQube(ソナーキューブ)とは、コード内の「バグ発見」「脆弱性発見」「メンテナンス困難なコード検出」などをサポートする自動コードレビューツールです。すべての開発者がよりクリーンで安全なコードを作成できるように、既存のCI/CDワークフローと統合して、プロジェクトブランチとプルリクエスト全体で継続的なコードインスペクションが可能となります。

SonarCloud を選択するでしょう。SonarQubeをベースにSonarSourceが提供するクラウドサービスで、コードの品質やセキュリティのチェックに利用されます。その主な目的は、バグや脆弱性を含む技術的負債を管理することです。

WhiteSource はオープンソースのセキュリティとライセンス コンプライアンスの問題を見つけるためのオープンソース ツールであるため、WhiteSource を選択することはありません。

Microsoft Threat Modeling Tool は、アーキテクトや開発者が潜在的なセキュリティ問題を早期に軽減するのに役立つインフラストラクチャおよび構成用のツールであるため、選択しないでしょう。

スマート検出は、Web アプリケーションの潜在的なパフォーマンス上の問題や障害の異常を自動的に警告します。アプリが Application Insights に送信するテレメトリのプロアクティブな分析を実行します。障害率が突然上昇した場合、またはクライアントまたはサーバーのパフォーマンスに異常なパターンが発生した場合は、アラートが表示されます。

ンバン ボードのカスタマイズ - 高品質のソフトウェアを一貫して提供するチームの能力を最大限に高めるために、カンバンでは 2 つの主要なプラクティスを重視します。1 つ目の作業フローの視覚化では、チームのワークフロー ステージをマッピングし、それに合わせてカンバン ボードを構成する必要があります。カンバン ボードはバックログをインタラクティブな看板に変え、視覚的な作業フローを提供します。

Azure DevOps (以前の VSTS) インスタンス内でカスタム NuGet パッケージ フィードを使用すると、組織内でパッケージを簡単に配布できるようになります。まず、新しいフィードを作成します。A: ビルドされたプロジェクトを公開、パックし、NuGet フィードにプッシュできます。E: プライベート NuGet フィードを使用する Azure DevOps の [パッケージ] 領域に戻り、フィードを選択して、[フィードに接続] をクリックします。フィードに関する手順がいくつか表示されますが、設定は非常に簡単です。

PMD はソース コード アナライザーです。未使用の変数、空の catch ブロック、不要なオブジェクトの作成など、一般的なプログラミングの欠陥を検出します。Apache Maven PMD プラグインを使用すると、プロジェクトのソース コードに対して PMD コード分析ツールを自動的に実行し、その結果を含むサイト レポートを生成できます。

マルチステージ ビルドは、デーモンとクライアントに Docker 17.05 以降が必要な新機能です。マルチステージ ビルドは、Dockerfile を読みやすく保守しやすい状態に保ちながら最適化することに苦労している人にとって役立ちます。

IOS デバイスのビルドが成功すると、ipa ファイルが生成されます。デバイスにビルドをインストールするには、有効なプロビジョニング プロファイルと証明書で署名する必要があります。ブランチから生成されたビルドに署名するには、構成ペインでコード署名を有効にし、プロビジョニング プロファイル (.mobileprovision) と有効な証明書 (.p12) を証明書のパスワードとともにアップロードします。

A: NPM の依存関係を解決するには、プラグインを実行する前に、まず関連するフォルダーで「npm install」コマンドを実行する必要があります。C: すべての npm パッケージには、通常はプロジェクトのルートに package.json と呼ばれるファイルが含まれています。このファイルには、プロジェクトに関連するさまざまなメタデータが含まれています。このファイルは、プロジェクトの識別と処理を可能にする情報を npm に与えるために使用されます。プロジェクトの依存関係。プロジェクトの説明、特定のディストリビューション内のプロジェクトのバージョン、ライセンス情報、さらには構成データなどの他のメタデータも含めることができます。これらはすべて、npm とパッケージのエンドユーザーの両方にとって重要です。 。

ゲートのシナリオと使用例には以下が含まれます。 * 品質検証。合格率やコード カバレッジなどのビルド アーティファクトに関するテストのメトリクスをクエリし、それらが必要なしきい値内にある場合にのみデプロイします。Quality Gates を使用して、導入前または導入後に監視を統合します。これにより、アプリケーションが開発から運用に移行する際に主要な健全性/パフォーマンス指標 (KPI) を確実に満たし、インフラストラクチャ環境や規模の違いが KPI に悪影響を与えることがなくなります。注: ゲートを使用すると、外部サービスからの正常性シグナルの自動収集が可能になり、すべてのシグナルが同時に成功した場合にリリースを促進するか、タイムアウトでデプロイメントを停止します。通常、ゲートはインシデント管理、問題管理、変更管理、モニタリング、

ブランチ ポリシーは、チームが開発の重要なブランチを保護するのに役立ちます。ポリシーは、チームのコード品質と変更管理基準を強制します。

スカッシュ マージは、プル リクエストの完了時にトピック ブランチの Git 履歴を圧縮できるマージ オプションです。トピック ブランチの各コミットがデフォルト ブランチの履歴に追加されるのではなく、スカッシュ マージによってファイルのすべての変更が取得され、それらがデフォルト ブランチの単一の新しいコミットに追加されます。これについて簡単に考えると、スカッシュ マージではファイルの変更のみが得られ、通常のマージではファイルの変更とコミット履歴が得られると考えられます。

キューイング ポリシーに対して選択できるオプションは次のとおりです。 * 並行デプロイメントの数 * デプロイメントの最大数を指定すると、さらに 2 つのオプションが表示されます。 - すべてを順番にデプロイする - 最新のものをデプロイし、残りをキャンセルする: このオプションは、次の場合に使用します。ビルドよりも早くリリースを作成し、最新のビルドのみをデプロイしたい場合。

B: Jenkins の組み込み Git プラグインまたは Team Foundation Server プラグインは、数分ごとに Team Services リポジトリをポーリングし、変更が検出されたときにジョブをキューに入れることができます。D: Azure DevOps/Visual Studio Team Services を使用してアクセス トークンを作成する E: より緊密な統合が必要な場合、Team Services はそれを実現する 2 つの追加方法を提供します。1) Jenkins サービス フック、2) Jenkins のビルドおよびリリース タスクです。

Docker タスクを使用して ACR にサインインし、後続のスクリプトを使用してイメージをプルし、コンテナー イメージの脆弱性をスキャンできます。ビルドまたはリリース パイプラインで Docker タスクを使用します。このタスクは、Docker または Azure Container レジストリで使用できます。

Azure SQL Analytics でのデータ分析は、カスタム クエリとレポート用の Log Analytics 言語に基づいています。Azure Monitor Logs は Azure Data Explorer に基づいており、ログ クエリは同じ Kusto クエリ言語 (KQL) を使用して作成されます。これは、読みやすく、作成しやすいように設計された機能豊富な言語であり、最小限のガイダンスで使い始めることができるはずです。

アップストリーム ソースを使用すると、製品のすべての依存関係を 1 つのフィードで管理できます。特定の製品のすべてのパッケージをその製品のフィードに公開し、同じフィード内のリモート フィードから上流のソースを介してその製品の依存関係を管理することをお勧めします。このセットアップにはいくつかの利点があります。 * 簡単さ: NuGet.config、.npmrc、または settings.xml には 1 つのフィード (フィード) が含まれます。* 決定性: フィードはパッケージ リクエストを順番に解決するため、同じコミットまたは変更セットで同じコードベースを再構築すると、同じパッケージ セットが使用されます。 * 来歴: フィードはアップストリーム ソース経由で保存したパッケージの出自を知っているため、フィードに公開されたカスタムまたは悪意のあるコピーではなく、元のパッケージを使用しています * 安心: 上流のソース経由で使用されるパッケージは、最初の使用時にフィードに保存されることが保証されます。上流のソースが無効化または削除された場合、またはリモート フィードがダウンした場合、または依存するパッケージが削除された場合でも、開発とビルドを続行できます。

• 各チーム内で、ユーザーはさまざまなチャネルを作成して、トピックごとにコミュニケーションを整理できます。各チャネルには数人のユーザーを含めることも、数千のユーザーに拡張することもできます。* Microsoft Teams は、Android、iOS、Mac、Windows のシステムおよびデバイスで動作します。Chrome、Firefox、Internet Explorer 11、および Microsoft Edge Web ブラウザでも動作します * Microsoft Teams のゲスト アクセス機能を使用すると、ユーザーはメッセージング、会議、ファイル共有のための内部チャネルに組織外のユーザーを招待できます。この機能は、企業間のプロジェクト管理を容易にするのに役立ちます。* Teams は Azure DevOps と統合されます 注: Slack も正解ですが、ここでは選択肢になりません

Azure DevOps にインストールされている Azure DevTest Labs Tasks 拡張機能を使用すると、CI/CD のビルドおよびリリース パイプラインを Azure DevTest Labs と簡単に統合できます。この拡張機能は、次の 3 つのタスクをインストールします。 * VM の作成 * VM からカスタム イメージの作成 * VM の削除 このプロセスにより、たとえば、特定のテスト タスク用の「ゴールデン イメージ」を迅速に展開し、必要に応じて削除することが簡単になります。テストが終わりました

技術的負債とは、アプリケーションの存続期間中に行われた最適ではない技術的決定の蓄積です。最終的には、物事を変えることがますます難しくなります。IT への取り組みが停止するのは、「歯車の砂」のせいです。

オープンソース ソフトウェアの保護と管理 Black Duck は、組織がアプリケーションとコンテナのポートフォリオ全体でオープンソースのセキュリティ、ライセンス コンプライアンス、コード品質のリスクを特定し、軽減するのに役立ちます。Black Duck Hub とその Team Foundation Server (TFS) 用プラグインを使用すると、ビルド プロセス中にオープン ソースのセキュリティの脆弱性を自動的に検出して修正できるため、リスクをプロアクティブに管理できます。この統合により、Black Duck Hub ポリシー違反が発生した場合にアラートを受信し、ビルドを失敗させることができます。注: WhiteSource も適切な答えですが、ここではオプションではありません。

https://www.shadan-kun.com/blog/measure/vulnerability/2961/

代わりに、コードの複雑さを軽減します。注: 技術的負債とは、アプリケーションの存続期間中に行われた最適ではない技術的決定の蓄積です。最終的には、物事を変えることがますます難しくなります。IT への取り組みが停止するのは、「歯車の砂」のせいです。

E: ライブ Web アプリの例外は Application Insights によって報告されます。注: 定期レポートは、ビジネスに不可欠なサービスがどのように行われているかをチームに知らせるのに役立ちます。開発者、DevOps/SRE チーム、およびそのマネージャーは、全員がポータルにサインインする必要がなく、確実に洞察を提供する自動レポートによって生産性を高めることができます。このようなレポートは、アラート ルールがトリガーされない可能性のある遅延、負荷、または障害率の段階的な増加を特定するのにも役立ちます。A: Application Insights データをプログラムでクエリして、スケジュールに従ってカスタム レポートを生成できます。次のオプションは、すぐに開始するのに役立ちます: * Microsoft Flow を使用してレポートを自動化する * Logic Apps を使用してレポートを自動化する

アプリケーション マップは、分散アプリケーションのすべてのコンポーネントにわたるパフォーマンスのボトルネックや障害のホットスポットを特定するのに役立ちます。マップ上の各ノードは、アプリケーション コンポーネントまたはその依存関係を表します。ヘルス KPI とアラート ステータスも含まれます。

代わりに、プロジェクトに継続的保証を実装します。注: AzSK のサブスクリプション セキュリティ健全性チェック機能には、サブスクリプションを検査し、サブスクリプションをより高いリスクにさらす可能性があるセキュリティの問題、構成ミス、または古い成果物/設定をフラグで知らせる一連のスクリプトが含まれています。

GitLab CI/CD は、GitHub または BitBucket などの他の Git サーバーで使用できます。プロジェクト全体を GitLab に移動する代わりに、外部リポジトリに接続して GitLab CI/CD の利点を活用できます。注: パイプラインが Bitbucket Cloud などのリモートのサードパーティ リポジトリ ホストを使用する場合、リポジトリはコードが変更され、ビルドをトリガーする必要があるときに Azure Pipelines Server または TFS に通知する Webhook を使用して構成されます。オンプレミスのインストールは通常、ファイアウォールの背後で保護されているため、サードパーティの Webhook はオンプレミスのサーバーに到達できません。回避策として、コードが変更されたときに Webhook の代わりにポーリングを使用してビルドをトリガーする外部 Git リポジトリ タイプを使用できます。

Application Insights は、パフォーマンスの問題や例外を通知し、根本原因の発見と診断に役立ちます。Application Insights は、Java と ASP.NET の両方の Web アプリケーションとサービス、WCF サービスを監視できます。これらは、オンプレミス、仮想マシン、または Microsoft Azure Web サイトとしてホストできます。クライアント側では、Application Insights は Web ページや、iOS、Android、Windows ストア アプリなどのさまざまなデバイスからテレメトリを取得できます。

セルフホステッド エージェントでパイプラインを実行する場合、デフォルトでは、連続する 2 回の実行の間にサブディレクトリはクリーンアップされません。その結果、それを利用するタスクが実装されていれば、増分ビルドとデプロイメントを実行できます。ジョブのワークスペース設定を使用して、この動作をオーバーライドできます。

代わりに、コードの複雑さを軽減します。注: 技術的負債とは、アプリケーションの存続期間中に行われた最適ではない技術的決定の蓄積です。最終的には、物事を変えることがますます難しくなります。IT への取り組みが停止するのは、「歯車の砂」のせいです。

SonarQube の事前承認により、品質ゲートを設定できます。C: SonarQube と Azure DevOps を使用すると、技術的負債を管理できます。注: 技術的負債とは、顧客価値の向上を非効率的に進める開発作業における一連の問題です。技術的負債は、コードを理解しにくく、脆弱にし、変更に時間がかかり、検証が困難にすることで生産性を低下させ、進捗を妨げる計画外の作業を生み出します。これらを管理しないと、技術的負債が蓄積し、長期的にはソフトウェア全体の品質や開発チームの生産性が損なわれる可能性があります。 SonarQube は、コード品質を継続的に検査し、コードの静的分析による自動レビューを実行するためのオープンソース プラットフォームです。 ✑ バグの検出 ✑ コードの臭い ✑ セキュリティの脆弱性 ✑ 品質の一元化

Azure Artifacts では、パッケージへのアクセスを整理および制御するために使用できる複数のフィードの概念が導入されています。Azure Artifacts でホストするパッケージはフィードに保存されます。フィードに権限を設定すると、シナリオに応じて必要な数のユーザーとパッケージを共有できます。フィードには、所有者、投稿者、コラボレーター、読者の 4 つのアクセス レベルがあります。

多層アプリケーションをデプロイする Azure Resource Manager テンプレートがあります。デプロイメントを実行するユーザーが、アプリケーションで使用されるアカウント資格情報と接続文字列を表示できないようにする必要があります。何を使えばいいのでしょうか？

あなたの会社は、開発者がオープンソース ライブラリを導入すると、ライセンス コンプライアンスの問題が発生することを懸念しています。一般的なオープンソース ライブラリがコード ベースに追加されたときを検出するには、自動プロセスをビルド パイプラインに追加する必要があります。何を使えばいいのでしょうか？

Jenkins を使用して、Azure DevOps Services と TFS のサービス フックを作成できます。

IT サービス管理コネクタ (ITSMC) を使用すると、Azure とサポートされている IT サービス管理 (ITSM) 製品/サービスを接続できます。ITSMC は、次の ITSM ツールとの接続をサポートしています。 * ServiceNow * System Center Service Manager * Provance * Cherwell ITSMC を使用すると、 * Azure アラート (メトリック アラート、アクティビティ ログ アラート、および Log Analytics アラート) に基づいて、ITSM ツールで作業項目を作成できます。 。* オプションで、インシデントと変更要求データを ITSM ツールから Azure Log Analytics ワークスペースに同期できます。

dependabot は、依存関係の更新を定期的にチェックするのに便利なツールです。プロジェクトを最新の状態に維持できるようにすることで、DependaBot は技術的負債を削減し、パッチがリリースされたときにすぐにセキュリティの脆弱性を適用できます。dependabot はどのように機能しますか? 1. dependaBot は更新の依存関係を定期的にチェックします。 2. 更新が見つかった場合、DependaBot はこのアップグレードとプル リクエストを使用して新しいブランチを作成し、承認を求めます。 3. あなたは新しいプル リクエストをレビューし、テストが合格したことを確認し、コードをレビューして、変更をマージできます

アプリケーションの健全性を監視することは、展開を管理およびアップグレードするための重要なシグナルです。Azure 仮想マシン スケール セットは、OS イメージの自動アップグレードを含むローリング アップグレードのサポートを提供します。これは、個々のインスタンスの正常性監視に依存してデプロイをアップグレードします。正常性拡張機能を使用して、スケール セット内の各インスタンスのアプリケーションの正常性を監視し、自動インスタンス修復を使用してインスタンスの修復を実行することもできます。

アドホックまたは開発プロビジョニング プロファイルで署名された iOS アプリをリリースする場合は、リリースをコンパイルする前にテスターのデバイス ID (UDID) を取得し、プロビジョニング プロファイルに追加する必要があります。配布グループの [デバイスを自動的に管理する] 設定を有効にすると、App Center は前述の操作を自動化し、手動タスクを実行するための制約を解除します。ワークフローを自動化する一環として、Apple ID のユーザー名とパスワード、および実稼働証明書を .p12 形式で指定する必要があります。新しいリリースを配布するか、テスターの 1 人が新しいデバイスを登録すると、App Center は自動化タスクを開始します。まず、Apple ID を使用して、ターゲット配布グループのすべてのデバイスが登録されます。開発者ポータルでは、アプリで使用されるすべてのプロビジョニング プロファイルが新規と既存の両方のデバイス ID で生成されます。その後、新しく生成されたプロビジョニング プロファイルが App Center サーバーにダウンロードされます。

トラフィックを処理するコンテナ化されたアプリケーションの場合、コンテナが受信リクエストを処理する準備ができているかどうかを確認することをお勧めします。Azure Container Instances は、特定の条件下でコンテナーにアクセスできないように構成を含める Readiness プローブをサポートしています。

Docker タスクを使用して ACR にサインインし、後続のスクリプトを使用してイメージをプルし、コンテナー イメージの脆弱性をスキャンできます。ビルドまたはリリース パイプラインで Docker タスクを使用します。このタスクは、Docker または Azure Container レジストリで使用できます。

Octopus Deploy は、ASP.NET Web アプリケーション、Java アプリケーション、NodeJS アプリケーション、およびカスタム スクリプトの複数の環境への展開を簡単に自動化できる自動展開サーバーです。

WhiteSource は、継続的なオープンソース ソフトウェアのセキュリティとコンプライアンス管理のリーダーです。WhiteSource は、プログラミング言語、ビルド ツール、開発環境に関係なく、ビルド プロセスに統合されます。バックグラウンドで自動的、継続的、サイレントに動作し、WhiteSource の常に更新されるオープン ソース リポジトリの決定的なデータベースと照合して、オープン ソース コンポーネントのセキュリティ、ライセンス、品質をチェックします。Azure DevOps と WhiteSource Bolt の統合により、次のことが可能になります。

OWASP ZAP
https://www.shadan-kun.com/blog/measure/vulnerability/2961/

変数グループを使用して、制御したい値を保存し、複数のパイプライン間で利用できるようにします。

Slack を使用して Azure DevOps のサービス フックを作成し、完了したビルド、コード変更、プル リクエスト、リリース、作業項目の変更など、Azure DevOps 組織内のイベントに応じてメッセージを Slack に投稿します。注: 1. プロジェクトのサービス フック ページに移動します: https://{orgName}/{project_name}/_settings/serviceHooks [サブスクリプションの作成] を選択します。2. Slack チャネルに表示するイベントの種類を選択します。3. 作成した Slack 統合から Web フック URL を貼り付け、[完了] を選択します。4. 設定したイベントがプロジェクトで発生すると、チームの Slack チャネルに通知が表示されます。

場合によっては、ブランチ ポリシーが満たされていない場合でも、変更をブランチに直接プッシュしたり、プル リクエストを完了したりできるように、ポリシー要件をバイパスする必要があります。このような状況では、前のリストから必要な権限をユーザーまたはグループに付与します。この権限の範囲をプロジェクト全体、リポジトリ、または単一のブランチに設定できます。この権限を他の Git 権限と一緒に管理します。

• 各チーム内で、ユーザーはさまざまなチャネルを作成して、トピックごとにコミュニケーションを整理できます。各チャネルには数人のユーザーを含めることも、数千のユーザーに拡張することもできます。* Microsoft Teams は、Android、iOS、Mac、Windows のシステムおよびデバイスで動作します。Chrome、Firefox、Internet Explorer 11、および Microsoft Edge Web ブラウザでも動作します * Microsoft Teams のゲスト アクセス機能を使用すると、ユーザーはメッセージング、会議、ファイル共有のための内部チャネルに組織外のユーザーを招待できます。この機能は、企業間のプロジェクト管理を容易にするのに役立ちます。* Teams は Azure DevOps と統合されます 注: Slack も正解ですが、ここでは選択肢になりません

「Exploratory Testing」拡張機能は「Test & Feedback」となり、一般利用可能になりました。誰でも、Windows、Mac、Linux などのプラットフォーム上のブラウザから直接、Web アプリをテストしてフィードバックを送信できるようになりました。現在、Google Chrome および Mozilla Firefox (バージョン 50.0 以降が必要) で利用できます。Microsoft Edge のサポートは進行中であり、Edge が Chromium 互換の Web プラットフォームに移行すると有効になる予定です。

スマート検出は、Web アプリケーションの潜在的なパフォーマンス上の問題や障害の異常を自動的に警告します。アプリが Application Insights に送信するテレメトリのプロアクティブな分析を実行します。障害率が突然上昇した場合、またはクライアントまたはサーバーのパフォーマンスに異常なパターンが発生した場合は、アラートが表示されます。

Jenkins を使用して、Azure DevOps Services と TFS のサービス フックを作成できます。

セキュア開発ライフサイクル (SDL) ガイドラインでは、チームが開発サイクルの実装フェーズ中に静的分析を実行することを推奨しています。注: 企業は、プロジェクトの計画段階から実装段階までのソフトウェアの品質を評価するために、DevOps テストの実装に特に重点を置く必要があります。

パーソナル アクセス トークン (PAT) を使用すると、ユーザー名とパスワードを直接使用せずに、Azure DevOps および Team Foundation Server (TFS) にアクセスできるようになります。

SonarCloud は、SonarSource が提供する SonarQube をベースとしたクラウド サービスです。SonarQube は、ソース コードの品質を継続的に検査し、20 を超える異なる言語でバグ、脆弱性、コードの匂いを検出するために広く採用されているオープン ソース プラットフォームです。注: SonarCloud Azure DevOps 拡張機能は、SonarCloud でプロジェクトを迅速に分析するために必要なものすべてを提供します。

PAT は、Azure Pipelines および TFS 2017 以降でのみサポートされます。PAT を選択した後、作成した PAT トークンをコマンド プロンプト ウィンドウに貼り付けます。Azure DevOps サーバーまたは TFS インスタンスとエージェント マシンが信頼されたドメインにない場合は、パーソナル アクセス トークン (PAT) を使用します。PAT 認証は、ドメイン コントローラーではなく、Azure DevOps サーバーまたは TFS インスタンスによって処理されます。

アドホックまたは開発プロビジョニング プロファイルで署名された iOS アプリをリリースする場合は、リリースをコンパイルする前にテスターのデバイス ID (UDID) を取得し、プロビジョニング プロファイルに追加する必要があります。配布グループの [デバイスを自動的に管理する] 設定を有効にすると、App Center は前述の操作を自動化し、手動タスクを実行するための制約を解除します。ワークフローを自動化する一環として、Apple ID のユーザー名とパスワード、および実稼働証明書を .p12 形式で指定する必要があります。新しいリリースを配布するか、テスターの 1 人が新しいデバイスを登録すると、App Center は自動化タスクを開始します。まず、Apple ID を使用して、ターゲット配布グループのすべてのデバイスが登録されます。開発者ポータルでは、アプリで使用されるすべてのプロビジョニング プロファイルが新規と既存の両方のデバイス ID で生成されます。その後、新しく生成されたプロビジョニング プロファイルが App Center サーバーにダウンロードされます。

SonarQube(ソナーキューブ)とは、コード内の「バグ発見」「脆弱性発見」「メンテナンス困難なコード検出」などをサポートする自動コードレビューツールです。すべての開発者がよりクリーンで安全なコードを作成できるように、既存のCI/CDワークフローと統合して、プロジェクトブランチとプルリクエスト全体で継続的なコードインスペクションが可能となります。

Octopus Deploy は、ASP.NET Web アプリケーション、Java アプリケーション、NodeJS アプリケーション、およびカスタム スクリプトの複数の環境への展開を簡単に自動化できる自動展開サーバーです。

一般的な劣化

スマート検出 – パフォーマンスの異常

スマート検出 – 障害の異常

LOBとは、企業が業務処理に必要とする主要な機能を行うアプリケーションの総称である。 LOBに該当する主なアプリケーションとしては、会計や在庫管理、受発注システム、サプライ・チェーン・マネジメント（SCM）などがある。 一般的にはサーバー上で動作し、データベースやデータベース管理システムなどと連携している。

次の機能を使用できます。

一般的な劣化

スマート検出 – パフォーマンスの異常

スマート検出 – 障害の異常

スマート検出は、Web アプリケーションの潜在的な障害の異常やパフォーマンスの問題を自動的に通知する Azure Application Insights の機能です。アプリが Application Insights に送信するテレメトリを積極的に分析します。障害率が上昇したり、クライアントまたはサーバーのパフォーマンスに異常なパターンが発生したりすると、アラートが表示されます。

以下は、Azure Automation PowerShell DSC で使用できない共有リソースです。

MOFファイル

ワークフロー

Webhook

DSC 構成は、ノードに適用する前に、まず管理対象オブジェクト フォーマット (MOF) ファイルにコンパイルする必要があります。MOF ファイルは、Runbook に関連付けることができる共有リソースではありません。

ポリシー定義をテストにはRESTAPIを使うと便利

プロジェクト設定でエージェント プールを選択すると、プロジェクト内のすべての並列ジョブとキューに入れられたジョブを識別できるためです。

ここで識別できるのは実行中の並列ジョブのみで、キューに入れられたジョブは識別できないためです。

Service Health を使用して、それぞれのリージョンの Azure サービスの正常性を追跡するダッシュボードを作成します。

Service Health が追跡する正常性イベントのタイプは次のうちどれですか? （4つお選びください。

サービスの問題

計画的なメンテナンス

健康に関する勧告

セキュリティ勧告

Azure テスト プランから自動テストを実行するには、次のアクセス許可が必要です。

導入の管理

リリースの管理

リリースの作成

リリースステージを編集する

コンテナー グループを作成するときは、再起動ポリシーを指定する必要があります。Azure には 3 つの既定の再起動ポリシーがあり、それらは次のとおりです。

Always : これは、再起動ポリシーが適用されていない場合にコンテナー グループに適用されるポリシーです。Always に設定すると、このコンテナー グループ内のコンテナーは常に再起動されます。

OnFailure : このグループのコンテナーは、プロセスが失敗した場合にのみ再起動されます。

Never : このコンテナー グループ内のコンテナーは再起動されません。

App Center で診断が有効になっている場合、アプリケーションのログとクラッシュ レポートが自動的に生成されます。アプリに対する App Center の診断を有効にするには、App Center SDK をアプリに統合する必要があります。

Azure Monitor を使用すると、Azure 上のアプリケーションとサーバー、およびオンプレミス インフラストラクチャを監視できます。これは、Application Insights と統合され、アプリケーション全体や依存関係などの問題を検出および診断する Microsoft のネイティブ監視ソリューションです。

Azure Policy を選択することになります。Azure Policy を使用すると、ポリシーを作成して割り当てることができます。Azure Policy には、使用できる既存のポリシーもあります。ポリシーを割り当てると、新しいリソースがポリシーに準拠していることが確認され、ポリシーに準拠していないリソースが特定されます。このシナリオでは、ポリシーはすでに存在しており、以下の図に表示されています。

Black Duck は、組織がアプリケーションとコンテナのポートフォリオ全体でオープンソースのセキュリティ、ライセンス コンプライアンス、コード品質のリスクを特定し、軽減するのに役立ちます。

Azure Service Health を使用した計画メンテナンス アラートの作成

1. Azure portal にログインし、[Service Health] を選択します。
2. 右側のウィンドウの上部から [ヘルス アラート] を選択し、続いて [+ サービス ヘルス アラートの作成] を選択します。
3. [アラートの編集] ブレードで、アラートに名前と説明を入力し、サブスクリプションが正しいことを確認して、リソース グループを選択します。
4. 次のステップでは、「基準」セクションで、監視するサービス、リージョン、およびイベント アラートの種類を選択します。この記事の目的上、すべてのサービスとリージョンがチェックされていますが、計画されているメンテナンス イベントのみがチェックされています。
5. アクション グループを選択または作成します。(アクション グループは、イベントが記録される場合に実行されるアクションのグループです。)
6. 実行されるアクションを構成します。ここでは電子メール アラートのみを設定しているため、最初にアクションに名前を付けてから、ドロップダウン リストから [電子メール/SMS/プッシュ/音声] を選択します。
   注: Azure Service Health を使用すると、クラウド サービスに影響を与える可能性がある Azure サービスの問題を表示できます。サービスの正常性では、次の 3 種類の正常性イベントが監視されます。
   サービスの問題 現在問題が発生している Azure サービス
   計画されたメンテナンス サービスの可用性に影響を与える可能性がある将来の既知のメンテナンス
   正常性に関する勧告 サービスの変更 (非推奨の機能やクォータ使用量の超過など)。

ビルド パイプラインでコード カバレッジ結果の発行タスクを使用して、Cobertura または JaCoCo 形式のビルドによって生成されたコード カバレッジ結果を Azure Pipelines または TFS に発行します。

Azure portal の App Configuration 用の機能マネージャーは、アプリケーションで使用する機能フラグを作成および管理するための UI を提供します。App Configuration には次の利点があります。 ✑ 数分でセットアップできるフルマネージド サービス ✑ 柔軟なキー表現とマッピング ✑ ラベルによるタグ付け ✑ 設定のポイントインタイム再生 ✑ 機能フラグ管理用の専用 UI ✑ 2 つのセットの比較Azure マネージド ID によるセキュリティの強化 ✑ 保存中および転送中の機密情報の暗号化 ✑ 一般的なフレームワークとのネイティブ統合 App Configuration は、アプリケーション シークレットの保存に使用される Azure Key Vault を補完します。

OWASP ZAP はセキュリティ問題に特化しており、SQL インジェクションやクロスサイト スクリプティングなどの脆弱性を検出するため、これを選択することはありません。

Octopus Deploy は、ASP.NET Web アプリケーション、Java アプリケーション、NodeJS アプリケーション、およびカスタム スクリプトの複数の環境への展開を簡単に自動化できる自動展開サーバーです。Octopus は、Windows、Mac、Linux などのさまざまなプラットフォームにインストールできます。VSTS や GIT など、ほとんどのバージョン管理ツールと統合することもできます。Windows サーバーにソフトウェアを展開する場合、Windows サーバーが Octopus サーバーと通信できるように、軽量のエージェント サービスである Tentacle を Windows サーバーにインストールする必要があります。導入プロセスを定義する場合、最も一般的なステップ タイプはパッケージ ステップです。このステップでは、パッケージ化されたアプリケーションを 1 つ以上のデプロイメント ターゲットにデプロイします。パッケージをデプロイするときは、パッケージをデプロイするマシンの役割を選択する必要があります。

カンバン ボード上でユーザー ストーリーとバグを作成して追跡

アジャイル

カンバン ボード上の製品バックログ項目を追跡したい場合は、プロジェクトの作成時に作業項目プロセスとしてスクラムを選択できます。

この要件に対する CMMI 作業項目プロセスに基づいてプロジェクトを作成できます。

作業が開始されてから作業項目を閉じるまでにかかった時間を追跡する
サイクルタイム

作業項目が作成されてから閉じるまでにかかった時間を追跡する
リードタイム

Azure Repos で通知を取得するために Slack 内で実行する必要がある特定のコマンドの 1 つは、/azrepos subscribe であり、リポジトリ URL を指定します。

リポジトリのデータ サイズを削減

git plune

掃除コマンド

メイン ブランチのコミット履歴を削減したい場合は、スカッシュ マージ手法の使用を検討する必要があります。

You need to use the @azure pipelines subscribe command. And then you can use the build definition to the command.

変数グループを使用して、Azure Key Vault からシークレットを参照できます。

このツールを使用すると、Java ベースのアプリケーションのテストによってアクセスされるコードの割合を計算できます。

Cobertura ツールの詳細については、以下の URL を参照してください。

https://cobertura.github.io/cobertura/

mend Boldとは
旧ホワイトソース

合格しました。