GitHub Enterprise-ondersteuning en automatische GitHub-serviceverbindingen in build-pijplijnen - Sprint 146 Update

In de Sprint 146-update van Azure DevOps hebben we onze GitHub-integratie met Azure Pipelines verbeterd. De nieuwe build-pijplijnwizard kan nu pijplijnen maken voor GitHub Enterprise repositories. Uw opslagplaats wordt ook geanalyseerd om een voorgestelde taalsjabloon te bieden. Daarnaast kunt u serviceverbindingen maken en opnieuw gebruiken voor de GitHub-opslagplaatsen die u selecteert.

Bekijk de functies lijst hieronder voor meer informatie.

Features

Algemeen:

• Verwijderde projecten herstellen

Azure Boards:

• Vereenvoudig de organisatie van uw werk met behulp van het Basic-proces

Azure Pipelines:

• GitHub Enterprise-ondersteuning in de pijplijnwizard
• Automatische GitHub-serviceverbindingen in pijplijnen
• Status weergeven voor elke pijplijnjob in GitHub Checks
• Standaardautorisatie voor YAML-resources in GitHub
• Servicecontainers voor YAML-pijplijnen
• Werkitems die zijn gekoppeld aan GitHub-commits in Releaseoverzicht
• Nieuwe Azure App Service-taken die zijn geoptimaliseerd voor YAML
• Ondersteuning voor Verificatie van Azure Active Directory (AD) voor Azure SQL-taken
• Servicehook van Grafana-aantekeningen
• Azure Monitor-waarschuwingentaken opvragen
• Inline-invoer van spec-bestand in De taak Implementeren in Kubernetes
• Docker CLI Installer-taak
• Langetermijnondersteuning voor Java (LTS) op door Microsoft gehoste agents
• YAML-ondersteuning voor Bitbucket Cloud-pijplijnen
• Voorkomen dat meerdere CI-builds worden geactiveerd voor pull-aanvragen
• Buildnummers wijzigen, artefacten uploaden en downloaden in builds van geforkte repositories
• Nieuwe optie in de taak Testresultaten publiceren om de build te laten falen bij mislukte tests
• Updates voor Azure Portal voor het maken van een Azure DevOps-project
• Azure Portal gebruiken om een CosmosDB-database in te stellen en te implementeren
• Builds en releasepipelines instellen voor Functions in Azure Portal

Azure Artifacts:

• Gebruiksstatistieken van pakketten

Wiki:

• Monospaced lettertype voor Wiki Markdown-editor
• Vette titels van wikipagina's
• Markdown-tabel invoegen
• Queryresultaten van Azure Boards insluiten in Wiki-

General

Verwijderde projecten herstellen

In deze update hebben we de mogelijkheid toegevoegd om verwijderde projecten te herstellen vanuit de Azure DevOps-portal. Als u de machtiging Project verwijderen hebt, kunt u ook een verwijderd project herstellen op de overzichtspagina organisatie-instellingen>.

Azure Boards

Vereenvoudig de organisatie van uw werk met het Basic-proces

In het verleden is Agile het standaardproces voor nieuwe projecten, dat een robuuste en flexibele set werkitemtypen en -statussen biedt voor een verscheidenheid aan projectleveringsmethoden. Voor sommige teams, die meer bekend zijn met andere hulpprogramma's of die groeien en een krachtigere set hulpprogramma's willen gebruiken, willen ze snel aan de slag gaan met terminologie waarmee ze vertrouwder zijn.

Het nieuwe Basic-proces biedt drie typen werkitems (Epics, Issues en Taken) om uw werk te plannen en bij te houden. We raden u aan problemen te gebruiken om zaken zoals gebruikersverhalen, bugs en functies bij te houden terwijl u Epics gebruikt om problemen samen te groeperen in grotere werkeenheden. Terwijl u met uw werk vordert, verplaatst u items langs een eenvoudige workflow voor taken: To-Do, In uitvoering, en Voltooid.

Zie de documentatie over het bijhouden van issues en taken om u te helpen beginnen met uw nieuwe project.

Azure-pipelines

GitHub Enterprise-ondersteuning in de pijplijnwizard

Voorheen kon u de visualontwerper gebruiken om pijplijnen te maken voor GitHub Enterprise-opslagplaatsen. U kunt nu ook de wizard Nieuwe build-pijplijn gebruiken om uw pijplijnen te maken.

De wizard analyseert uw GitHub Enterprise-opslagplaats om een YAML-sjabloon voor te stellen die overeenkomt met uw projecttaal. U kunt de YAML vervolgens bewerken en opslaan als een directe doorvoering naar uw standaardbranch of als een pull-aanvraag.

Zie de documentatie over het maken van uw eerste pijplijn hier voor meer informatie.

Automatische GitHub-serviceverbindingen in pijplijnen

Wanneer u de wizard Nieuwe build-pijplijn gebruikt om een pijplijn voor GitHub te maken, heeft de pagina voor het kiezen of maken van een GitHub-serviceverbinding tot verwarring geleid over welke verbinding uit de lijst moet worden geselecteerd. U hoeft nu geen verbinding te kiezen. De wizard maakt en gebruikt automatisch een serviceverbinding voor de opslagplaats die u kiest.

Als u handmatig een andere verbinding wilt kiezen dan de verbinding die automatisch wordt geselecteerd, volgt u de hyperlink Verbinding kiezen. Zie GitHub-opslagplaatsen bouwen voor meer informatie.

Weergave van status voor elke pijplijntaak in GitHub Checks

Voorheen werd één buildstatus gepost op GitHub Controles voor uw pijplijn, zelfs als deze taken voor meerdere platforms bevat (bijvoorbeeld Linux, macOS en Windows). Nu wordt de status op GitHub Checks geplaatst voor elke taak in de pijplijn. Daarnaast kunt u de volledige build of alleen afzonderlijke mislukte taken opnieuw uitvoeren vanuit GitHub-controles. Als u deze functionaliteit wilt gebruiken, moet uw pijplijn zijn geconfigureerd voor het gebruik van de GitHub-app van Azure Pipelines. Zie Integreren met behulp van de GitHub-app voor meer informatie. Zie Een pijplijn met meerdere platformen maken om een pijplijn op te zetten met taken voor meerdere platforms.

Standaardautorisatie voor YAML-resources in GitHub

Als u uw broncode beheert in GitHub en YAML gebruikt om uw pijplijn te definiëren, is er waarschijnlijk een fout opgetreden bij het bouwen van resourceautorisatie. Wanneer u het YAML-bestand bewerkt en een verwijzing hebt toegevoegd naar een van de beveiligde resources (bijvoorbeeld serviceverbinding, agentgroep, variabele groep of beveiligd bestand), kan Azure Pipelines de identiteit van de gebruiker die die wijziging heeft aangebracht, niet valideren en mislukte build. Om dit probleem te omzeilen, moest u de build-pijplijn opslaan in de webeditor nadat u een wijziging hebt aangebracht in het YAML-bestand. Veel van de gebruikers die dit probleem hebben ondervonden, wilden simpelweg dat alle pijplijnen de bron kunnen gebruiken.

Om de buildfout bij resource-autorisatie te voorkomen, hebben we het standaardgedrag van alle nieuwe serviceverbindingen, agentgroepen en variabelegroepen gewijzigd zodat ze voor gebruik in alle pijplijnen worden geautoriseerd. Als u meer besturingselementen voor uw resources wilt, kunt u het standaardautorisatiemodel uitschakelen (zie de onderstaande afbeelding). Wanneer u dit doet, moet iemand met machtigingen voor het gebruik van de resource de pijplijn opslaan in de webeditor nadat een resourcereferentie is toegevoegd aan het YAML-bestand.

Servicecontainers voor YAML-pijplijnen

Voorheen moest u services zoals databases of geheugencaches installeren, starten en stoppen als uw YAML-pijplijn deze services gebruikte. Met deze update hebben we servicecontainers toegevoegd die deze taken kunnen verwerken. Als uw pijplijn bijvoorbeeld gebruikmaakt van een redis-cache voor integratietests, kunt u de redis-containerafbeelding als service toevoegen aan de pijplijn. De agent haalt de image automatisch op, start deze, en verbindt deze met het netwerk zodat uw pijplijnstappen ernaar kunnen verwijzen door de hostnaam redis. Wanneer de pijplijn is voltooid, maakt de agent de servicecontainer schoon.

Werkitems die zijn gekoppeld aan GitHub-commits in het releaseoverzicht

In december hebben we de mogelijkheid geïntroduceerd om GitHub-doorvoeringen te koppelen aan werkitems. We zijn verheugd om aan te kondigen dat u nu alle Azure Boards-werkitems kunt zien die zijn gekoppeld aan GitHub-doorvoeringen op de overzichtspagina van de release. Dit zal teams helpen bij het volgen en ophalen van meer informatie over de commits die zijn uitgerold naar een omgeving.

Nieuwe Azure-app-servicetaken die zijn geoptimaliseerd voor YAML

We ondersteunen nu vier nieuwe taken die een eenvoudige maar krachtige manier bieden om Azure App Services te implementeren met moderne ontwikkelaars in gedachten. Deze taken hebben een geoptimaliseerde YAML-syntaxis, waardoor het eenvoudig en intuïtief is om implementaties te maken in Azure AppServices, waaronder WebApps, FunctionApps voor Containers en FunctionApp for Containers op zowel Windows- als Linux-platforms.

We ondersteunen ook een nieuwe hulpprogrammataak voor bestandstransformatie en het vervangen van variabelen voor XML- en JSON-indelingen.

Ondersteuning voor verificatie van Azure Active Directory (AD) voor Azure SQL-taak

De Azure SQL-taak is uitgebreid ter ondersteuning van het maken van verbinding met een database met behulp van Azure AD (geïntegreerd & wachtwoord) en een verbindingsreeks naast de bestaande ondersteuning voor SQL-serververificatie.

Servicehook voor Grafana-annotaties

We ondersteunen nu een nieuwe servicehook waarmee u Grafana-aantekeningen kunt toevoegen voor implementatie voltooid gebeurtenissen aan een Grafana-dashboard. Hiermee kunt u implementaties correleren met de wijzigingen in metrische gegevens van toepassingen of infrastructuur die worden gevisualiseerd in een Grafana-dashboard.

Azure Monitor-waarschuwingstaken opvragen

De vorige versie van de Query Azure Monitors-taak ondersteunde alleen het opvragen van waarschuwingen in de klassieke monitorervaring. Met deze nieuwe versie van de taak kunt u query's uitvoeren op waarschuwingen over de geïntegreerde bewakingservaring die onlangs is geïntroduceerd door Azure Monitor.

Inline invoer van specificatiebestand in Deploy naar Kubernetes-taak

Voorheen moest u voor de Kubernetes-implementatietaak een bestandspad voor de configuratie opgeven. U kunt nu ook de configuratie in de tekst toevoegen.

Docker CLI Installer-taak

Met deze taak kunt u elke versie van Docker CLI installeren op de agents zoals opgegeven door de gebruiker.

Java langetermijnondersteuning (LTS) op door Microsoft gehoste agents

Voorheen hadden door Microsoft gehoste agents JDK's vooraf geïnstalleerd die overbelast waren door complexe licenties, beperkingen voor eindgebruikers en gebrek aan langetermijnondersteuning. In deze update hebben we de JDK's vervangen door geteste, gecertificeerde LTS-builds van OpenJDK van Azul Systems. Java-ontwikkelaars die Azure gebruiken, kunnen nu productie-Java-toepassingen bouwen en uitvoeren met behulp van Azul Systems Zulu Enterprise-builds van OpenJDK zonder dat er extra ondersteuningskosten in rekening worden gebracht.

Deze nieuwe aanbieding is ontworpen om door Microsoft gehoste Java-builds en -implementaties zorgeloos te maken door zo nodig driemaandelijkse beveiligingsupdates en oplossingen voor fouten en kritieke out-of-band-updates en patches op te nemen. Als u momenteel on-premises of met andere JDK's Java-apps bouwt of uitvoert, kunt u overwegen om over te stappen naar Zulu in Azure voor gratis ondersteuning en onderhoud. Voor meer informatie, zie de blog Microsoft en Azul Systems brengen gratis Java LTS-ondersteuning naar Azure.

YAML-ondersteuning voor Bitbucket Cloud-pijplijnen

Voorheen bieden YAML-pijplijnen geen ondersteuning voor Bitbucket Cloud. Nu kunt u YAML gebruiken om uw Bitbucket Cloud-pijplijnen te definiëren of de visualontwerper gebruiken om hetzelfde te doen. Als u YAML wilt gebruiken, voegt u een azure-pipelines.yml-bestand toe aan uw opslagplaats. Kies in Azure Pipelines Nieuwe build-pijplijn en selecteer vervolgens de hyperlink De visualontwerper gebruiken, selecteer Bitbucket Cloud en YAML. Hier kunt u het pad naar het YAML-bestand van uw opslagplaats invoeren.

Zie de YAML-syntaxishandleiding en de GitHub-opslagplaats van YAML-voorbeelden voor meer informatie.

Voorkom activering van meerdere CI-builds voor pull requests

De YAML-buildsjablonen die zijn opgenomen in Azure Pipelines, zijn geconfigureerd voor het activeren van builds voor elke vertakking in een opslagplaats. Dit omvat vertakkingen voor pull-aanvragen. Als gevolg hiervan werden twee builds geactiveerd wanneer pull-aanvragen werden gemaakt. Eén build voor de pull request branch als reactie op de CI-trigger en een tweede build voor de pull request branch als reactie op de pull request trigger.

Met behulp van het ONDERSTAANDe YAML-fragment worden de ingebouwde YAML-sjablonen geconfigureerd om alleen een continue integratiebuild te activeren voor de hoofdvertakking . Nieuwe pull-aanvragen worden nog steeds gemaakt met behulp van de pull-aanvraagtrigger. Zie de documentatie voor build-pijplijntriggers voor meer informatie.

trigger:
- main

Buildnummers wijzigen, artefacten uploaden en downloaden voor builds van geforkte repositories

Tot nu toe hadden builds voor pull-aanvraagvalidatie van geforkte opslagplaatsen geen toestemming om buildartefacten te uploaden of downloaden, noch om het buildnummer te wijzigen. Machtigingen zijn beperkt omdat het onveilig was om de bredere machtigingen van de agent beschikbaar te maken tijdens een fork-build die wordt geactiveerd door een onbekende gebruiker. Met deze update zijn de rechten van agenten gedefinieerd, zodat uw pijplijn deze bewerkingen kan uitvoeren indien nodig.

Hieronder ziet u een voorbeeld van de YAML die u kunt gebruiken om build-uitvoer in een tar.gz-bestand te archiveren in de map voor fasering van artefacten. Vervolgens wordt de uitvoer gepubliceerd naar Azure Pipelines die aan de build moet worden gekoppeld. Zie de documentatie over de taak Archiefbestanden en de taak BuildArtefacten publiceren voor meer informatie.

- task: ArchiveFiles@2
  inputs:
    archiveType: 'tar'
    tarCompression: 'gz'
    includeRootFolder: false
    rootFolderOrFile: '$(build.sourcesDirectory)/target'
    archiveFile: '$(build.artifactStagingDirectory)/$(build.buildId).tar.gz'
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(build.artifactStagingDirectory)'

Nieuwe optie bij de taak 'Testresultaten publiceren' om de build te laten falen bij mislukte tests.

De taak Testresultaten publiceren wordt gebruikt om testresultaten te publiceren naar Azure Pipelines wanneer tests worden uitgevoerd met behulp van uw keuze voor testrunner. Tot nu toe zou de taak gewoon resultaten publiceren uit een resultatenbestand en zou de build niet mislukken, zelfs niet als het resultatenbestand mislukte tests bevatte. Dit betekende dat u aangepaste stappen moest schrijven om de build te laten mislukken bij testfouten.

We hebben nu een optie toegevoegd in de taak om de build te laten mislukken als er mislukte tests zijn.

Updates voor Azure Portal voor het maken van een Azure DevOps-project

Azure Portal bevat nu extra functionaliteit ter ondersteuning van meer frameworks en services bij het maken van een Azure DevOps-project. Hieronder ziet u de lijst met wijzigingen voor elk gebied.

Framework

Azure IoT is een volledig beheerde service die cloudintelligentie lokaal levert op platformoverschrijdende IoT-apparaten. U kunt nu een Azure DevOps-project maken vanuit Azure Portal en de Eenvoudige IoT gebruiken als het toepassingsframework.

Service

Voorheen ondersteunde de werkstroom 'Azure DevOps-project maken' in de Azure Portal alleen Nieuwe maken als optie voor de Kubernetes-dienst. Er is een nieuwe optie toegevoegd waarmee u een bestaand cluster kunt kiezen als het implementatiedoel voor de installatie van de pijplijn.

Azure Portal gebruiken om een CosmosDB-database in te stellen en te implementeren

Op dit moment kunt u de Azure DevOps Project-werkstroom in Azure Portal gebruiken om build- en release-pijplijnen in te stellen voor een Git-opslagplaats. U kunt nu implementeren in Azure Web App for Containers (Linux) of Azure Kubernetes Service met een CosmosDB die is ingericht als database voor de apps op deze doelen. Dit is momenteel beschikbaar voor alle Node.js sjablonen en we verwachten in de toekomst ondersteuning voor andere sjablonen toe te voegen.

Buildprocessen en release-pipelines instellen voor Functies in Azure Portal

U kunt nu de Azure DevOps Project-werkstroom in Azure Portal gebruiken om build- en release-pijplijnen in te stellen voor Git-opslagplaats die Azure Functions 2.0 (Windows) implementeren. Dit is functionaliteit beschikbaar voor Node.js en .NET Core.

Azure Artifacts

Gebruiksstatistieken van pakketten

Tot nu toe biedt Azure Artifacts geen manier om het gebruik of de populariteit van pakketten te meten. Met deze update hebben we het aantal Downloads en Gebruikers toegevoegd aan zowel de pakketlijstpagina's als de pakketgegevenspagina's. U kunt de statistieken aan de rechterkant van een van beide pagina's zien.

Wiki

Monospaced lettertype voor Wiki Markdown-editor

Met de introductie van monospaced lettertypen voor wiki Markdown-editor is leesbaarheid geen uitdaging meer. De Markdown-bron ziet er schoon en gemakkelijk te lezen uit. Deze functie heeft prioriteit gekregen op basis van dit suggestieticket.

Titels van wikipagina's vetmaken

Eerder zagen zowel de titel van de wikipagina als koptekst 1 er hetzelfde uit. Dit maakte het moeilijk voor lezers om onderscheid te maken tussen hen. Nu zijn de wikipaginatitels in vet weergegeven en onderscheiden van Koptekst 1. Deze functie heeft prioriteit gekregen op basis van dit suggestieticket.

Markdown-tabel invoegen

Het maken van Markdown-tabellen in een wiki is geen uitdaging meer. U kunt nu een Markdown-tabel toevoegen met een klik op een knop. Deze functie heeft prioriteit gekregen op basis van dit ticket voor functiesuggesties.

Queryresultaten van Azure Boards insluiten in Wiki

U kunt nu queryresultaten van Azure Boards insluiten op een wikipagina in de vorm van een tabel. In de onderstaande afbeelding ziet u een voorbeeld van een wikipagina met een lijst met alle functies die zijn uitgebracht en alle actieve bugs in de huidige sprint die in de wiki zijn ingesloten. De inhoud die op de pagina wordt weergegeven, maakt gebruik van een bestaande werkitemquery. Met deze nieuwe functie kunt u dynamische inhoud maken en hoeft u zich geen zorgen te maken over het handmatig bijwerken van de wikipagina.

De queryresultaten kunnen in twee stappen worden toegevoegd

1. Klik op de knop Opvraagresultaten op de bewerkbalk.

2. Selecteer de vereiste query en klik op de knop Invoegen.

De resultaten van de query kunnen nu worden weergegeven in de vorm van een tabel nadat u de pagina hebt opgeslagen.

Dit heeft prioriteit gekregen op basis van de volgende suggesties voor functies:

1. Query's voor werkitems in de Wiki
2. Dynamische wiki-inhoud toevoegen

Volgende stappen

Lees meer over de nieuwe functies hieronder en ga naar Azure DevOps om ze voor uzelf te proberen.

Feedback geven

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

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

Bedankt

Jeremy Epling