增強的安全性管理
透過此更新，您現在可以選擇為整個專案或組織啟用或停用進階安全性。 您也可以針對任何新建立的存放庫或專案自動啟用進階安全性。
在 Azure Pipelines 中，我們新增了集中式控制項，以改善從分支 GitHub 存放庫建置的提取要求安全性。
請參閱版本資訊，以深入瞭解這些功能。
一般
Azure Pipelines
Azure Repos
Azure Artifacts
一般
進階安全性的專案和組織層級啟用
您現在可以針對整個專案或組織啟用或停用 進階安全性 。 除了在啟用之前新增認可者計數之外，在專案或組織層級選取 [ 全部啟用 ]，將會提供您預估可能需要支付多少新的作用中認可者。 您也可以選擇針對個別專案或組織下任何新建立的存放庫或專案自動啟用 進階安全性 。 透過此設定啟用的任何存放庫，都會有秘密存放庫掃描和推送保護作用中。
專案層級啟用：
組織層級啟用：
進階安全性啟用期間的估計認可者計數
身為 進階安全性 上線體驗的一部分，您現在可以看到由於針對特定存放庫、專案或組織啟用 進階安全性 ，可能會新增多少作用中認可者。 此計數是近似值，您可能會在提供的估計值與啟用後針對計費報告的內容之間看到稍微差異。 此估計值也可以透過 API 取得，並隨附說明此程式即將推出的其他檔。
Azure Pipelines
在核准和簽核逾時時重試階段
核准和檢查逾時時，會略過其所屬的階段。 也會略過相依于略過階段的階段。
現在，您可以在核准和檢查逾時時重試階段。先前，只有在核准逾時時，才可能這樣做。
所有環境的系統管理員角色
YAML 管線中的環境代表您部署應用程式的計算資源，例如 AKS 叢集或一組 VM。 它們提供您部署的安全性控制和可追蹤性。
管理環境可能相當具挑戰性。 這是因為建立環境時，建立環境的人員會自動成為唯一的系統管理員。 例如，如果您想要以集中式方式管理所有環境的核准和檢查，您必須要求每個環境管理員以系統管理員身分新增特定使用者或群組，然後使用 REST API 來設定檢查。 此方法很繁瑣、容易出錯，而且在新增環境時不會進行調整。
在此短期衝刺中，我們在環境中樞層級新增 了系統管理員角色 。 這可讓環境與服務連線或代理程式組件區進行剖析。 若要將系統管理員角色指派給使用者或群組，您必須已經是環境中樞系統管理員或組織擁有者。
具有此系統管理員角色的使用者可以管理許可權、管理、檢視及使用任何環境。 這包括開啟所有管線的環境。
當您在環境中樞層級授與使用者系統管理員角色時，它們會成為所有現有環境的系統管理員，以及任何未來的環境。
從分支 GitHub 存放庫建置 PR 的集中式控制
如果您從 GitHub 建置公用存放庫，則必須考慮分支組建上的主張。 分支特別危險，因為它們來自組織外部。
您可以檢閱如何 建置 GitHub 存放 庫和存放 庫保護的建議，以改善建置 GitHub 公用存放庫的管線安全性。 可惜的是，管理許多管線並確保其遵循最佳做法可能需要大量精力。
為了增強管線的安全性，我們新增了組織層級控制項，以定義管線如何從分支 GitHub 存放庫建置 PR。 新的設定名為 [限制從分支 GitHub 存放庫建置提取要求 ]，且可在組織和專案層級運作。
組織層級設定會限制專案可以擁有的設定，而專案層級設定會限制設定管線可以擁有。
讓我們看看切換在組織層級的運作方式。 預設會關閉新的控制項，因此不會通用強制執行任何設定。
當您開啟切換開關時，您可以選擇停用從分支 GitHub 存放庫建置 PR。 這表示，建立這類 PR 時，不會執行任何管線。
當您 從分岔存放庫選擇 [安全建置提取要求 ] 選項時，所有管線、全組織、 無法 讓秘密可供從分叉存放庫建置的 PR 使用、 無法 讓這些組建具有與一般組建相同的許可權， 而且必須由 PR 批註觸發。 專案仍然可以決定 不允許 管線建置這類 PR。
當您選擇 [ 自訂 ] 選項時，您可以定義如何限制管線設定。 例如，當 PR 屬於非小組成員和非參與者時，您可以確定所有管線都需要批註，才能從分支 GitHub 存放庫建置 PR。 但是，您可以選擇允許這些組建使用秘密。 專案可以決定 不允許 管線建置這類 PR，或安全地建置它們，或有更嚴格的設定，也就是組織層級所指定的設定。
Azure Repos
新的「分支原則」可防止使用者核准自己的變更
為了改善使用者核准和比對更嚴格法規/合規性需求的變更控制，我們會提供一個選項來防止使用者核准自己的變更，除非明確允許。
能夠管理分支原則的使用者現在可以在 [推送新變更時] 底下，切換新加入的選項「需要至少一次每次反復專案核准」。 選取此選項時，至少需要一個來源分支變更的核准投票。 使用者的核准不會計入該使用者所推送的任何先前未核准的反復專案。 因此，需要其他使用者完成上次反復專案的其他核准。
下圖顯示使用者 A 所建立的提取要求，以及額外的 4 個認可 (反復專案，) 使用者 B、C、A、A 和 C 對該提取要求所做的反復專案。第二次反復專案 (完成使用者 B) 認可之後，使用者 C 已核准該專案。 此時，當提取要求建立) 且新引進的原則將會成功時，隱含第一次認可使用者 A (。 第五次反復專案 (使用者 C) 認可之後，使用者 A 已完成核准。這表示使用者 C 所完成的先前認可隱含核准，但並不表示第四次反復專案中由使用者 A 完成的第二個認可核准。 若要讓新引進的原則成功，必須核准使用者 B、C 或任何其他未變更提取要求的使用者核准，才能核准未核准的反復專案四。
Azure Artifacts
介紹適用于貨物箱的 Azure Artifacts 支援 (公開預覽版)
我們很高興宣佈 Azure Artifacts 現在提供貨物箱的原生支援。 除了 crates.io 做為上游來源，這項支援還包含現有通訊協定的功能同位。 Rust 開發人員和小組現在可以順暢地取用、發佈、管理及共用其貨物箱，同時使用 Azure 的強固基礎結構並保持在熟悉的 Azure DevOps 環境中。
預覽不需要註冊;您可以流覽至您的 Azure DevOps 專案、選取 [成品]，然後遵循指示，將您的 Rust 專案連線到 Azure Artifacts 摘要，以開始使用。
後續步驟
注意
這些功能將在接下來兩到三周推出。
請前往 Azure DevOps 並查看。
如何提供意見反應
我們希望聽到您對這些功能的想法。 使用說明功能表來回報問題或提供建議。
您也可以在 Stack Overflow上取得社群所回答的建議和問題。
感謝您！
Silviu Andrica