Visual Studio Team Services(VSTS)のSprint 133アップデートでは、引き続きビルドとリリースでサポートする言語とプラットフォームを拡大しています。あなたのアプリケーションがAzure Database for MySQL、Kubernetes、またはRuby on Railsといったプラットフォームをあなたを使っているかどうかに関わらず、カバーしました。このリストはAzure DevOps Projectsで成長し続けます。今回の更新で、Azureにおいて、GoまたはRubyアプリケーションを使い始めるのが簡単ではない、という懸念はなくなりました。
新しい通知の種類とNuGetアップストリームソースのサポートが、Package Managementでも利用可能になりました。
注意事項
ここで議論されている機能は今後二～三週間にわたって順次展開されます。
- YAMLでCIビルドトリガーを設定する
- Azure Database for MySQLに継続的デプロイ
- HelmでKubernetesへストリームデプロイ
- Ruby on Railsアプリケーションのデプロイ
- Azure DevOps Projects でGoとRubyアプリケーションを構成する
- ビルド後にタグ付けしたビルドを継続的デプロイ
- GitHub Enterpriseおよび、外部Gitのブランチでフィルタする
最近、私たちは特殊文字を検索する場合により正確な検索結果が得られる方法を検討しています。
今回の更新では、(英数字以外の)特別な文字を含む検索を行うと、探している文字列を見つけられる可能性が高くなります。たとえば、以前にA + Bを検索した場合、結果にはA+B、A--B、A*B、A$B、A/Bなどの期待しない文字列が含まれていました。
文字フレーズに対する検索もよくなりました。たとえば、以前は new List()を検索すると、>()を含まない部分一致で検索されました。
今回の更新から、フレーズ全体が一致対象となり、強調表示されます。
チームの設定では、1つ以上のArea Pathを関連付けることができます。これにより、Backlogs, Boards, Plans, Dashboardまで、そのチームの仕事だけに集中させることができます。ただし、チームのクエリを作成する場合は、そのチームのArea Pathクエリ句にすべてのArea Path一覧から選択して追加する必要がありました。今回の更新では、新しい@TeamAreasマクロを使用すると、指定したチームの所有するArea Pathを簡単に参照できます。この機能は、提案に基づいて優先順位が付けられました。
YAMLビルド定義ファイルの一部として、継続的インテグレーション(CI)トリガ設定を定義できるようになりました。デフォルトでは、新しい.vsts-ci.ymlファイルをGitリポジトリにプッシュすると、すべてのブランチに対してCIが自動的に設定されます。
トリガ対象のブランチを制限するには、以下のような記述をすると、master もしくは release/*配下のすべてのブランチにプッシュされたときだけビルドがトリガーされるようになります。
YAML
trigger:
- master
- releases/*
トリガーを無効にしたい場合や、YAMLファイルのトリガー設定を上書きする場合、定義に対して行えます。
詳細については、YAML build triggersのドキュメントを参照してください。
AzureのMySQL Databaseに対して継続的展開が可能になりました。バージョン管理でMySQLスクリプトファイルを管理し、PowerShellスクリプトではなくネイティブタスクを使用してリリースパイプラインの一部として継続的に展開します。
Helmは、Kubernetesアプリケーションのインストールと管理をストリーム化するツールです。Helmは昨年、コミュニティから多くの支持を得ました。HelmチャートをAzure Container Service(AKS)または他のKubernetesクラスタにパッケージ化して配備するために、ReleaseでHelm Taskが利用できるようになりました。
VSTSは既にKubernetesとDockerのコンテナをサポートしています。このHelmタスクを追加することで、コンテナをKubernetesクラスタに配信するためのHelmベースのCI/CDパイプラインが設定できるようになりました。詳細は、Kubernetes to Azure Container Serviceを参照してください。
Ruby on RailsアプリケーションをAzure WebApp on Linuxに配備するために必要なタスクが新しくAzure App Serviceのリリース定義テンプレートに含まれるようになりました。このリリース定義テンプレートを使用すると、App Service Deployタスクに、アプリケーションの依存関係を解決するためのbundleler(依存関係マネージャ)がインラインデプロイメントスクリプトとしてがあらかじめ設定されています。
Azure DevOps Projectsを使用すると、Azureが簡単にはじめられます。DevOpsプロジェクトを使えば、あなたが選んだAzureサービス上のアプリケーションをわずかなステップで起動できるようになります。DevOps Projectsは、アプリの開発、導入、監視に必要なものすべてを設定します。今回の更新で、GoとRubyアプリケーション用のDevOpsパイプライン全体をセットアップすることができるようになりました。詳細については、Deploy to Azureのドキュメントを参照してください。
継続的なデプロイメントトリガーは、ビルド完了時にリリースを作成します。ただし、ビルドはしばしば後処理を行うことがあり、その処理が完了した後にのみビルド成果物をリリースしなければならない場合があります。今回の更新で、後処理で割り当てられるビルドタグを、リリースのトリガフィルタで活用できます。
GitHub Enterpriseまたは外部のGitリポジトリからのリリース時に、リリースされる特定のブランチを設定できるようになりました。たとえば、特定のブランチからのビルドのみを本番環境にデプロイできます。
かつて、パッケージの新しいバージョンがリリースされたことを知る唯一の方法は、パッケージクライアント(Visual Studio、NuGet、npmなど)を使用するしかありませんでした。今回の更新で、気になるパッケージの更新通知が電子メールで受けられるようになりました。特定のパッケージの新しいバージョンやフィード内のすべてのパッケージに関する通知を受け取ることができます。パッケージの告知(Promote)または削除時の通知もできます。
これを設定するには、右上隅のプロフィール画像にカーソルを置き、Notification settingsを選択し、New subscriptionをクリックします。表示されるダイアログで、Packageカテゴリを選択します。
この機能は、提案に基づいて優先順位が付けられました。
アップストリームソースには引き続き投資します。今回の更新で、すべてのパッケージ依存関係を1つのフィードに集中させ、使用するすべてのパッケージの保存済みコピーを保持できます。NuGetパッケージを使用して複数のフィードをお持ちの場合は、同じアカウント内の他のフィードをアップストリームソースとして追加できます。これにより、nuget.configファイル内に1つのフィードのみを持つことができ、確定的な復元などの利点が得られます。詳細については、upstream sourcesドキュメントを参照してください。
以前、Sprint 130アップデートの後に作成されたフィードのみが、nuget.orgのアップストリームソースを使用することができました。今回の更新で、そのアップデートの前に作成されたほとんどのパッケージ管理フィードでも使用可能になりました。あなたのフィードに対して用意ができたら、パッケージの上にnuget.orgのアップストリームソースを有効にできることを知らせるバナーが表示されます。
Nuget.orgやnpmjs.comのようなパブリックパッケージフィードのアップストリームソースは、使用しているすべてのパッケージの保存されたコピーを保持しているため、停止(outages)にできません。詳細については、upstream sourcesドキュメントを参照してください。
別のwikiページへのリンクを作成したいときは、[リンク名](/のような、リンクを追加するための標準的なマークダウン構文を入力するだけです。リンクをクリックすると、現在のWikiにすべてのページが登録されます。wikiページをマークダウンエディタにドラッグしてリンクを作成しますが、これによりページのリンクが簡単に作成されます。
この機能は提案に基づいて優先順位がつけられました。
GitリポジトリからマークダウンファイルをWikiとして公開すると、同じプロジェクトで複数のwikiが見れるようになります。そうなると、検索する際に、類似した文書を渡り歩くことになってしまうため、探しているものが見つけにくくなる場合があります。今回の更新で、あなたのWikiページを検索すると、検索結果ページにWiki名でフィルタを適用することにより、コンテンツをより迅速に検索できるようになるため、結果が絞り込みやすくなります。
今回の更新で、他のほとんどのAzureリソースと同様に、AzureポータルのAzureサブスクリプションまたはリソースグループ間でVSTSアカウントを移動することができるようになりました。詳細については、move resourcesドキュメントを参照してください。
これらの機能についてどう思っているかお聞きしたいと思います。フィードバックメニューを使用して、優先順位を付けたいと思っていることに関するアイデアがある場合は、問題を報告するか、提案をしてください。
アドバイスや回答が必要な質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Henry Dixon