次の方法で共有

Azure Database for MySQL、Helm を使用した Kubernetes、Ruby on Rails のデプロイ – VSTS Sprint 133 Update

  • [アーティクル]

Sprint 133 Update of Visual Studio Team Services (VSTS) では、ビルドとリリースでサポートされている言語とプラットフォームを引き続き拡張しています。 アプリケーションで Azure Database for MySQL、Kubernetes、Ruby on Rails のいずれを使用する場合でも、取り上げてきました。 この一覧は、Azure DevOps プロジェクトでも増え続けています。 これで、Azure で Go または Ruby アプリケーション を使い始めるのが簡単になりました。

NuGet アップストリーム ソースに対する新しい通知の種類とより適切なサポートは、パッケージ管理でも利用できるようになりました。

VSTS の新機能

機能

コード

Work

ビルドとリリース

Package

Wiki

管理

コード

特殊文字を含む語句とコードを迅速に検索する

特に検索に特殊文字が含まれている場合に、検索結果をより正確にする方法を最近検討しています。

この更新プログラムでは、特別な (英数字以外の) 文字を含む検索が、探しているものを見つけるのに役立つ可能性が高くなります。 たとえば、以前に を検索したA+B場合、結果には 、、A-B、A*B、A$BA/B、などを含A+Bめることができます。これで、偽陽性なしで結果にのみ表示A+Bされます。

フレーズもより適切に認識されます。 たとえば、以前は を new List<string>() 検索すると、この部分一致が返され、末尾は >() 返されません。

検索結果に完全な検索語句がありません

ただし、この更新プログラムでは、完全な語句が返され、強調表示されます。

完全な検索語句を含む結果

Work

新しい @TeamAreas マクロを使用してチームのエリア パスで作業を照会する

チームの設定では、1 つ以上のエリア パスを関連付けることができます。これは、 バックログ、 ボード、 プラン、 さらにはダッシュボード をそのチームの作業のみに集中するのに役立ちます。 ただし、チームのクエリを作成する場合は、クエリ句でそのチームの特定のエリア パスを一覧表示する必要がありました。 これで、新しい @TeamAreas マクロを使用して、指定したチームに所有されているエリア パスを簡単に参照できるようになりました。 この機能は提案に基づいて優先されました。

クエリ エディターのチーム領域マクロ

ビルドとリリース

YAML から CI ビルドをトリガーする

YAML ビルド定義ファイルの一部として、継続的インテグレーション (CI) トリガー設定を定義できるようになりました。 既定では、新 .vsts-ci.yml しいファイルを Git リポジトリにプッシュすると、すべてのブランチに対して CI が自動的に構成されます。

トリガーするブランチを制限するには、以下をファイルに追加して、マスターへのプッシュまたはリリース/* パターンに一致するブランチのビルドをトリガーします。

trigger:
- main
- releases/*

トリガーを無効にするか、YAML ファイルのトリガー設定をオーバーライドする場合は、定義でこれを行うことができます。

詳細については、 YAML ビルド トリガーの ドキュメントを参照してください。

yaml からの ci トリガー

Azure Database for MySQLに継続的にデプロイする

Azure Database for MySQL - Azure の MySQL データベースにサービスとして継続的にデプロイできるようになりました。 バージョン管理で MySQL スクリプト ファイルを管理し、PowerShell スクリプトではなくネイティブ タスクを使用してリリース パイプラインの一部として継続的にデプロイします。

Helm を使用して Kubernetes へのデプロイを効率化する

Helm は、Kubernetes アプリケーションのインストールと管理を効率化するツールです。 また、昨年は多くの人気とコミュニティのサポートを得ています。 リリースの Helm タスクを、Azure Container Service (AKS) またはその他の Kubernetes クラスターに Helm チャートをパッケージ化してデプロイできるようになりました。

VSTS では、Kubernetes コンテナーと Docker コンテナーが既にサポートされています。 この Helm タスクを追加することで、コンテナーを Kubernetes クラスターに配信するための Helm ベースの CI/CD パイプラインを設定できるようになりました。 詳細については、 Kubernetes を使用した Azure Container Service へのデプロイ に関するドキュメントを参照してください。

Helm タスク

Ruby on Rails アプリケーションをデプロイする

新しいAzure App Serviceリリース定義テンプレートに、Ruby on Rails アプリケーションを Azure WebApp on Linux にデプロイするために必要なタスクが含まれるようになりました。 このリリース定義テンプレートを使用すると、App Service配置タスクには、bundler (依存関係マネージャー) がアプリケーションの依存関係をインストールするインライン展開スクリプトが事前に設定されます。

Azure DevOps Projects を使用して Go アプリケーションと Ruby アプリケーションを構成する

Azure DevOps Projects を利用すると、Azure を使い始めるのが簡単になります。 これは、いくつかの手順で任意の Azure サービスでアプリケーションを起動するのに役立ちます。 DevOps Projects は、アプリの開発、デプロイ、監視に必要なすべてのものを設定します。 これで、Go および Ruby アプリケーション用に DevOps パイプライン全体をセットアップできるようになりました。 詳細については、 Azure へのデプロイに関する ドキュメントを参照してください。

ビルド後処理によってタグ付けされたビルドを継続的にデプロイする

継続的デプロイ トリガーは、ビルドの完了時にリリースを作成します。 ただし、ビルドが後処理されることがあり、その処理が完了した後にのみビルドを解放する必要があります。 これで、リリースのトリガー フィルターで、後処理中に割り当てられるビルド タグを利用できるようになりました。

ビルド タグ トリガー

GitHub Enterprise または外部 Git 成果物のブランチをフィルター処理する

GitHub Enterprise または外部 Git リポジトリからリリースする場合は、リリースされる特定のブランチを構成できるようになりました。 たとえば、特定のブランチから運用環境へのビルドのみをデプロイできます。

ブランチ フィルター

Package

パッケージ更新通知をサブスクライブする

以前は、使用するパッケージの新しいバージョンについて知る唯一の方法は、パッケージ クライアント (Visual Studio、NuGet、npm など) を使用することでした。 これで、関心のあるパッケージに関する電子メール通知を構成できるようになりました。 フィード内の特定のパッケージまたはすべてのパッケージの新しいバージョンに関する通知を受け取ることができます。 パッケージが昇格または削除されたときにも通知を受け取ることができます。

これを設定するには、右上隅にあるプロファイル画像にマウス ポインターを合わせ、[ 通知の設定] を選択し、[新しいサブスクリプション] をクリックします。 表示されるダイアログで、[ パッケージ ] カテゴリを選択します。

この機能は提案に基づいて優先されました。

VSTS の他の場所からアップストリーム NuGet パッケージを使用する

引き続きアップストリーム ソースに投資しています。これにより、すべてのパッケージ依存関係を 1 つのフィードに一元化し、使用するすべてのパッケージの保存されたコピーを保持できます。 NuGet パッケージで複数のフィードがある場合は、同じアカウント内のもう一方のアップストリーム ソースとして 1 つを追加できます。 これにより、 nuget.config ファイルに 1 つのフィードのみを含め、確定的な復元などの利点が得られます。 詳細については、 アップストリーム ソース のドキュメントを参照してください。

NuGet アップストリーム

より多くのフィード nuget.org アップストリーム ソースを有効にする

以前は、 Sprint 130 Update の後に作成されたフィードのみが、nuget.org アップストリーム ソースを使用できました。 これで、その更新プログラムの前に作成されたほとんどのパッケージ管理フィードでも使用できます。 フィードの準備ができたら、パッケージの上にバナーが表示され、アップストリーム ソース nuget.org 有効にできることを知らせます。

nuget.org や npmjs.com などのパブリック パッケージ フィードへのアップストリーム ソースは、使用するすべてのパッケージの保存されたコピーを保持するため、停止から保護されます。 詳細については、 アップストリーム ソース のドキュメントを参照してください。

Wiki

別の Wiki ページへのリンクを作成する場合は、リンク [link name](/ を追加するための標準の Markdown 構文を入力するだけで、現在の Wiki のすべてのページが登録されます。 以前は、Wiki ページをクリックして Markdown エディターにドラッグしてリンクを作成できましたが、これによりページ内でのリンクの作成がさらに簡単になります。

autosuggestion Wiki ページ リンク

この機能は提案に基づいて優先されました。

Wiki 名で検索結果をフィルター処理する

Git リポジトリから Markdown ファイルを Wiki として発行すると、 前回の更新プログラムをリリースしました。これは、同じプロジェクトに複数の Wiki が表示されることを意味します。 検索するときは、同様のドキュメントを探して探しているものを見つけるのが難しい場合があります。 これで、Wiki ページを検索するときに、検索結果ページに Wiki 名フィルターを適用して結果の範囲を絞り込み、コンテンツをより迅速に見つけることができます。

検索中の Wiki 名

管理

Azure サブスクリプションまたはリソース グループ間で VSTS アカウントを移動する

これで、他のほとんどの Azure リソースと同様に、Azure portal内の Azure サブスクリプションまたはリソース グループ間で VSTS アカウントを移動できるようになります。 詳細については、 リソースの移動 に関するドキュメントを参照してください。

次の手順とフィードバック

VSTS に移動する

更新をサブスクライブする

これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告するか、Microsoft に優先順位を付ける必要がある事項に関するアイデアがある場合は、提案を提供します。

フィードバック メニュー

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

ヘンリー・ディクソン