Beheerde DevOps-pools voor Azure DevOps (preview)

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.

Geavanceerde beveiliging van GitHub voor Azure DevOps

• Advanced Security Meter Usage API retourneert nu gebruikersidentiteiten
• GitHub Advanced Security-codescans voor C# en Java-projecten zonder builds

Azure-pipelines

• Beheerde DevOps-pools (voorvertoning)
• Azure Pipelines-taken maken gebruik van Node 20
• Samenstellingspijplijnmachtiging maken
• Exclusieve vergrendelingscontrole op faseniveau
• Sjabloongegevens in pijplijnuitvoeringen
• Handmatig geactiveerde YAML-pijplijnfasen

Geavanceerde beveiliging van GitHub 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, lijkt de syntaxis op die van de bestaande API-eindpunten voor metergebruik; voeg /details toe 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 de ondersteunde gecompileerde talen C# of Java wordt uitgekozen, 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').

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 mogelijk maken en onderhouden binnen Azure-abonnementen die eigendom zijn van Microsoft.
• Tijd 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 duizenden agents in één groep.

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 pipeline-taken maken gebruik van Node als uitvoerder. Azure Pipelines-taak die NodeJS als runner gebruikt, gebruikt 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.

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.

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 dit geval 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 controle voor exclusieve vergrendeling op die omgeving toepassen. 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 het alleen builds voor dezelfde tak runLatest annuleert, en niet voor alle takken van de pijplijn.

Sjabloongegevens in pijplijnuitvoeringen

We hebben de Pipelines Runs - Get REST API bijgewerkt met informatie over de sjablonen die zijn uitgebreid en inbegrepen 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:

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

Ga naar Azure DevOps en kijk eens.

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.

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

Bedankt

Gepleiu Andrica