パイプラインのコンプライアンスとセキュリティの検証 - Sprint 141 Update
Azure DevOps Servicesの Sprint 141 Update で、Azure Pipelines にコンプライアンスとセキュリティの検証を含めることができるようになりました。 Azure Reposでは、pull request のターゲット ブランチを変更できます。
詳細については、以下の 機能 の一覧を参照してください。
機能
全般:
Azure Pipelines:
- パイプラインでのコンプライアンスとセキュリティの検証をAzure Policyする
- Azure VM への継続的デリバリーの簡素化
- Xcode タスクでは、新しくリリースされた Xcode 10 がサポートされます
- ビルドをキューに入れたときのパフォーマンスの向上
- 証明書で認証するサービス プリンシパルを使用して Azure サービス接続を作成する
- パイプラインでテスト分析を表示する
Azure Repos:
- pull request - のターゲット ブランチを変更するクロスプラットフォーム互換性設定を使用して Git リポジトリを保護する
- クロスプラットフォーム互換性設定を使用して Git リポジトリを保護する
[Administration:
次の手順
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
以下の新機能を読み、Azure DevOps Servicesに進んで自分で試してみてください。
全般
ナビゲーションの更新
今年の 6 月に、 新しいナビゲーション モデルの最初のイテレーションをロールアウトしました。 多くの皆様から寄せられたフィードバックに基づいて、夏のエクスペリエンスの向上に費やしてきました。 よろしくお願いいたします。 次の手順では、新しいモデルをプレビューから、製品 の ナビゲーションに移行します。 新しいモデルをすべての組織に導入するためのスケジュールと共に、最近の変更について説明した ブログ投稿 をお読みください。
展開された検索ボックス
検索の重要性を理解し、製品ヘッダーの展開された検索ボックスを取り戻しています。 さらに、Azure DevOps の任意のサービス ページで [/] をクリックするだけで、検索ボックスを呼び出すようになりました。 この機能は、ユーザーの声の提案に基づいて優先順位が付けられました。
既定の検索ボックスを次に示します。
"/" を入力すると、展開された検索ボックスが表示されます。
Azure Pipelines
パイプラインでのコンプライアンスとセキュリティの検証をAzure Policyする
開発、セキュリティ、運用を一緒にしながら、開発プロセスの早い段階でソフトウェアの安定性とセキュリティを確保したいと考えています。 これを行うために、Azure Policyのサポートが追加されました。
Azure Policy では、リソースに対してルールと効果を適用するポリシー定義によって IT の問題を管理および防止できます。 Azure Policyを使用する場合、リソースは企業の標準とサービス レベルアグリーメントに準拠し続けます。
リリース プロセスの一環として、コンプライアンスとセキュリティのガイドラインに準拠するために、Azure リソース グループのデプロイ エクスペリエンスが強化されました。 ここでは、ARM テンプレートのデプロイ中に違反が発生した場合に、関連するポリシー関連のエラーで Azure リソース グループのデプロイ タスクを失敗させます。
さらに、リリース定義テンプレートAzure Policy追加しました。 これにより、ユーザーは Azure ポリシーを作成し、リリース定義自体からリソース、サブスクリプション、または管理グループにこれらのポリシーを割り当てることができます。
Azure VM への継続的デリバリーの簡素化
このリリースでは、Azure Virtual Machinesへの継続的デリバリーを設定するプロセスを簡略化する新しいウィザードを追加しました。 Azure DevOps organizationとデプロイ グループを指定して仮想マシンを登録すると、サンプル スクリプト ステップを使用してリリース パイプラインが自動的に作成されます。 追加の Azure リソースのプロビジョニング、スクリプトの実行、アプリケーションのアップグレード、または追加の検証テストの実行が必要な場合は、このリリース パイプラインを簡単にカスタマイズできます。
Xcode タスクでは、新しくリリースされた Xcode 10 がサポートされます
Apple の Xcode 10 リリースと合わせて、プロジェクトをビルドするように設定したり、Xcode 10 で特別にテストしたりできます。 パイプラインでは、Xcode バージョンの マトリックス と並行してジョブを実行することもできます。 Microsoft でホストされている macOS エージェント プールを使用して、これらのビルドを実行できます。 Azure Pipelines で Xcode を使用するための ガイダンス を参照してください。
ビルドをキューに入れたときのパフォーマンスの向上
ホステッド エージェントを使用すると、ジョブごとに新しい VM が取得されます。 これにより、セキュリティと制御の追加レイヤーが提供されます。 出力を残したり、マシンに悪意のある操作を行ったりする前のビルドについて心配する必要はありません。 ただし、初回起動時のアクティビティでは、以前は [ ビルドのキュー ] をクリックしてからパイプラインが実際に実行されるまでの遅延が発生しました。 これらの遅延の多くを調査して修正し、ホストされているプール全体でキューから開始までの時間で 5 倍の高速化が見られます。 ビルドをより迅速に開始できるようになりました。つまり、反復処理を高速化できます。
証明書で認証するサービス プリンシパルを使用して Azure サービス接続を作成する
Azure Pipelines または Team Foundation Server (TFS) で、認証用のサービス プリンシパルと証明書を使用して Azure サービス接続を定義できるようになりました。 証明書で認証するサービス プリンシパルをサポートする Azure サービス接続を使用して、AD FS で構成された Azure Stack にデプロイできるようになりました。 証明書認証を使用してサービス プリンシパルを作成するには、証明書で 認証するサービス プリンシパルを作成する方法に関する記事を参照してください。
パイプラインでテスト分析を表示する
テスト品質を経時的に追跡し、テスト資料を改善することは、正常なパイプラインを維持するための鍵です。 テスト分析機能を使用すると、ビルドとリリース パイプラインのテスト データをほぼリアルタイムで可視化できます。 繰り返し発生する影響の大きい品質上の問題を特定することで、パイプラインの効率を向上させることができます。
さまざまな要素でテスト結果をグループ化したり、ブランチまたはテスト ファイルの主要なテストを特定したり、特定のテストにドリルダウンして傾向を表示したり、フラキネスなどの品質の問題を理解したりできます。
ビルドとリリースのテスト分析を表示し、以下のプレビューを表示します。
詳細については、こちら を参照してください。
Azure Repos
pull request のターゲット ブランチを変更する
ほとんどのチームでは、ほぼすべての pull request が、 や developなどmaster、同じブランチを対象とします。 ただし、別のブランチをターゲットにする必要がある場合は、ターゲット ブランチを既定から変更することを忘れてしまいます。 アクティブな pull request のターゲット ブランチを変更する新しい機能により、これは単純なアクションになりました。 pull request ヘッダーのターゲット ブランチ名の近くにある鉛筆アイコンをクリックするだけです。
間違いを修正するだけでなく、ターゲット ブランチを変更する機能を使用すると、ターゲット ブランチがマージまたは削除されたときに pull request を簡単に "再ターゲット" できます。 変更が依存する機能を含む機能ブランチを対象とする PR があるシナリオを考えてみましょう。 依存する変更を、機能ブランチ内の他の変更とは分離して確認する必要があるため、最初に をターゲットにしますfeatures/new-feature。 その後、校閲者は自分の変更だけを確認し、適切なコメントを残すことができます。
ここで、機能ブランチも PR がアクティブで、変更前に にmasterマージされた場合はどうなりますか? 以前は、変更を破棄して に新しい PR を作成するか、 masterに PR features/new-featureをマージしてから、 から features/new-feature に別の PR を作成する master必要があります。 ターゲット ブランチを更新するこの新しいアクションを使用すると、PR のターゲット ブランチを から features/new-feature に master変更するだけで、すべてのコンテキストとコメントを保持できます。 ターゲット ブランチを変更すると、PR の新しい更新プログラムが作成されます。これにより、ターゲット ブランチが変更される前に、以前の差分を簡単に確認できます。
クロスプラットフォーム互換性設定を使用して Git リポジトリを保護する
Git はクロスプラットフォーム テクノロジであるため、ファイルまたはディレクトリは、特定のプラットフォームで互換性がない可能性があるファイル システムへの道を見つけることができます。 これらの非互換性の詳細については、 こちらのドキュメントを参照してください。
チームがリポジトリとその開発者を保護できるように、1 つ以上の OS プラットフォームと互換性のないファイル/ディレクトリを含むコミットを含むプッシュをブロックする新しいリポジトリ設定を追加しました。 これらの設定の詳細については、こちらをご覧ください。
管理
MSA アカウントで AAD ユーザーをサポートする
Azure DevOps では、MSA によってサポートされている組織にアクセスする AzureAD (AAD) ユーザーがサポートされるようになりました。 管理者の場合、これは、Azure DevOps organizationが企業ユーザーに対して MSA を使用している場合、Azure DevOps でのみ使用する新しい MSA ID を作成する代わりに、AAD 資格情報を使用して新しい従業員にアクセスできることを意味します。
企業ユーザーが Azure DevOps を AAD に接続するのが最善のエクスペリエンスであると考えていますが、今年の初めに、管理者がその変換を行うためにより多くの時間が必要であることを学習しました。 AZURE DevOps が月末に AzureAD によってサポートされるカスタム ドメイン名を持つ新しい MSA ユーザーの作成を防いだら、新しいユーザーは MSA 支援組織に AAD ユーザーを許可することで、Azure DevOps にアクセスできるようになります。
Azure DevOps で AAD ID を既に使用している組織の場合、この機能は適用されません。 現在 MSA ID を使用している組織の場合、既存のすべてのユーザーは、現在と同様に、引き続き MSA ID でサインインできることに注意してください。 これは、将来追加されたユーザー (企業のメール アドレスで MSA を作成できない可能性があるユーザー) にのみ適用されます。
このエクスペリエンスが役立つ可能性があるシナリオの例を次に示します。Dorothy は、会社 Fabrikam の Azure DevOps organization所有者です。 彼女と 10 人のチーム メンバーのチームはすべて、企業の電子メール アドレスを使用する MSA ID (例: ) を使用して Azure DevOps にサインインします。 Dorothy@fabrikam.com Sam は、今日入社した新しいチーム メンバーです。 Dorothy は、 sam@fabrikam.comメール を使用して Azure DevOps に招待します。 メールの [今すぐ参加] リンクをクリックすると、Microsoft 365 で自分のメールにアクセスするために指定されたのと同じ AAD ID を使用して Azure DevOps にサインインできます。 これにより、Sam は 11 人の同僚と共同作業を行い、準備ができたら Azure DevOps organizationを AAD に接続する自由を Dorothy に提供できます。
詳細については、 ブログ記事 を参照してください。
フィードバックの提供方法
これらの機能に関するご意見をお聞かせください。 フィードバック メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。
よろしくお願いします。
ゴピナス・チガッカガリ (Twitter)