Delen via

Verbeterde beveiligings- en pijplijnwerkstromen

  • Artikel

Met deze sprint verbeteren we uw DevOps-werkstroom met meer zichtbaarheid van beveiliging en gestroomlijnde pijplijnwerkstromen. GitHub Advanced Security bevat nu gedetailleerde tracering van activeringen voor afhankelijkheidsscans, codescansen geheime scans, waardoor er meer inzicht is in de beveiligingsdekking van uw organisatie.

Daarnaast introduceren we graag verbeteringen die gericht zijn op pijplijnen, waaronder nieuwe YAML-expressiefuncties en uitgebreide besturingselementen voor handmatige validatietaken, zodat u efficiëntere en veilige werkstromen kunt maken.

Bekijk de releaseopmerkingen voor meer informatie.

GitHub Advanced Security voor Azure DevOps

Azure Boards:

Azure Repos

Azure Pipelines

Testplannen

GitHub Advanced Security voor Azure DevOps

Dekking van specifiek beveiligingsoverzicht voor hulpprogramma's

Het beveiligingsoverzicht in GitHub Advanced Security for Azure DevOps biedt nu een gedetailleerde uitsplitsing van de activeringsstatus voor elk scanprogramma, waaronder afhankelijkheidsscans, codescansen geheime scan. Met deze uitbreiding kunt u gedetailleerde activeringsstatussen bekijken in alle opslagplaatsen in uw organisatie.

schermopname van het beveiligingsoverzicht.

Zie Beveiligingsoverzicht voor Advanced Securityvoor meer informatie.

Azure Boards

Integratie van Azure Boards met GitHub Enterprise Cloud met Data Residency

Azure Boards ondersteunt nu integratie met GitHub Enterprise Cloud-organisaties waarvoor gegevenslocatie is ingeschakeld. Deze update komt overeen met GitHub's aankondiging van september 2024 de introductie van gegevenslocatie voor Enterprise Cloud-klanten, beginnend met die in de Europese Unie (EU).

Een Azure Boards-project verbinden met uw GitHub Enterprise Cloud-organisatie voor gegevensresidentie:

  1. Maak een nieuwe verbinding in Azure Boards.

Schermopname van verbinding maken met GitHub met borden.

  1. Selecteer de optie GitHub Enterprise Cloud met gegevenslocatie.

Schermopname van een nieuwe GitHub-verbinding.

Azure Repos

Sparse-betaling voor Azure-opslagplaatsen

De opdracht git sparse-checkout wordt nu ondersteund in de YAML-checkout-taak, naast het gedeeltelijke kloonfilter, om de prestaties van het uitchecken van repositories te verbeteren. U kunt de eigenschappen sparseCheckoutDirectories en sparseCheckoutPatternsgebruiken.

Als u sparseCheckoutDirectories instelt, wordt de kegelmodus ingeschakeld, waarbij het betalingsproces gebruikmaakt van adreslijstkoppeling. U kunt ook sparseCheckoutPatterns instellen die niet-kegelmodus activeert, waardoor complexere patroonkoppeling mogelijk is.

Als beide eigenschappen zijn ingesteld, initialiseert de agent de conemodus met mapkoppeling. Als geen van beide eigenschappen is opgegeven in de uitchecktaak, is het sparse-uitcheckproces uitgeschakeld. Eventuele problemen die zijn opgetreden tijdens het uitvoeren van opdrachten, resulteren in het falen van de uitchecktaak.

YAML-voorbeeld voor de sparse checkout-conemodus:

    checkout: repo
    sparseCheckoutDirectories: src

YAML-voorbeeld voor het parseren van de niet-kegelmodus:


   checkout: repo
   sparseCheckoutPatterns: /* !/img

Belangrijk

De sparse checkout-functie vereist agent v3.248.0 (v4.248.0 voor .NET 8) of latere versies.

U vindt de agent op de pagina releases.

Beleidsregels voor meerdere opslagplaatsen hoofdlettergevoelig maken

Voorheen werden in de voorbeeldweergave van de vertakkingskandidaat voor cross-repository beleidsregels de resultaten ongevoelig voor hoofdletters weergegeven, ondanks dat vertakkingsmatching hoofdlettergevoelig is. Deze inconsistentie creëerde een potentieel misverstand, omdat het zou kunnen lijken dat bepaalde vertakkingen werden beschermd toen ze dat niet waren. Om dit probleem op te lossen, hebben we de preview van het takpatroon bijgewerkt om deze af te stemmen op het hoofdlettergevoelige gedrag van de beleidsimplementatie.

Eerder:

Schermafbeelding van voor de oplossing

Na:

screenshot na reparatie.

Azure Pipelines

Nieuwe pijplijnexpressiefuncties

Met pijplijnexpressiefuncties kunt u krachtige YAML-pijplijnen schrijven. In deze sprint hebben we twee nieuwe functies geïntroduceerd:

  • iif(condition, value_when_true, value_when_false) die value_when_true retourneert wanneer condition uitkomt op true of value_when_false, anders

  • trim(string) die een nieuwe tekenreeks retourneert waarin witruimten aan het begin en einde van de tekenreeks worden verwijderd

U kunt bijvoorbeeld de functie iif gebruiken om dynamisch een pool te selecteren voor het uitvoeren van uw pijplijn. Als u pull-aanvragen wilt maken met behulp van de Azure Pipelines-pool, maar alle andere uitvoeringen een Beheerde DevOps-pool moeten gebruiken, kunt u de volgende pijplijn schrijven.

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'

U kunt de functie trim gebruiken om uw YAML toleranter te maken voor gebruikersinvoer. In de volgende pijplijn gebruiken we bijvoorbeeld de functie trim om ervoor te zorgen dat de fasenaam niet begint met spaties.

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)}}

Verbeteringen aan de taak ManualValidation

Met de ManualValidation-taak kunt u een pijplijnrun onderbreken en wachten op handmatige tussenkomst. Een scenario voor het gebruik van deze taak is handmatig testen.

Als u de beveiliging van uw pijplijn wilt verbeteren, wilt u mogelijk beperken wie de taak kan voltooien en de pijplijnuitvoering kan hervatten. Daarom introduceren we een nieuwe versie van de taak die twee extra parameters biedt:

  • approvers: beperken wie de taak kan voltooien tot een vooraf gedefinieerde set gebruikers/beveiligingsgroepen/teams

  • allowApproversToApproveTheirOwnRuns: de gebruiker die de pijplijnuitvoering in de wachtrij heeft geplaatst, verbieden van het hervatten van de pijplijnuitvoering

Het volgende YAML-fragment beperkt bijvoorbeeld de set van personen die de pijplijn kunnen hervatten tot leden van de groep "Release Goedkeurders," maar niet de gebruiker die de pijplijn gestart heeft.

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

In de eigenschap approvers kunt u de volgende waarden (door komma's gescheiden) gebruiken:

  • E-mailadres
  • Machtigingsgroep,
  • Projectteam
  • [ProjectName][Machtigingsgroep],
  • [Org][Machtigingsgroep],
  • [ProjectName][Projectteam]

Testplannen

Bugfixes voor Azure-testplannen

Met deze sprint hebben we updates aangebracht in Azure Test Plans om verschillende bugs op te lossen en de bruikbaarheid te verbeteren. Dit is opgelost:

  • resultaten van gedeelde stappen zichtbaar: er is een fout opgelost waarbij de resultaten van gedeelde stappen niet in de query-editor zouden worden weergegeven bij het openen van testcases in de New Boards Hub.

  • Verbeterde sessies in de belanghebbendemodus: Een probleem opgelost in de test- en feedbackextensie waarmee gebruikers met toegang tot belanghebbenden geen sessies meer kunnen starten.

  • Verbeterd kopiëren van testplannen: Probleem opgelost waarbij vereisten werden gedupliceerd bij het kopiëren van een testplan met de optie "Bestaande testcases verwijzen".

Volgende stappen

Notitie

Deze functies worden de komende twee tot drie weken uitgerold.

Ga naar Azure DevOps en kijk eens.

Ga naar Azure DevOps-

Feedback geven

We horen graag wat u van deze functies vindt. Gebruik het Help-menu om een probleem te melden of een suggestie op te geven.

een suggestie doen

U kunt ook advies krijgen en uw vragen beantwoord door de community op Stack Overflow.

Bedankt

Silviu Andrica