Azure DevOps ServicesのSprint 141アップデートでは、Azure Pipelinesでコンプライアンスとセキュリティ検証ができるようになりました。Azure Reposでは、pull requestのターゲットブランチの変更ができるようになりました。
以下のリストで紹介する機能を是非体験してください。
General:
Azure Pipelines:
- Azure PipelinesでAzureポリシーコンプライアンスとセキュリティ検証を使う
- Azure VMへの継続的デリバリーを簡単に作る
- Xcodeタスクで新しくリリースされたXcode 10をサポート
- ビルドキューに投入する性能を向上
- サービスプリンシパルを使ったAzureサービス接続への証明書認証を作成する
- Pipelinesでテスト分析を見る
Azure Repos:
Administration:
注意事項
ここで議論されている機能は今後二～三週にわたって順次展開されます。
これらの新機能を読んだ後、次のリンクからぜひご自身でAzure DevOpsサービスを体験してみてください。
今年6月に、最初のイテレーションとして新しいナビゲーションモデルを公開しました。私たちは皆さんからいただいた多くのフィードバックに基づいて、そのエクスペリエンスを向上させるために、この夏をすべてささげました。ありがとうございました！私たちの次のステップは、プレビューの新しいモデルから製品のナビゲーションに移行することです。新しいモデルをすべての組織にもたらすためのスケジュールとともに、最近の変更点を説明するブログをお読みください。
検索の重要性を理解しており、拡張された検索ボックスを製品のヘッダーに戻しています。また、Azure DevOpsのサービスページで"/"をクリックするだけで検索ボックスを呼び出すことができます。この機能は、次のuser voiceに基づいて優先順位が付けられました。
これがデフォルトの検索窓です。
"/"を一度タイプすると、検索窓が拡張されます。
私たちは開発プロセスの早い段階でソフトウェアの安定性とセキュリティを確保しながら、開発、セキュリティ、および操作を一緒にしたいと考えています。そのために、Azure Policyのサポートを追加しました。Azure Policyは、リソースに規則と効果を適用するポリシー定義を使用して、ITの問題を管理および防止します。Azure Policyを使用すると、リソースを企業標準およびサービスレベル契約に準拠できます。リリースプロセスの一環としてのコンプライアンスとセキュリティのガイドラインに準拠するため、Azureリソースグループの展開を強化しました。現在、Azure Resource Groupのデプロイメントタスクで、ARMテンプレートをデプロイする際に違反があった場合に関連するポリシー関連のエラーが発生しています。
さらにAzure Policy Release定義テンプレートを追加しました。これにより、ユーザーはAzureポリシーを作成し、これらのポリシーをリリース定義自体からリソース、サブスクリプション、または管理グループに割り当てることができます。
今回のリリースでは、Azure仮想マシンへの継続的デリバリーの設定プロセスを簡略化するための新しいウィザードを追加しました。Azure DevOps組織とdeployment groupを指定して仮想マシンを登録すると、サンプルスクリプトステップでリリースパイプラインが自動的に作成されます。追加のAzureリソースのプロビジョニング、スクリプトの実行、アプリケーションのアップグレード、または追加の検証テストの実行が必要な場合は、このリリースパイプラインを簡単にカスタマイズできます。
AppleのXcode 10のリリースに合わせて、Xcode 10を使ってプロジェクトを構築および、テストができます。パイプラインでは、Xcodeバージョンのマトリクスで並行してジョブを実行できます。これらのビルドを実行するために、Microsoft-hosted macOSエージェントプールを使用できます。Azure PipelineでXcodeを使用するためのガイダンスを参照してください。
ホステッドエージェントを使用すると、ジョブごとに新しいVMが取得されます。これにより、セキュリティと制御に追加の層を提供します。以前のビルドがアウトプットの周りに残っているとか、マシンに何か悪意のある行為をしていることを心配する必要はありません。ただし、はじめての起動アクティビティとは、ビルドのキューをクリックしてから実際にパイプラインが実行されるまでの遅延を意味していました。これらの遅延の多くを調査して修正し、現在ホストされているプール全体でQueue buildを実行して、ビルド開始までの時間が1/5になったため、ビルドが早く開始されるようになりました。つまり、より速く反復できます。
今回の更新で、Azure PipelinesまたはTeam Foundation Server(TFS)で、サービスプリンシパルと証明書を使用してAzureサービス接続を認証用として定義できるようになりました。証明書ベースの認証を使うサービスプリンシパルをサポートするAzureサービス接続を使用すると、AD FSで設定されたAzure Stackへ展開できるようになりました。証明書認証を使用してサービスプリンシパルを作成するには、how to create a service principal that authenticates with a certificateを参照してください。
時間の経過によるテストの品質を追跡し、テスト担保を改善することは、健全なパイプラインを維持する上で重要です。テスト分析機能は、ビルドおよびリリースパイプラインのテストデータをほぼリアルタイムで可視化します。反復的で影響の大きい品質問題を特定することで、パイプラインの効率が向上します。
テスト結果をさまざまな要素でグループ化したり、ブランチやテストファイルのキーテストを特定したり、特定のテストにドリルダウンしてトレンドを表示したり、フレークさなどの品質問題を理解できます。
ビルドおよびリリースのテスト分析を表示し、以下をプレビューします。
詳細はドキュメントを参照してください。
ほとんどのチームにとって、ほぼすべてのpull requestは、masterやdevelopmentなどの同じブランチを対象としています。ただし、別のブランチをターゲットにする必要がある場合、ターゲットブランチをデフォルトから変更するのを忘れてしまいます。今回の新機能として、アクティブなpull requestのターゲットブランチを簡単なアクションで変更できるようになりました。pull requestヘッダーのターゲットブランチ名の近くの鉛筆アイコンをクリックするだけでできます。
誤って修正するだけでなく、ターゲットブランチを変更する機能によって、ターゲットブランチがマージまたは削除されたときにpull requestを「再ターゲット」することも容易になります。変更が依存している機能が含まれているフィーチャーブランチをターゲットにしたPRがあるシナリオを考えてみましょう。フィーチャーブランチ内の他の変更とは独立している依存関係の変更を確認したいので、最初にfeatures/new-featureを対象にします。レビュー担当者はあなたの変更を確認し、適切なコメントが残せます。
次は、フィーチャーブランチへのPRがアクティブで、変更前にmasterへマージされていたら何が起こるかを考えてみましょう。以前は、変更を放棄して新しいPRを作成したり、PRをfeatures/new-featureにマージしたり、features/new-featureからmasterに別のPRを作成する必要がありました。ターゲットブランチを更新するこの新しいアクションでは、単にPRのターゲットブランチをfeatures/new-featureからmasterに変更しても、すべてのコンテキストとコメントを保持します。ターゲットブランチを変更すると、PRの新しいアップデートが作成され、ターゲットブランチが変更される前の以前の差分を容易に参照できるようになります。
Gitはクロスプラットフォームの技術であるため、ファイルやディレクトリが特定のプラットフォームで互換性のないファイルシステムにアクセスする可能性があります。これらの非互換性に関する詳細は、ドキュメントに記載されています。
チームがリポジトリとその開発者を保護するために、新しいリポジトリ設定を追加して、1つまたは複数のOSプラットフォームと互換性のないファイル/ディレクトリを持つコミットをブロックします。これらの設定の詳細をご覧ください。
MSA(訳注：Microsoftアカウントのこと)を認証のバックエンドに使っているAzure DevOpsでも、組織AzureAD(AAD)ユーザーをサポートするようになりました。管理者にとって、これはAzure DevOps組織が企業ユーザー向けにMSAを使用する場合、Azure DevOps専用の新しいMSA IDを作成するのではなく、新しい従業員にAAD資格情報を使用させることができるようになりました。
企業ユーザーがAzure DevOpsをAADに接続するのが最高の経験だと今でも信じていますが、今年初めに管理者がその変換を行うために多くの時間費やしていることも理解しています。AADユーザーをMSA認証でサポートすることにより、新規ユーザーはAzure DevOpsにアクセスできます。AzureADは、月末にAzure ADで作られているカスタムドメイン名を持つ、新しいMSAユーザーが作成できないようになっています。
Azure DevOpsですでにAADのアイデンティティーを使用している組織では、この機能は適用されません。現在MSAのアイデンティティを使用している組織の場合、既存のすべてのユーザーは、現在のようにMSAのIDで引き続きサインインできることに注意してください。これは、今後追加されるユーザー(企業の電子メールアドレスでMSAを作成できない可能性があるユーザー)にのみ適用されます。
この経験が役に立ちそうなシナリオの例は次のとおりです。DorothyはAzure DevOpsをFabrikamという会社で使っている組織管理者です。彼女と10人のチームメンバーからなるチームはすべて、Dorothy@fabrikam.comのようなメールアドレスに紐づいたMSAを使ってAzure DevOpsにサインインします。Samは今日、この会社に加わった新しいチームメンバーです。Dorothyは彼の電子メールsam@fabrikam.comを使用して彼をAzure DevOpsに招待します。電子メールの今すぐ参加するリンクをクリックすると、O365で彼のEメールにアクセスするのと同じAADアイデンティティでAzure DevOpsにサインインできます。これにより、Sam氏は11人の同僚と共同作業でき、DorothyにAzure DevOps組織をAADに接続する準備ができました。
詳しくは、ブログをご覧ください。
2017年2月、VSTSはAzure Active Directoryの条件付きアクセスポリシー(CAP)のサポートを発表しました。その発表の時に忠告された警告のひとつは、個人アクセストークンなどの代替認証メカニズムがCAPを強制しないということでした。このギャップの解消がお知らせできることを嬉しく思っています。PAT、SSHキー、OAuthを使用する場合、Azure DevOpsはCAP IPフェンシングポリシーを守ります。管理者はこの機能を利用するために何もする必要はありません。既存のすべてのポリシーに自動的に適用されます。
これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。
アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。
ありがとうございました。
Gopinath Chigakkagari (Twitter)