Visual Studio Team Services の最新情報: 2018 年 4 月のまとめ
執筆者: Buck Hodges (Director of Engineering, VS Team Services)
このポストは、2018 年 4 月 25 日に投稿された What’s brewing in Visual Studio Team Services: April 2018 Digest の翻訳です。
このブログ シリーズでは、3 週間ごとに Visual Studio Team Services (VSTS) のリリースに関する最新情報をお届けします。Visual Studio Team Services は、効率のよい継続的インテグレーションと Azure リリース パイプラインの構築に最適な DevOps ツールです。機能が大幅に増えたことで、言語やデプロイ先の OS を問わず、あらゆるアプリの Azure ワークフローのすべての分野で Team Services を効率的に活用できるようになりました。
ビルド完了トリガーを使用して関連ビルドを連結
大規模な製品の場合、複数のコンポーネントが相互に依存していますが、多くの場合、コンポーネント自体は個別に構築されています。そのため、アップストリームのコンポーネント (ライブラリなど) を変更する場合には、ダウンストリームの依存関係を再度構築して検証する必要があります。通常、このような依存関係は手動で管理されています。
このたび、ビルドの正常な完了時に別のビルドをトリガーできるようになりました。アップストリームのビルドで生成されたアーティファクトをダウンロードして、後のビルドで使用することができます。また、Build.TriggeredBy.BuildId、Build.TriggeredBy.BuildDefinitionId、Build.TriggeredBy.BuildDefinitionName の各変数からデータを取得することもできます。詳細については、ビルド トリガー (英語) に関するドキュメントをご覧ください。
この機能は、これまでで 2 番目に多く寄せられたご要望 (英語) (1,129 票) を優先的に反映したものです。
これは、単一のマルチフェーズ ビルド (英語) を使用して解決することもできますが、複数の構成設定やオプションを設定している場合や、依存するプロセスを別のチームが所有している場合などには、ビルド完了トリガーを使用するのが便利です。
YAML から CI ビルドをトリガー
YAML ビルド定義ファイルの一部として、継続的インテグレーション (CI) トリガー設定を定義できるようになりました。既定では、新しい .vsts-ci.yml ファイルを Git リポジトリにプッシュすると、すべてのブランチの CI が自動的に構成されます。
トリガーするブランチを制限したい場合には、ファイルに以下の行を追加して、マスターまたは releases/* のパターンに一致するブランチのみをトリガーするように設定します。
YAMLCopy
trigger:
- master
- releases/*
YAML ファイルのトリガーの無効化や、設定の上書きは、定義ファイルで行うことができます。
詳細については、YAML ビルド トリガー (英語) に関するドキュメントをご覧ください。
Helm を使用して Kubernetes へのデプロイを効率化
Helm (英語) は、Kubernetes アプリケーションのインストールと管理を効率化するツールで、この 1 年間で利用者やコミュニティの支持が急増しています。今回、Release の Helm タスクで、Helm Chart をパッケージ化して Azure Container Service (AKS) やその他の Kubernetes クラスターにデプロイできるようになりました。
VSTS では既に Kubernetes と Docker コンテナーをサポートしていますが、Helm タスクの追加により、Helm ベースの CI/CD パイプラインをセットアップし、コンテナーを Kubernetes クラスターに配布できるようになりました。詳細については、Kubernetes を使用した Azure Container Service へのデプロイ (英語) のドキュメントをご覧ください。
Azure Database for MySQL への継続的デプロイ
Azure のサービスとしての MySQL データベースである Azure Database for MySQL への継続的デプロイが可能になりました。バージョン管理で MySQL スクリプト ファイルを管理し、PowerShell スクリプトではなくネイティブ タスクを使用して、リリース パイプラインの中で継続的デプロイを行うことができます。
Azure DevOps Projects を使用して Go および Ruby アプリケーションを構成
Azure DevOps Projects は、Azure 上でアプリケーションを簡単に実行できるようにするサービスです。シンプルな手順でどんな Azure サービスのアプリケーションでも起動することができます。DevOps Projects には、アプリの開発、デプロイ、監視に必要なツールがすべて揃っており、Go および Ruby アプリケーションの DevOps パイプライン全体をセットアップすることができます。詳細については、Azure へのデプロイ (英語) に関するドキュメントをご覧ください。
Ruby on Rails アプリケーションをデプロイ
Azure App Service の新しいリリース定義テンプレートでは、Ruby on Rails アプリケーションの Azure WebApp on Linux へのデプロイ用タスクが追加されました。このテンプレートを使用すると、App Service Deploy タスクにインラインのデプロイメント スクリプトを追加し、Bundler (依存関係マネージャー) でアプリケーションの依存関係をインストールしておくことができます。
Go で構築されたアプリケーションをビルド
VSTS で Go アプリケーションをビルドできるようになりました。Go Tool Installer タスクは、1 つまたは複数のバージョンの Go Tool をオンザフライでインストールするもので、プロジェクトに必要な Go Tool のバージョンを取得し、ビルド エージェントのパスに追加します。ターゲットに指定したバージョンの Go Tool が既にエージェントにインストールされている場合は、ダウンロードとインストールのプロセスをスキップします。Go タスクは、依存関係のダウンロードや、アプリケーションのビルド、テストなどに役立ちます。また、任意のカスタム Go コマンドを実行することもできます。
Deployment Groups の一般提供を開始
このたび、プレビュー版で提供されていた Deployment Groups の一般提供を開始しました。これは、VSTS/TFS の Release Management の堅牢なデプロイ機能で、設定不要で複数マシンに対応しています。
複数のサーバー間でデプロイのオーケストレーションを行い、ローリング アップデートを実行すると同時に、アプリケーション全体の高可用性を確保することができます。また、オンプレミスのサーバーにも Azure または任意のクラウド上の仮想マシンにもデプロイできるほか、デプロイされたアーティファクトのバージョンをサーバー レベルまでエンドツーエンドで追跡することもできます。
エージェント ベースのデプロイ エージェントは、ビルドやリリースのエージェントと同じであるため、ターゲット マシンに対して完全なタスク カタログを使用できます。拡張性の面では、REST API を使用して、Deployment Groups (英語) や Targets (英語) にプログラムからアクセスすることができます。
エージェント ベースのデプロイ機能は、既存のビルドおよびデプロイ エージェントを使用します。Deployment Group フェーズでは、ターゲット マシンに対して完全なタスク カタログを使用できます。拡張性の面では、Deployment Groups (英語) や Targets (英語) に REST API を使用して、プログラムによるアクセスを行うことができます。
詳細については、一般提供の発表 (英語) をご覧ください。
SonarSource の最新の拡張機能でコード品質を改善
SonarSource は先日、更新版の SonarQube 拡張機能 (英語) と新しい SonarCloud 拡張機能 (英語) をリリースしました。これにより、多数の言語の静的コード分析を行えるようになります。VSTS の Gradle および Maven タスクでは、特に Java ビルドにこれらの拡張機能を利用します。バージョン 2.* の Gradle または Maven タスクに対して [Run SonarQube/SonarCloud Analysis] を有効にしてから、以下のとおりに SonarQube/SonarCloud の [Prepare] と [Publish] タスクを追加します。詳細については、SonarQube を使用した分析 (英語) に関するドキュメントをご覧ください。
Git リポジトリからマークダウン ファイルを Wiki として公開
開発者は、「API」、「SDK」、「コードを説明するヘルプ ドキュメント」などのドキュメントをコード リポジトリに作成します。しかしユーザーは、コードを精査して必要なドキュメントを探す必要があります。今回、コード リポジトリからマークダウン ファイルを公開し、Wiki でホストできるようになりました。
まず、Wiki から [Publish code as wiki] をクリックします。次に、公開する Git リポジトリのフォルダーを指定します。
[Publish] をクリックすると、選択したフォルダーに含まれるすべてのマークダウン ファイルが Wiki として公開されます。また、ブランチの最上位のフォルダーが Wiki に関連付けられるため、Git リポジトリの変更が即座に反映されます。
詳しくは、発表記事 (英語) をご覧ください。同時に Wiki REST API も公開しています。詳細については、Wiki 関数 (英語) と Wiki 検索 (英語) に関するドキュメントをご確認ください。
Analytics views を使用して Power BI と VSTS Analytics を統合
Power BI と VSTS Analytics (英語) の拡張機能とを統合する便利なソリューション (英語) をリリースします。これにより、今後は OData クエリの記述方法を習得する必要はありません。新機能の Analytics views (英語) を使用すると、アカウントの規模を問わず、VSTS の作業管理データを Power BI に簡単に統合することができます。作業項目クエリのように、作業項目データの結果と列を絞り込むフィルターを指定可能なうえ、作業項目の変更履歴のレポートを作成し、トレンド レポートを簡単に作成することができます。
既定の Analytics views (英語) は、小規模アカウントや基本的なシナリオに適しています。大規模アカウントの場合は、Power BI に取り込むデータの範囲を絞り込む必要があり、Analytics views で行うことができます。Power BI でレポートする内容に合わせて、データと履歴の範囲を正確に絞り込みます。VSTS の Analytics ハブで作成した Analytics views は、即座に VSTS Power BI Data Connector (英語) で選択できるようになります。既定のビューを編集、または新しいビューを作成 (英語) して、Power BI に返されたレコード、フィールド、履歴を調整することができます。
まとめ
全機能の一覧はリリース ノートをご覧ください。VSTS に関する計画や開発の最新情報については、DevOps ブログ (英語) をご確認ください。
ではまた!