Azure DevOps Server

Azure DevOps Server  と Visual Studio Team System ) は、製品のバージョン管理をレポーティング、要件管理、プロジェクト管理、自動ビルド、テスト、リリース管理機能を提供する、マイクロソフトの統合開発環境のサーバ製品。アプリケーションライフサイクル管理全体をカバーし、DevOps機能を利用できる。Azure DevOpsは、多数の統合開発環境のバックエンドとして使用できるが、すべてのプラットフォームのMicrosoft Visual StudioおよびEclipse用に調整されている。

1. オンプレミスとオンライン
---------------

Azure DevOpsは、オンプレミスとオンラインの2つの異なる形式で利用できる。

1.1. Azure DevOps Services
--------------------------

Azure DevOps Servicesクラウドサービスは、Microsoft Azureクラウドプラットフォーム上に構築されている。オンプレミスバージョンのAzure DevOpsと同じコードを少し変更して使用し、最新の機能を実装している。Azure DevOpsはセットアップを必要としない。ユーザーがマイクロソフトアカウントでサインインする環境をセットアップし、プロジェクトを作成して、チームメンバーを追加することができる。短い開発サイクルで開発された新機能は、最初にクラウドバージョンに追加される。これらの機能は、約3か月間隔で、更新としてオンプレミスバージョンに実装される。

1.2. Azure DevOps Server Express
--------------------------------

無料版でありながら、Azure DevOps Serverの主要機能はそのまま使うことができる一方、5人以下でのみ利用可能 、シングルサーバ限定、SQL Server Expressのみ対応、TFS Proxyのサポートなし、SharePoint統合利用不可、といった制限事項がある「Azure DevOps Server Express」は、以下のバージョンで提供されている。

Azure DevOps Server Express 2019

2. アーキテクチャ
----------

2.1. サーバ アーキテクチャ
----------------

Azure DevOpsは、多層のスケーラブルなアーキテクチャ上に構築されている。一次構造は、ロジックの処理とWebアプリケーションポータルの保守を担当するアプリケーション層で構成される。Azure DevOpsは、Windows Communication Foundation Webサービスを使用して構築されている。クライアントオブジェクトモデルが推奨されるが、これらはどのクライアントでも使用できる。データ層とアプリケーション層は同じマシン上に共存できる。

スケーラビリティをサポートするために、アプリケーション層の負荷を分散し、データ層をクラスター化することができる。Microsoft SQL Server 2012以降を使用している場合は、AlwaysOn SQL Serverフェールオーバークラスターと可用性グループがサポートされており、データの地理的な複製が可能となる。プライマリコンテナはプロジェクトコレクションである。プロジェクトコレクションは、チームプロジェクトのグループを含むデータベースである。プロジェクトコレクションは、各コレクションを異なるSQL ServerまたはSQL Serverインスタンスに配置できるという点で、別のスケーラビリティメカニズムである。Azure DevOpsインスタンスごとの「Oe」構成データベースには、プロジェクトコレクションのメタデータが格納される。プロジェクトコレクションデータベースのデータはウェアハウスデータベースに集約され、Analysis Servicesキューブにロードする準備としてデータが非正規化される。ウェアハウスとキューブにより、複雑な傾向レポートとデータ分析が可能になる。

Azure DevOpsは、既存のSharePointファームと統合できる。SQL Server Reporting Servicesは、データウェアハウスまたはAnalysis Servicesデータキューブに対するより高度なレポートでサポートされている。これらのインストールは、同じシステムまたは異なるシステムに行うことができる。ビルドサーバー、ラボ管理サーバー、リリース管理サーバー、プロキシサーバー、テストマシン、負荷テストマシンもインフラストラクチャに追加できる。エンタープライズプロジェクトのスケジューリングを必要とするチームをサポートするために、Azure Dev OpsはMicrosoft Project Serverとも統合されており、エンタープライズレベルのポートフォリオ管理、リソース管理、およびプロジェクト追跡が可能である。

2.2. 拡張性
--------

マイクロソフトは、Azure DevOpsに接続するための2つのスタンドアロンの再配布APIを提供している。一つは、 Java SDK、もうひとつは.NET Framework SDKである。これらのAPIにより、Azure DevOpsへのクライアント接続が可能となる。Azure DevOpsはサービス指向アーキテクチャで記述されているため、Webサービスを呼び出すことができるほぼすべてのツールと通信できる。もう1つの拡張可能なメカニズムは、システムアラートの購読である。たとえば、作業項目が変更された、またはビルドが完了したことをアラートする。事前構成されたアラートは約20あり、チームは必要な数の追加アラートを構成できる。拡張可能なシナリオで使用すると、これらのアラートをWebサービスに送信して、作業項目を変更または更新するアクションをトリガーできる。

データウェアハウスは、カスタムデータウェアハウスアダプターを作成することで拡張することもできる。Web Access Extensionsと呼ばれるTeam Web Access用のカスタムアドインを作成することもできる。

2.3. クライアント
-----------

Azure DevOpsは、Visual Studio 2010以降、Microsoft Test Manager2012および2013をサポートする。Eclipse、古いバージョンのVisual Studio、およびその他の環境は、Microsoft Source Code Control Integration Providerを使用してAzure DevOpsにプラグインできる。。これらのツールは、Azure DevOpsの機能へのフルアクセスを提供する。

Microsoft ExcelやMicrosoft Projectもサポートされており、作業項目の一括更新、一括入力、および一括エクスポートを可能にする作業項目の管理に役立つ。Microsoft Projectを使用して、ウォーターフォールソフトウェア開発方法論に準拠する際の作業をスケジュールできる。ExcelとProjectはどちらも、データの双方向更新をサポートする。これにより、たとえば、プロジェクトマネージャーがプロジェクトにスケジュールを設定し、その作業をAzure DevOpsにインポートして、開発者が作業を更新すると、プロジェクトマネージャーが追加の作業を実行しなくてもスケジュールを更新できる。

Microsoft PowerPointもAzure DevOpsと統合されており、要件管理プロセスを支援するための迅速なストーリーボード開発が可能である。この統合により、PowerPointの組み込み関数でアニメーション化できる、あらゆるタイプのインターフェイスモックアップを構築するために使用できる拡張可能なストーリーボードシェイプが提供される。これらのストーリーボードは、作業項目にリンクできる。

チームの地理的な分散の拡大に対処し、プロセスの早い段階でより頻繁に利害関係者を関与させるために、マイクロソフトはフィードバッククライアントを追加した。このツールを使用すると、ユーザーはアプリケーションを実行し、表示されているものにオーディオとビデオで注釈を付け、画面をキャプチャし、開発チームにコンテキストフィードバックを提供できる。これにより、会議やデモンストレーションセッションを必要とせずに、ユーザーの観点からアプリケーションの機能に関する特定のフィードバックが提供される。Azure DevOpsは、Unix環境とWindows環境の両方に対応するコマンドラインツールも提供する。Power Toolsには、ユーザーがファイルまたはフォルダーを右クリックして、ファイルのチェックインとチェックアウト、ファイルの追加、およびその他の基本的なタスクを実行できるWindowsシェル統合が含まれている。

3. 主要機能
-------

3.1. 作業項目
---------

Azure DevOpsの中核機能は「作業項目」である。作業項目は物事を表す。それは、達成する必要のある作業、追跡するリスク、テストケース、バグなどである。作業項目はXMLドキュメントを介して定義され、高度に拡張可能となっている。 作業項目は、開発フレームワークを提供するために、これらおよびその他の情報を含むプロセステンプレートに結合される。Azure DevOpsには、アジャイル、スクラム、CMMI向けMicrosoft Solutions Frameworkのプロセステンプレートが含まれている。チームは、組み込みのテンプレートを使用するか、サードパーティによって作成された使用可能な多くのテンプレートの1つを使用するかを選択できる。プロセステンプレートは、電動工具の一部であるプロセステンプレートエディタを使用してカスタマイズできる。

さまざまな関係を使用して作業項目を相互にリンクし、作業項目の階層ツリーまたは作業項目間のフラットな関係を作成できる。作業項目は、Webページ、ファイル共有上のドキュメント、SharePointなどの別のリポジトリに保存されているドキュメントなどの外部アーティファクトにリンクすることもできる。作業項目は、ソースコード、ビルド結果、テスト結果、およびソース管理内の項目の特定のバージョンにリンクすることもできる。

作業項目システムの柔軟性により、Azure DevOpsは、要件管理からバグ追跡、リスクと問題の追跡、レビューの結果の記録まで、多くの役割を果たすことができる。拡張可能なリンク機能により、要件からソースコード、テストケースおよび結果までのトレーサビリティを実現し、監査目的および変更の履歴理解のためにレポートすることができる。

3.2. ソース管理
----------

Azure DevOpsは、2つの異なる種類のソース管理をサポートする。

3.2.1. Team Foundation Version Control
--------------------------------------

TFVC}}TFVCは、チームがリポジトリ内にあらゆるタイプのアーティファクトを保存できるようにする一元化されたバージョン管理システムである。TFVCは、クライアントツールを操作するときに、サーバーワークスペースとローカルワークスペースの2種類のワークスペースをサポートする。サーバーワークスペースを使用すると、開発者はチェックアウトのためにファイルをロックし、ファイルが編集されていることを他の開発者に通知できる。このモデルでよくある不満は、開発マシン上のファイルが読み取り専用としてマークされていることである。また、サーバーに接続できない場合は、開発者が「オフラインにする」必要がある。ローカルワークスペースは、これらの問題を回避するように設計されている。ローカルワークスペースのシナリオでは、ファイルは読み取り専用ではなく、作業する前にチェックアウトする必要はない。ファイルが開発者のローカルマシン上にある限り、サーバーが接続されているかどうかは関係ない。競合はチェックイン時に処理される。

リモートクライアントのパフォーマンスを向上させるために、Azure DevOpsにはプロキシサーバーをインストールする機能が含まれている。プロキシサーバーを使用すると、ソース管理コンテンツを開発者に近いサイトにキャッシュして、長いネットワークトリップとそれに関連する遅延を回避できる。チェックインは引き続きAzure DevOpsアプリケーション層に対して直接実行されるため、プロキシサーバーは読み取りシナリオで最も効果的である。

ソース管理エンジンの一部として、Azure DevOpsは、開発者がチェックインされるコードが構成可能なルールに従っていることを確認するのに役立つ多くの機能をサポートしている。このルールエンジンは、チェックインポリシーと呼ばれる。開発者がチェックインコメントを入力しない限りチェックインを許可しないチェンジセットコメントポリシーなど、すぐに使用できるポリシーがいくつかあります。これらのポリシーは拡張可能であり、チェックインされているコード、コメント、および関連する作業項目のすべての側面を調べるために使用できる。Azure DevOpsは、独立して使用するとFxCopと呼ばれるコード分析機能もサポートする。Azure DevOpsに含まれているということは、サーバーにチェックインされたコードに対して、自動ビルド中に分析を実行できることを意味する。

Visual Studio CodeのAzure Repos拡張機能は、TFVCをサポートしている。

3.2.2. Git
----------

Azure DevOpsではGitもネイティブサポートしている。これはマイクロソフト固有の実装ではなく、libgit2ライブラリに基づく標準の実装である。これは、人気のあるGitHubを強化するのと同じライブラリであり、コードはGitHubから無料で入手できる。マイクロソフトは標準ライブラリを使用するアプローチを採用したため、任意のGitクライアントをAzure DevOpsでネイティブに使用できるようになっている。これにより、Gitをサポートする任意のプラットフォームおよび任意のIDE上のツールがAzure DevOpsに接続できるようになる。例えば、両方のXcodeとAndroid StudioのメーカーGitプラグインをサポートする。さらに、開発者がEclipse用のTeam Explorer Everywhereプラグインを使用したくない場合は、eGit を使用してAzure DevOpsに接続することを選択できる。

Gitを使用しても、Azure DevOpsワークアイテムまたはビルドシステムを使用するメリットが損なわれることはない。Gitでコードをチェックインするときに、チェックインコメントでワークアイテムIDを参照すると、チェックインが指定されたワークアイテムに関連付けられる。同様に、Team BuildもGitプロジェクトをビルドする。

Azure DevOpsをGitリポジトリとして使用する主な理由の1つは、SQL Serverに支えられており、Team Foundationバージョン管理と同じ保護が提供されていることである。これにより、開発者は、プロジェクトのタイプと自分に最適なワークスタイルを選択する際にいくつかの選択肢が得られる。

3.3. レポーティング
------------

レポーティングは、2005年の最初のリリース以来、Azure DevOpsの中核コンポーネントです。レポーティングインフラストラクチャは、関係データベースであるデータウェアハウスとSQL Server Analysis Servicesデータキューブで構成されている。このオプションがインストールされている場合、これらのソースは両方ともSQL Server Reporting Servicesを介したレポートに使用できる。これらは標準のデータベースおよびキューブ構造であるため、これらのデータソースを指すことができる任意のツールがそれらからレポートできる。これには、Cognos、Tableau、Excel、その他のレポートツールなどのツールが含まれる。すぐに使用できる各プロセステンプレートには、ビルド情報、テスト結果と進捗状況、プロジェクト管理、アジャイルレポート、バグと問題のデータをカバーするレポートサービスの一連のレポートが含まれる。SSRSのレポートビルダーを使用して新しいレポートを作成でき、既存のレポートを変更できる。

負荷テストの結果については、より専門的なレポートを利用できる。このデータはVisual Studio内で直接利用でき、詳細な分析のためにExcelにエクスポートできる。

「軽量レポート」と呼ばれる機能は、クエリ結果に基づいて、ウェアハウスやキューブに依存しないリアルタイムレポートを作成する機能を提供する。

3.4. チームビルド
-----------

Team Buildは、Team Foundation Serverに含まれているビルドサーバーアプリケーションである。Team Buildは、MSBuildとWindows Workflow Foundationの2つのコンポーネントで構成されている。MSBuildのはApache Antと同様に宣言型のXML言語である。WFは、TFS2010以降のビルドプロセスに追加された。それ以前は、MSBuildのみが利用可能であった。ビルド機能は、Azure DevOpsの後続のリリースごとに進化し続けています。TFS 2010および2012では、WFテンプレートファイルはソース管理に保存され、ソース管理から直接編集およびバージョン管理できる。TFS 2013では、これらのファイルが削除され、煩雑さが解消され、ビルドプロセスが合理化された。WFテンプレートは、必要に応じてダウンロード、編集、およびソース管理に保存できる。TFS2013は、既存のTFS2010または2012ビルドプロセステンプレートを壊さずに扱うことができる。TFS 2013でのGitのサポートにより、Team Buildが拡張され、GitプロジェクトとTFVCプロジェクトの自動構築が可能になった。

Windows Workflowは、ビルドプロセスの全体的なフローを制御し、Azure DevOpsには、ビルド中に実行される一般的なタスクを管理するための多くのビルド済みワークフローアクティビティが含まれる。MSBuildは、.projファイルにあるマークアップ言語である。ビルドシステムは拡張可能であり、ユーザーは独自のワークフローアクティビティを作成でき、MSBuildをプロセスに挿入し、外部プロセスを実行できる。ビルドのワークフローの性質により、無制限の柔軟性が可能になるが、その柔軟性を実現するには多少の作業が必要になる場合がある。チームビルドの機能を強化して、コミュニティ開発者がアクティビティを構築できるように、オープンソースプロジェクトが開始された。

ビルドプロセスは、スケジュールされたビルド、継続的インテグレーション、ゲートチェックイン、ローリングビルドなど、さまざまなタイプのビルド用に構成できる。ゲートチェックインビルドは、開発者がチェックインするコードを棚上げし、サーバーコードで「最新情報を取得」して、ビルドを実行する。ビルドが成功すると、コードを送信した開発者に代わってコードがチェックインされる。ビルドが失敗した場合、開発者に通知され、別のチェックインを試みる前にコードを修正できる。

ビルドには保持ポリシーがあり、不要なときに蓄積されないようにしたり、ビルド出力をロックして永久に保存することができる。TFS 2013の新機能は、ビルド結果をソース管理にチェックインする機能である。これは、ビルドを配置するためのドロップ場所がないAzure DevOps Servicesでの自動ビルドをサポートするために必要な拡張機能であった。オンプレミスバージョンでは、ビルド出力は、アクセス可能な共有フォルダーの場所に配置されるように構成できる。

Azure DevOpsのビルドプロセスは、Team BuildがAzure DevOpsで作成および保存されるアーティファクトの多くをまとめるというトレーサビリティメカニズムの一部でもある。開発者がチェックイン時にソースコードを作業項目に関連付けると仮定すると、チームビルドには、各ビルドの変更をレポートする機能がある。ソースコードの変更と作業項目の変更の両方、およびテスト結果、機能テストの結果などである。バグやプロダクトバックログ が解決されてビルドに統合されると、これらのアーティファクトを追跡する作業項目が自動的に更新され、どのビルドで正常に統合されたかが示される。テスターは、テストツールと組み合わせて、各ビルドで変更されたコードだけでなく、ビルドごとに変更されたバグ、PBI、その他の作業の統合ビューを取得する。

当初、TFS2015とVisual Studio Team Servicesを使用して、マイクロソフトは、クロスプラットフォーム対応のNode.jsアプリケーションに基づくビルドエンジンのアーキテクチャを再発明した。現在、Windows、Mac、およびLinuxビルドエージェントがサポートされている。Azure DevOpsは、Microsoft Azureのビルドホスティングを介して柔軟なビルド機能を提供する。

3.5. リリース管理
-----------

2013年半ば、マイクロソフトはInCycle SoftwareからInReleaseという製品を購入した。 InReleaseは、Team Foundation Server 2013に完全に組み込まれた。この機能は、真の継続的デプロイソリューションを可能にすることで、自動化されたビルドおよびテストプロセスを補完した。ツールはTFS2013の「リリース管理」に名称変更された。リリース管理機能により、チームは、開発、テスト、および本番環境への制御されたワークフロー主導のリリースを実行でき、1つ以上のリリースの進行状況を監視するダッシュボードが提供される。

マイクロソフトは、Visual Studio Team Servicesのリリース管理とオンプレミスバージョンのTFSを再構築し、2015 Update 2の新しい変更を加えた。新しいバージョンのリリース管理は、クライアントとしてWebブラウザーを活用し、Team Foundation Buildと同じエージェントアーキテクチャに依存している。 リリース管理により、Azure DevOpsのDevOps機能を活用することができる。

4. バージョン履歴
----------



5. 関連項目
-------

バージョン管理システム
バージョン管理システムの一覧
Team Foundation Server
Visual Studio Application Lifecycle Management
Microsoft Visual SourceSafe 
SVNBridge, a Windows client or server side extension to TFS that allows access to TFS revision controlled items from Subversion client applications.

6. 脚注
-----

7. 外部リンク
--------

[1]