Sdílet prostřednictvím


Rozšířené zabezpečení a pracovní postupy kanálů

V tomto sprintu vylepšujeme váš pracovní postup DevOps s větším přehledem o zabezpečení a efektivnějšími kanálovými procesy. GitHub Advanced Security nyní obsahuje podrobné sledování povolení pro skenování závislostí, skenování kódua skenování tajných údajů, které nabízejí hlubší přehled o pokrytí zabezpečení vaší organizace.

Kromě toho s radostí zavádíme vylepšení zaměřená na kanály, včetně nových funkcí výrazů YAML a rozšířených ovládacích prvků pro úlohy ručního ověřování, což vám umožní vytvářet efektivnější a bezpečnější pracovní postupy.

Podrobnosti najdete v poznámkách k verzi.

Pokročilé zabezpečení GitHubu pro Azure DevOps

Azure Boards:

Azure Repos

Azure Pipelines

Testovací plány

Pokročilé zabezpečení GitHubu pro Azure DevOps

Pokrytí přehledu zabezpečení pro konkrétní nástroj

Přehled zabezpečení v GitHub Advanced Security pro Azure DevOps teď poskytuje podrobný rozpis stavu povolení pro každý nástroj pro kontrolu závislostí, prohledávání kódua kontroly tajných kódů . Toto vylepšení umožňuje zobrazit jemně odstupňované stavy povolení ve všech úložištích ve vaší organizaci.

Další informace naleznete v tématu Přehled pokročilého zabezpečení.

Azure Boards

Integrace Azure Boards s cloudem GitHub Enterprise s rezidencí dat

Azure Boards teď podporuje integraci s cloudovými organizacemi GitHub Enterprise, které mají povolenou rezidenci dat. Tato aktualizace je v souladu s oznámením GitHubu ze září 2024 zavádějícím rezidenci dat pro zákazníky podnikového cloudu, počínaje těmi v Evropské unii (EU).

Připojení projektu Azure Boards ke cloudové organizaci GitHub Enterprise s rezidencí dat:

  1. Vytvořte nové připojení v Azure Boards.
  1. Vyberte GitHub Enterprise Cloud s možností umístění dat.

cs-CZ: snímek obrazovky s novým připojením GitHubu

Azure Repos

Řídký výběr pro Azure Repos

Příkaz git řídký poklad je nyní podporován v úkolu YAML společně s částečným klonovacím filtrem, aby se zlepšil výkon pokladování úložiště. Můžete použít vlastnosti sparseCheckoutDirectories a sparseCheckoutPatterns.

Nastavení sparseCheckoutDirectories povolí režim kužele, kdy proces rezervace používá porovnávání adresářů. Alternativně můžete nastavit sparseCheckoutPatterns, které aktivuje režim bez kužele, což umožňuje složitější porovnávání vzorů.

Pokud jsou nastaveny obě vlastnosti, agent inicializuje režim kužele s odpovídajícími adresáři. Pokud není v úloze checkout zadána žádná vlastnost, je proces řídkého checkoutu zakázán. Jakékoliv problémy během provádění příkazu způsobí selhání úlohy výběru.

Příklad YAML pro režim řídkého kuželového výběru:

    checkout: repo
    sparseCheckoutDirectories: src

Příklad YAML pro režim řídkého vyhledávání, který není kuželový:


   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Důležitý

Funkce řídké rezervace vyžaduje agenta verze 3.248.0 (v4.248.0 pro .NET 8) nebo novějších verzích.

Agenta najdete na stránce vydání .

Rozlišovat velká a malá písmena v zásadách napříč úložišti

Dříve náhled kandidátské větve pro zásady křížového repozitáře zobrazoval výsledky bez rozlišení malých a velkých písmen, přestože porovnávání větví rozlišuje malá a velká písmena. Tato nekonzistence mohla vést k potenciálnímu nesouladu, protože se mohlo zdát, že určité pobočky byly chráněny, když nebyly. Abychom tento problém vyřešili, aktualizovali jsme náhled vzoru větve tak, aby odpovídal chování politiky s rozlišením velikosti písmen.

Dříve:

Po:

Azure Pipelines

Nové funkce výrazů pipeline

Funkce výrazů kanálu umožňují psát výkonné kanály YAML. V tomto sprintu jsme zavedli dvě nové funkce:

  • iif(condition, value_when_true, value_when_false), která vrací value_when_true, když se condition vyhodnotí jako true nebo value_when_false, jinak

  • trim(string), který vrátí nový řetězec, ve kterém se odeberou prázdné znaky na začátku a konci řetězce.

Pomocí funkce iif můžete například dynamicky vybrat fond pro spuštění pipeline. Pokud chcete vytvářet pull requesty pomocí fondu Azure Pipelines, ale všechna ostatní spuštění by měla používat spravovaný fond DevOps, můžete napsat následující pipeline.

variables:
  poolToUse: ${{ iif(eq(variables['Build.Reason'], 'PullRequest'), 'Azure Pipelines', 'ManagedDevOpsPool')}}

stages:
- stage: build
  pool: ${{variables.poolToUse}}
  jobs:
  - job:
    steps:   
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'

Pomocí funkce trim můžete zajistit odolnost YAML vůči uživatelským vstupům. Například v následujícím pipeline používáme funkci trim, abychom zajistili, že název fáze nezačíná bílými mezerami.

parameters:
- name: regions
  type: string
  default: '  wus1,   wus2, wus3,wus4'

stages:
- ${{ each region in split(parameters.regions, ',')}}:
  - stage: stage_${{trim(region)}}
    displayName: Deploy to ${{trim(region)}}
    jobs:
    - job: deploy
      steps:
      - script: ./deploy.sh ${{trim(region)}}

Vylepšení úlohy ManualValidation

Úloha ManualValidation umožňuje pozastavit běh kanálu a čekat na ruční zásah. Jedním ze scénářů použití této úlohy je ruční testování.

Pokud chcete zvýšit zabezpečení kanálu, můžete chtít omezit, kdo může dokončit úlohu a pokračovat v spuštění kanálu. Za tímto účelem představujeme novou verzi úlohy, která poskytuje dva další parametry:

  • approvers: omezení, kdo může úkol dokončit, na předdefinovanou sadu uživatelů / skupin zabezpečení / týmů

  • allowApproversToApproveTheirOwnRuns: Zabraňte uživateli, který zařadil spuštění kanálu do fronty, aby v něm mohl znovu pokračovat.

Například následující fragment kódu YAML omezuje sadu lidí, kteří mohou obnovit běh kanálu, na členy skupiny Schvalovatelů vydaných verzí, ale nikoliv uživatelem, který běh kanálu spustil.

- task: ManualValidation@1
  inputs:
    notifyUsers: 'Release Approvers'
    approvers: 'Release Approvers'
    allowApproversToApproveTheirOwnRuns: false

Ve vlastnosti approvers můžete použít následující hodnoty (oddělené čárkami):

  • E-mailová adresa,
  • Skupina oprávnění,
  • Projektový tým,
  • [Název_projektu][Skupina oprávnění],
  • [Organizace][Skupina oprávnění],
  • [Název_projektu][Projektový tým]

Testovací plány

Opravy chyb Azure Test Plans

V tomto sprintu jsme provedli aktualizace plánů Azure Test, abychom vyřešili několik chyb a zlepšili použitelnost. Toto je opravené:

  • Výsledky sdílených kroků jsou viditelné: Opravili jsme chybu, kdy se výsledky sdílených kroků v editoru dotazů při přístupu k testovacím případům v New Boards Hub neobjevily.

  • Vylepšené relace v režimu stakeholderů: Vyřešili jsme problém v rozšíření pro testování a zpětnou vazbu, který blokoval uživatelům se stakeholder přístupem spuštění relací.

  • Kopírování testovacích plánů bez duplikací: Opravili jsme problém, kdy se požadavky duplikovaly při kopírování testovacího plánu s možností „Odkázat na existující testovací případy“.

Další kroky

Poznámka

Tyto funkce se budou zavádět během následujících dvou až tří týdnů.

Přejděte na Azure DevOps a podívejte se kolem.

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.

udělat návrh

Můžete také získat rady a své otázky zodpovězené komunitou na Stack Overflow.

Dík

Silviu Andrica