管線合規性和安全性驗證 - 短期衝刺 141 更新
在Azure DevOps Services的 Sprint 141 更新中，您現在可以在 Azure Pipelines 中包含合規性和安全性驗證。 在Azure Repos中，您可以變更提取要求的目標分支。
如需詳細資訊，請參閱下面的 功能 清單。
功能
一般：
Azure Pipelines：
- Azure 原則管線中的合規性和安全性驗證
- 簡化對 Azure VM 的持續傳遞
- Xcode 工作支援新發行的 Xcode 10
- 佇列組建時的效能改善
- 使用憑證驗證的服務主體建立 Azure 服務連線
- 在管線中檢視測試分析
Azure Repos：
管理：
後續步驟
注意
這些功能將在接下來兩到三周推出。
閱讀下列新功能，並前往Azure DevOps Services自行嘗試。
一般
流覽更新
回到今年 6 月，我們推出 新導覽模型的第一次反復專案。 我們已根據您所提供的許多意見反應，在一起改善該體驗的夏日。 感謝您！ 下一個步驟是從新的模型變成預覽，變成產品的導覽。 請閱讀 我們的部落格文章 ，說明最近的變更，以及將新模型帶入所有組織的排程。
展開的搜尋方塊
我們瞭解搜尋的重要性，並帶回產品標頭上的展開搜尋方塊。 此外，您現在只要按一下 Azure DevOps 中任何服務頁面上的 「/」 即可叫用搜尋方塊。 這項功能會根據使用者語音建議來設定優先順序。
以下是預設搜尋方塊：
輸入 「/」 之後，您會看到展開的搜尋方塊：
Azure Pipelines
Azure 原則管線中的合規性和安全性驗證
我們想要確保軟體在開發程式中的穩定性和安全性，同時將開發、安全性和作業整合在一起。 為了這樣做，我們已新增對Azure 原則的支援。
Azure 原則可協助您進行管理，同時透過原則定義讓您的資源強制執行規則並產生效果，避免發生 IT 問題。 當您使用Azure 原則時，資源會符合公司標準和服務等級協定的規範。
為了在發行過程中遵守合規性和安全性指導方針，我們已增強 Azure 資源群組部署體驗。 現在，在部署 ARM 範本時發生任何違規時，我們失敗了與相關原則相關的原則相關錯誤。
此外，我們已新增Azure 原則發行定義範本。 這可讓使用者建立 Azure 原則，並從發行定義本身將這些原則指派給資源、訂用帳戶或管理群組。
簡化對 Azure VM 的持續傳遞
在此版本中，我們新增了新的精靈，以簡化設定持續傳遞至 Azure 虛擬機器的程式。 一旦您指定要註冊虛擬機器的 Azure DevOps 組織和部署群組，就會使用範例腳本步驟自動建立發行管線。 如果您需要布建其他 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。 若要使用憑證驗證建立服務主體，請參閱 有關如何建立使用憑證進行驗證的服務主體一文。
在管線中檢視測試分析
追蹤一段時間的測試品質並改善測試附隨品是維護狀況良好管線的關鍵。 測試分析功能可讓您近乎即時地查看組建和發行管線的測試資料。 它可藉由識別重複、高影響品質的問題，來協助改善管線的效率。
您可以依各種元素分組測試結果、識別分支或測試檔案的關鍵測試，或向下切入至特定測試，以檢視趨勢並瞭解品質問題，例如 flakiness。
如需詳細資訊，請參閱文件。
Azure Repos
變更提取要求的目標分支
對於大部分小組而言，幾乎所有提取要求都會以相同的分支為目標，例如 master 或 develop 。 不過，在您需要以不同分支為目標的情況下，很容易忘記從預設值變更目標分支。 使用新功能來變更作用中提取要求的目標分支，現在是簡單的動作。 只要按一下提取要求標頭中目標分支名稱附近的鉛筆圖示即可。
除了更正錯誤之外，變更目標分支的功能也可讓您在合併或刪除目標分支時，輕鬆地「重定目標」提取要求。 假設您有以功能分支為目標的 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 是跨平臺技術，因此檔案或目錄可能會尋找它們可能在特定平臺上不相容的檔案系統。 您可以在 我們的檔中查看這些不相容的詳細資料。
為了協助小組保護其存放庫及其開發人員，我們新增了新的存放庫設定，以封鎖包含認可與一或多個 OS 平臺不相容的檔案/目錄的推播。 深入瞭解 這些設定。
系統管理
支援 MSA 帳戶中的 AAD 使用者
Azure DevOps 現在支援 AzureAD (AAD) 存取 MSA 所支援組織的使用者。 對於系統管理員而言，這表示如果您的 Azure DevOps 組織針對公司使用者使用 MSA，您現在可以使用其 AAD 認證來讓新員工存取，而不是只建立新的 MSA 身分識別來與 Azure DevOps 搭配使用。
我們仍然認為最佳的體驗是讓公司使用者 將 Azure DevOps 連線至 AAD，但我們稍早瞭解到系統管理員需要更多時間來進行該轉換。 藉由允許 AAD 使用者進入 MSA 支援的組織，新使用者就能夠在 Azure DevOps 防止在當月結束時建立具有 AzureAD 支援之自訂功能變數名稱的新 MSA 使用者之後存取 Azure DevOps。
對於已搭配 Azure DevOps 使用 AAD 身分識別的組織，此功能不適用。 對於目前使用 MSA 身分識別的組織，請注意，所有現有的使用者都可以像今天一樣繼續使用其 MSA 身分識別登入。 這僅適用于未來新增的使用者 (，這些使用者可能無法使用其公司電子郵件地址建立 MSA) 。
以下是此體驗可能很有用的範例案例：Dorothy 是其公司 Fabrikam 的 Azure DevOps 組織擁有者。 她和她的 10 個小組成員全都使用其公司電子郵件地址的 MSA 身分識別登入 Azure DevOps，例如 Dorothy@fabrikam.com 。 Sam 是今天加入公司的新小組成員。 Dorothy 使用電子郵件 sam@fabrikam.com 邀請他加入 Azure DevOps。 當他按一下電子郵件中的 [立即加入] 連結時，他可以使用與 Microsoft 365 存取其電子郵件相同的 AAD 身分識別登入 Azure DevOps。 這可讓 Sam 與他 11 位同事共同作業，並在她準備好時自由地將 Azure DevOps 組織連線到 AAD。
如需詳細資訊，請參閱我們的 部落格文章 。
如何提供意見反應
我們很樂於聽到您對這些功能的想法。 使用意見反應功能表來回報問題或提供建議。
您也可以在 Stack Overflow上取得社群所回答的建議和您的問題。
感謝您！
Gopinath Chigakkagari (Twitter)