説明
* 各チーム内で、ユーザーはさまざまなチャネルを作成して、トピックごとにコミュニケーションを整理できます。各チャネルには、数人のユーザーを含めることも、数千のユーザーに拡張することもできます。
* Microsoft Teams は、Android、iOS、Mac、および Windows のシステムとデバイスで動作します。また、Chrome、Firefox、Internet Explorer 11、および Microsoft Edge Web ブラウザーでも動作します。
* Microsoft Teams のゲスト アクセス機能により、ユーザーは組織外の人を招待して、メッセージング、会議、およびファイル共有のために内部チャネルに参加させることができます。この機能は、企業間のプロジェクト管理を容易にするのに役立ちます。
* Teams は Azure DevOps と統合されています。
参照: https://searchunifiedcommunications.techtarget.com/definition/Microsoft-Teams
トピック 1、ケース スタディ: 1概要
既存の環境
Litware, Inc. 独立系ソフトウェア ベンダー (ISV) Litware には、本社と 5 つの支社があります。
アプリケーション アーキテクチャ
同社の主なアプリケーションは、V8.NET で記述されたロジックを使用する ASP.NE T Web フォームに基づく単一のモノリシックな退職金管理システムです。アプリケーションのいくつかの新しいセクションは、C# で記述されています。
アプリケーションのバリエーションは、個々の顧客向けに作成されます。現在、アプリケーションのコード ベースには 80 以上のコード ブランチがあります。
アプリケーションは、Microsoft Visual Studio を使用して開発されました。ソース コードは、本社の Team Foundation Server (TFS) に格納されています。ブランチ オフィスは、TFS プロキシ サーバーを使用してソース コードにアクセスします。
アーキテクチャの問題
Litware は、顧客向けの新しいコードの作成に重点を置いています。既存のコードをリファクタリングまたは削除するためのリソースは提供されません。コード ベースの変更には長い時間がかかります。AS の依存関係は、個々の開発者には明らかではありません。
コードのマージ操作には数か月かかることが多く、多くの開発者が関与します。コードのマージにより、見つけて解決するのが難しいバグが頻繁に発生します。
顧客は、退職金管理システムの所有コストが継続的に増加していると報告しています。無関係なコードをマージする必要があるため、小さなコードの変更でもコストがかかります。
要件
変更予定
Litware は、投資計画のための新しいアプリケーション スイートの開発を計画しています。投資計画アプリケーションは、イースティング退職基金管理システムとのわずかな統合のみを必要とします。
投資計画アプリケーション スイートには、1 つの多層 Web アプリケーションと 2 つの iOS モバイル アプリケーションが含まれます。従業員は 1 つのモバイル アプリケーションを使用します。もう 1 つは顧客が使用します。
Litware は、よりアジャイルな開発手法への移行を計画しています。共有コードは、一連のパッケージに抽出されます。
Litware は社内のクラウド変革プロセスを開始しており、適切な場合はいつでもクラウド ベースのサービスを使用する予定です。
Litware は、常に顧客からのバグ レポートを無視するのではなく、障害を検出することでプロアクティブになりたいと考えています。
技術要件
企業の投資計画アプリケーション スイートは、次の技術要件を満たす必要があります。
* ファイアウォールを通過する新しい着信接続を最小限に抑える必要があります。
* Developers という名前のグループのメンバーは、パッケージをインストールできる必要があります。
* すべてのアクセス許可の割り当てには、最小特権の原則を使用する必要があります
* 新しい機能を分離して開発することをサポートする分岐戦略を使用する必要があります。
* チーム リーダーという名前のグループのメンバーは、新しいパッケージを作成し、パッケージ フィードの権限を編集できる必要があります。
* Visual Studio App Center を使用して、モバイル アプリケーションのクラッシュと使用中のデバイス タイプのレポートを一元化する必要があります。
* デフォルトでは、すべての App Center を使用して、モバイル アプリケーションのクラッシュと使用中のデバイス タイプのレポートを一元化する必要があります。
* コードの品質とリリースの品質は非常に重要です。リリース中にアクティブなバグがログに記録されている場合、リリース中に展開をステージ間で進めてはなりません。
* モバイル アプリケーションは、既存の退職金管理システムの株価サービスを呼び出すことができる必要があります。システムがアップグレードされるまで、サービスは HUPS を介した基本認証のみをサポートします。
* テスト サーバーに必要なオペレーティング システムの構成は、毎週変更されます。Azure Automation State Configuration を使用して、サーバーが定期的に作成およびチェックされるときに、各テスト サーバーのオペレーティング システムが同じように構成されていることを確認する必要があります。
現在の技術
テスト サーバーは、最初のデプロイ時には正しく構成されていますが、時間の経過とともに構成のドリフトが発生します。Azure Automation State Configuration は、構成の修正に失敗します。
Azure Automation State Configuration ノードは、次のコマンドを使用して登録されます。

ボックス 1: チェックイン ポリシー
Team Foundation バージョン管理の管理者は、チェックイン ポリシー要件を追加できます。これらのチェックイン ポリシーでは、ユーザーがソース管理へのチェックインを実行するときにアクションを実行する必要があります。
デフォルトでは、次のチェックイン ポリシー タイプを使用できます。
* ビルド チェックイン前に最後のビルドが成功している必要があります。
* コード分析 チェックイン前にコード分析を実行する必要があります。
* 作業項目 チェックインに関連付けられた 1 つ以上の作業項目が必要です。
ボックス 2: ポリシーの構築
参照：
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/add-check-policies
https://azuredevopslabs.com/labs/vstsextend/sonarcloud/

フィードには、所有者、投稿者、共同編集者、閲覧者の 4 つのアクセス レベルがあります。所有者は、あらゆる種類の ID (個人、チーム、およびグループ) をあらゆるアクセス レベルに追加できます。

参照：
https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions

Azure Artifacts では、パッケージへのアクセスを整理および制御するために使用できる複数のフィードの概念が導入されています。
Azure Artifacts でホストするパッケージは、フィードに格納されます。フィードにアクセス許可を設定すると、シナリオで必要な数のユーザーとパッケージを共有できます。
フィードには、所有者、投稿者、共同編集者、閲覧者の 4 つのアクセス レベルがあります。
参考文献:
https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions?view=vsts&tabs=new-nav