Delen via

Beheerde DevOps-pools voor Azure DevOps (preview)

  • Artikel

We zijn verheugd om de preview van Beheerde DevOps-pools aan te kondigen, ontworpen om ontwikkel- en platformengineeringsteams snel aangepaste DevOps-pools in te stellen en te beheren.

Daarnaast hebben we de schattings-API's voor metergebruik voor GitHub Advanced Security verbeterd, met nieuwe mogelijkheden waarmee u gebruikers kunt identificeren.

Bekijk de releaseopmerkingen voor meer informatie.

GitHub Advanced Security voor Azure DevOps

Azure-pipelines

GitHub Advanced Security voor Azure DevOps

Advanced Security Meter Usage API retourneert nu gebruikersidentiteiten

Om u te helpen uw gebruikers van geavanceerde beveiliging te identificeren, retourneren de Api's voor metergebruik nu de Azure DevOps-identiteit van elke gebruiker, inclusief hun weergavenaam, CUID, e-mail-id en identiteitsdescriptor. Deze functie is beschikbaar op organisatie-, project- en opslagplaatsniveau. Als u dit nieuwe eindpunt wilt gebruiken, is de syntaxis vergelijkbaar met de bestaande eindpunten van de metergebruik-API, die worden toegevoegd /details aan het eindpunt:

  • Op organisatieniveau: GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Op projectniveau: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • Op het niveau van de opslagplaats: GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

GitHub Advanced Security-codescans voor C# en Java-projecten zonder builds

Codescans met CodeQL omvat het uitvoeren van query's op databases die de code in uw opslagplaats vertegenwoordigen voor één taal. Voor gecompileerde talen zoals C/C++, C#, Go, Java en Swift moet hiervoor doorgaans eerst de code worden gebouwd.

CodeQL, de statische analyse-engine achter GitHub Advanced Security voor Azure DevOps, kan nu C#- en Java-projecten scannen zonder dat er een build nodig is. Wanneer de buildmodus is ingesteld op 'geen', wordt de CodeQL-database rechtstreeks vanuit de codebasis gegenereerd, waardoor de buildstap wordt overgeslagen.

Voor alle gecompileerde talen is de standaard buildmodus 'handmatig'. Voor C# en Java kunt u de buildmodus echter wijzigen in 'geen'.

U kunt de buildmodus configureren tijdens de installatie van AdvancedSecurity-Codeql-Init@1. Zie Codescans instellen voor gedetailleerde instructies voor het configureren van codescans in GitHub Advanced Security met Azure DevOps

Overweging:

  • Als 'geen' is geselecteerd en een andere taal dan ondersteunde talen C# of Java wordt ondersteund, werkt de pijplijntaak mogelijk niet zoals verwacht.

  • De buildmodus 'none' werkt momenteel in combinatie met andere geïnterpreteerde talen (bijvoorbeeld JavaScript, Python, Ruby).

  • Geldig voorbeeld: C# en JavaScript met de buildmodus ingesteld op 'none'. (JavaScript in een geïnterpreteerde taal)

  • Ongeldig voorbeeld: C#, JavaScript en Swift met de buildmodus ingesteld op 'none' (Swift wordt niet ondersteund in de buildmodus 'none').

Schermopname van AdvancedSecurity-Codeql.

Azure-pipelines

Beheerde DevOps-pools (preview)

Technische teams excelen wanneer ze zich kunnen richten op het schrijven van code voor het ontwikkelen van toepassingen en services voor hun gebruikers. In de praktijk wordt echter vaak veel tijd besteed aan het beheren van andere taken, zoals het onderhouden van de DevOps-infrastructuur.

We zijn verheugd om de openbare preview van Beheerde DevOps-pools (MDP) aan te kondigen, een nieuwe Azure DevOps-functie die is ontworpen om ontwikkel- en platform engineeringteams te helpen aangepaste DevOps-pools te implementeren die zijn afgestemd op hun unieke behoeften. MDP combineert de flexibiliteit van schaalsetagents met het gemak van onderhoud dat is gekoppeld aan door Microsoft gehoste agents, waardoor teams consistentie en best practices kunnen vaststellen en tegelijkertijd prestaties, beveiliging, naleving en kostenefficiëntie kunnen optimaliseren.

Belangrijke voordelen van beheerde DevOps-pools zijn:

  • Gehost namens u: MDP wordt gehost en beheerd door Microsoft, met de virtuele machines die de agents aandrijven die zijn gemaakt en onderhouden binnen Azure-abonnementen die eigendom zijn van Microsoft.
  • Tijd die is besteed aan beheer: MDP vermindert de tijd die nodig is om agents te beheren, met name die op basis van on-premises infrastructuur of handmatig onderhouden systemen.
  • Specifieke pools: Vanwege het gemak waarmee nieuwe pools kunnen worden gemaakt, kunnen organisaties eenvoudig meerdere teamspecifieke of workloadspecifieke pools maken.
  • DevOps-facturering: MDP helpt bij het optimaliseren van de DevOps-factuur van een team via veel functies. Het maakt het voor teams gemakkelijk om een optimale balans te vinden tussen de QoS/prestaties en kosten van een pool.
  • Schaalbaar: MDP schaalt naar 1000 agents in één pool.

Teams kan pools maken met quickstart-installatiekopieën die dezelfde software bevatten die aanwezig is in door Microsoft gehoste agents of met installatiekopieën die het team heeft gemaakt met vereisten die uniek zijn voor hun scenario.

Lees onze blogpost of de bijbehorende documentatie voor meer informatie over Beheerde DevOps-pools.

Azure Pipelines-taken maken gebruik van Node 20

De meeste pijplijntaken maken gebruik van Node als hardloper. Azure Pipelines-taak die NodeJS als hardloper gebruikt, gebruiken nu allemaal NodeJS 20. Auteurs van taakextensies moeten hun taken bijwerken voor het gebruik van Node 20. Zie Hoe kan ik mijn aangepaste taak upgraden naar het nieuwste knooppunt voor hulp bij het upgraden.

Samenstellingspijplijnmachtiging maken

Om de beveiliging van pijplijnen te verbeteren, introduceren we een nieuwe machtiging op Create build pipelinepijplijnniveau.

Schermopname van het maken van een samenstellingspijplijnmachtiging.

Voorheen was de Edit build pipeline machtiging vereist om een pijplijn te maken of te bewerken. Dit was een beveiligingsrisico, omdat alle gebruikers met de mogelijkheid om pijplijnen te maken ook pijplijnen konden bewerken die ze niet hebben gemaakt. Het voorkomen van dit was tijdrovend.

Om uw pijplijnervaring te verbeteren zonder de beveiliging in gevaar te brengen, ontvangen alle gebruikers en groepen met de Edit build pipeline machtiging nu ook de Create build pipeline machtiging.

Wanneer een pijplijn wordt gemaakt, krijgt de maker hiervan de Edit build pipeline machtiging.

Voor verbeterde pijplijnbeveiliging kunt u ervoor kiezen om de Edit build pipeline machtiging te verwijderen uit gebruikersgroepen, zoals Inzenders en Lezers. Dit zorgt ervoor dat alleen de maker van de pijplijn deze standaard kan bewerken.

Notitie

Met de machtiging Build-pijplijn bewerken kunnen anderen geen YAML-pijplijn bewerken. De eigenschappen van de pijplijn kunnen alleen worden bewerkt.

Voor nieuwe projecten hebben gebruikers en groepen met de Edit build pipeline machtiging ook de Create build pipeline machtiging. Dit is in de toekomst onderhevig aan verandering.

Exclusieve vergrendelingscontrole op faseniveau

Voor sommige gebruiksscenario's is een pijplijn vereist om slechts één keer toegang te krijgen tot een specifieke resource op een bepaald moment. Ter ondersteuning van deze case hebben we de exclusieve vergrendelingscontrole .

Er ontstaat een vergelijkbare situatie wanneer slechts één pijplijnuitvoering op elk moment toegang moet krijgen tot een fase. Als u bijvoorbeeld een fase hebt die wordt geïmplementeerd in een Azure-resourcegroep, kunt u voorkomen dat meerdere pijplijnuitvoeringen tegelijkertijd dezelfde resourcegroep bijwerken. Op dit moment moet u hiervoor een proxyresource gebruiken, zoals een omgeving, en de exclusieve vergrendelingscontrole op die omgeving plaatsen. Deze aanpak kan tijdrovend zijn, complexiteit toevoegen en onderhoudsinspanningen verhogen.

In deze sprint introduceren we ondersteuning voor het opgeven van de exclusieve vergrendeling op faseniveau. Als u een fase met een id hebt en de eigenschap ervan lockBehavior opgeeft, wordt er automatisch een vergrendeling gemaakt voor die fase. Het sequential gedrag blijft consistent voor zowel vergrendelingen op resourceniveau als op faseniveau. Het runLatest gedrag verschilt echter, omdat er alleen builds voor dezelfde vertakking worden geannuleerd runLatest , niet voor alle vertakkingen van de pijplijn.

Sjabloongegevens in pijplijnuitvoeringen

We hebben de pijplijnenuitvoeringen bijgewerkt- REST API ophalen met informatie over de sjablonen die zijn uitgebreid en opgenomen in een pijplijnuitvoering.

Denk bijvoorbeeld aan de volgende YAML-pijplijncode:

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

De nieuwe REST API heeft de volgende nieuwe eigenschappen:

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

Handmatig geactiveerde YAML-pijplijnfasen

We ontvangen regelmatig aanvragen over handmatig geactiveerde YAML-pijplijnfasen. Dit is handig als u een uniforme pijplijn wilt, maar niet altijd wilt dat deze wordt uitgevoerd tot voltooiing.

Uw pijplijn kan bijvoorbeeld fasen bevatten voor het bouwen, testen, implementeren in een faseringsomgeving en implementeren in productie. Mogelijk wilt u dat alle fasen automatisch worden uitgevoerd, met uitzondering van de productie-implementatie, die u liever handmatig activeert wanneer u klaar bent.

Met deze sprint voegen we ondersteuning toe voor handmatig geactiveerde YAML-pijplijnfasen. Als u deze functie wilt gebruiken, moet u de trigger: manual eigenschap toevoegen aan een fase.

Bekijk het volgende YAML-pijplijnvoorbeeld:

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

Wanneer u deze pijplijn uitvoert, is de ervaring als volgt:

Schermopname van handmatig geactiveerde YAML-pijplijnfasen.

Handmatig geactiveerde fasen hebben geen afhankelijkheden en kunnen op elk gewenst moment worden uitgevoerd. De pijplijnuitvoering wordt voltooid wanneer er alleen handmatig geactiveerde fasen zijn om uit te voeren.

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 beantwoorden door de community op Stack Overflow.

Met vriendelijke groet,

Gepleiu Andrica