Releaseopmerkingen voor Team Foundation Server 2018 Update 2

Ontwikkelaarscommunity | Systeemvereisten en compatibiliteit | Licentiebepalingen | TFS DevOps-blog | SHA-1 Hashes | | Meest recente opmerkingen bij de release van Visual Studio 2019

In dit artikel vindt u informatie over de nieuwste versie voor Team Foundation Server 2018. Klik op de knop om te downloaden.

Voor meer informatie over Team Foundation Server 2018 raadpleegt u de pagina Vereisten compatibiliteitsvereisten voor Team Foundation Server. Ga naar de pagina visualstudio.com/downloads om andere TFS 2018-producten te downloaden.

Directe upgrade naar Team Foundation Server 2018 Update 2 wordt ondersteund vanuit TFS 2012 en hoger. Als uw TFS-implementatie zich op TFS 2010 of eerder bevindt, moet u enkele tussentijdse stappen uitvoeren voordat u een upgrade uitvoert naar TFS 2018 Update 2. Zie de onderstaande grafiek en de tfs-installatiepagina voor meer informatie.

Releasedatum: 7 mei 2018

U kunt nu upgraden naar TFS 2018 Update 2 en uw XAML-controllers blijven verbinden en XAML-builds uitvoeren. Toen we ondersteuning voor XAML-build in TFS 2018 RTW en Update 1 hebben verwijderd, konden sommigen niet upgraden vanwege verouderde XAML-builds en we willen de blokkering van u opheffen. Hoewel TFS 2018 Update 2 XAML-builds ondersteunt voor uw oudere builds, wordt XAML-build afgeschaft en is er geen verdere investering meer, dus we raden u ten zeerste aan om te converteren naar een nieuwere builddefinitieindeling.

Samenvatting van wat is er nieuw in TFS 2018 Update 2

We hebben veel nieuwe waarde toegevoegd aan Team Foundation Server 2018 Update 2. Enkele van de hoogtepunten zijn:

• Samenvoegingscommit van pull request weergeven
• Revisoren helpen bij het gebruik van labels voor pull-aanvragen
• Een pull-aanvraag vermelden
• Meldingen over opmerkingen op pull-aanvragen bevatten de threadcontext
• Uitbreidbaarheid van pull-aanvraagstatus
• Aangepaste velden en tags filteren in meldingen voor het bijhouden van werkitems
• Gemoderniseerde kolomopties
• Ondersteuning toegevoegd voor Niet-In query-operator
• Query for @MyRecentActivity and @RecentMentions
• Filteren op abonnementen
• Poorten vrijgeven
• Bouwen met continue integratie vanuit GitHub Enterprise
• Verbeteringen aan builds met meerdere fasen
• Geplande builds overslaan als er niets is gewijzigd in de opslagplaats
• Openbare pakketten naadloos gebruiken met behulp van upstream-bronnen
• Bewaarbeleid in TFS-feeds
• Filteren in pakketbeheer
• Wiki zoeken
• Naslagwerkitems in Wiki
• Voorbeeld van inhoud tijdens het bewerken van wikipagina's
• Uitgebreide Wiki-inhoud plakken als HTML
• Profielkaarten
• Cirkelvormige avatars

Details van wat er nieuw is in TFS 2018 Update 2

Meer informatie over functies vindt u in elk gebied:

• Code
• Werk
• Build en Release
• Pakket
•   Testen
• Wiki
• Algemeen

Code

Een permanente link naar code verkrijgen

Wanneer u een bestand bekijkt, ziet u meestal de versie aan de kop van de geselecteerde tak. De versie van een bestand op de tip kan worden gewijzigd met nieuwe doorvoeringen. Als u een koppeling uit deze weergave kopieert, kunnen uw koppelingen verlopen omdat de URL alleen de naam van de vertakking bevat, niet de doorvoer-SHA. U kunt nu eenvoudig overschakelen naar de weergave Bestanden om de URL bij te werken zodat deze verwijst naar de commit in plaats van de branch. Als u op de toets "y" drukt, schakelt de weergave over naar de laatste commit van de huidige branch. Vervolgens kunt u permanente koppelingen kopiëren.

Een onlangs verwijderde opslagplaats herstellen via API

Soms kunnen er fouten worden gemaakt bij het opschonen van oude opslagplaatsen in broncodebeheer. Als een Git-opslagplaats binnen de afgelopen 30 dagen wordt verwijderd, kan deze worden hersteld via de REST API. Zie de documentatie voor de lijst en herstelbewerkingen voor meer informatie.

SSH: ondersteuning voor extra coderingen/sleutels en verouderde coderingen verwijderen

Om de beveiliging en compatibiliteit te verbeteren, hebben we de lijst met coderingen bijgewerkt die worden ondersteund voor SSH. We hebben twee nieuwe coderingen toegevoegd en drie afgeschaft, die overeenkomen met de richting van OpenSSH. De afgeschafte coderingen blijven in deze release werken. Ze worden in de toekomst verwijderd wanneer het gebruik uitvalt.

Toegevoegd:

• AES128 CTR
• AES256 CTR

Verouderd:

• AES128
• AES192
• AES256

Vermijd overschrijvingen en bescherm de prestaties met behulp van repository-instellingen.

In deze update vindt u twee nieuwe opslagplaatsinstellingen om Git soepel te laten werken.

Met het afdwingen van aanvragen wordt de server overgeschakeld van de standaard hoofdlettergevoelige modus, waarbij 'File.txt' en 'file.txt' naar hetzelfde bestand verwijzen, naar een windows- en macOS-vriendelijke modus waarbij 'File.txt' en 'file.txt' hetzelfde bestand zijn. Deze instelling is van invloed op bestanden, mappen, vertakkingen en tags. Het voorkomt ook dat inzenders per ongeluk verschillen die alleen de lettergrootte betreffen introduceren. Het inschakelen van het afdwingen van cases wordt aanbevolen wanneer de meeste inzenders Windows of macOS uitvoeren.

Met maximale bestandsgrootten kunt u voorkomen dat nieuwe of bijgewerkte bestanden een groottelimiet overschrijden die u hebt ingesteld. Hoe groter het aantal grote bestanden in de geschiedenis van een Git-opslagplaats, hoe erger de kloon- en ophaalbewerkingsprestaties worden. Deze instelling voorkomt onbedoelde introductie van deze bestanden.

Verbeterde filtermogelijkheden voor commits waarbij meer dan 1000 bestanden zijn gewijzigd

Het zoeken naar een bestand in commits of pull-verzoeken die meer dan 1000 bestanden hebben gewijzigd, was inefficiënt; u moet meerdere keren op de Meer laden-link klikken om het bestand te vinden waarin u geïnteresseerd was. Wanneer u nu inhoud filtert in de structuurweergave, wordt het zoeken naar dat bestand uitgevoerd over alle bestanden in de commit in plaats van alleen de bovenste 1000 geladen bestanden. De prestaties van de pagina met doorvoerdetails worden ook verbeterd wanneer er meer dan 1000 bestanden zijn gewijzigd.

Verloren commits vinden door een geforceerde push

U kunt een Git force push uitvoeren en een externe ref bijwerken, zelfs als het geen voorouder van de lokale ref is. Dit kan ertoe leiden dat anderen doorvoeringen verliezen en het kan erg moeilijk zijn om de hoofdoorzaak te identificeren. In de nieuwe pushes-weergave hebben we force pushes zichtbaar gemaakt om te helpen bij het oplossen van problemen met betrekking tot ontbrekende commits.

Als u op de force push-tag klikt, gaat u naar de verwijderde commit.

De schuld is nu geschiedenis

De Blame-weergave is ideaal voor het identificeren van de laatste persoon die een coderegel heeft gewijzigd. Soms moet u echter weten wie de vorige wijziging heeft aangebracht in een coderegel. De nieuwste verbetering van de schuld kan helpen - De schuld bekijken voorafgaand aan deze doorvoering. Zoals de naam al aangeeft, kunt u met deze functie teruggaan naar de versie van het bestand vóór de versie die een bepaalde regel heeft gewijzigd en de informatie over de schuld voor die versie bekijken. U kunt verder inzoomen op elke versie van het bestand dat de geselecteerde coderegel heeft gewijzigd.

Schakel tekstterugloop en witruimte in verschilweergaven in/uit.

Er zijn twee nieuwe functies beschikbaar in de viewer voor bestandsverschil: Tekstterugloop in- / uitschakelen en witruimte in-/uitschakelen. Met de eerste optie kan de instelling voor tekstterugloop worden toegepast in een diff-weergave. Dit is met name handig voor het beoordelen van PR's die bestanden bevatten zonder frequente regeleinden - markdown-bestanden zijn een goed voorbeeld. De optie om witruimte in te schakelen is handig wanneer alleen witruimte is gewijzigd in een regel of bestand. Als u deze instelling activeert, worden de witruimtetekens (puntjes voor spaties, pijlen voor tabstoppen, enzovoort) in de diff weergegeven en gemarkeerd.

Als u deze instellingen wilt beheren, klikt u in de pull request-editor of diff-weergave op het voorkeurenwiel. Selecteer in de weergave Bestanden de optie Gebruikersvoorkeuren in het snelmenu.

Selecteer de verschillende editorfuncties, waaronder Witruimte weergeven en diffen, Tekstterugloop inschakelen, Codevouwen inschakelen en Minimap weergeven.

Code folding ('omlijning' genoemd in sommige editors) wordt ook ingeschakeld voor de webweergave. Wanneer codevouwen is ingeschakeld, klikt u op de mintekens om secties met code samen te vouwen. Klik op plustekens om samengevouwen secties uit te vouwen. Het F1-opdrachtpalet bevat ook opties voor het vouwen van verschillende inspringingsniveaus in een heel bestand, waardoor het gemakkelijker is om grote bestanden te lezen en te controleren.

Code pushes bijhouden naar een Git-opslagplaats voor builds en releases

U kunt nu de build- en releasestatus van samenvoegingsdoorvoeren bekijken op de pagina Pushes . Door op de status naast de push te klikken, vindt u de specifieke build of release waarin de push is opgenomen, zodat u de geslaagde of mislukte bewerking kunt controleren.

Markdown weergegeven in e-mailmeldingen

Markdown is ideaal voor het toevoegen van uitgebreide opmaak, koppelingen en afbeeldingen in pull-aanvraagbeschrijvingen en opmerkingen. E-mailmeldingen voor PR's tonen nu de gerenderde Markdown in plaats van de onbewerkte inhoud, wat de leesbaarheid verbetert.

Inline-afbeeldingen worden nog niet inline gerenderd (ze worden alleen getoond als links), maar we hebben dit op onze to-do-lijst staan om in de toekomst toe te voegen.

TFVC-opdrachten rechtstreeks vanuit Windows Verkenner uitvoeren

De TFVC Windows Shell-extensie, die een lichtgewicht versiebeheerervaring biedt geïntegreerd in Windows Verkenner, ondersteunt nu TFS 2018. Dit hulpprogramma biedt handige toegang tot veel TFVC-opdrachten rechtstreeks in het contextmenu van Windows Verkenner.

Voorheen onderdeel van de TFS Power-hulpprogramma's, is het hulpprogramma uitgebracht als een zelfstandig hulpprogramma op Visual Studio Marketplace.

Bepalen wie kan bijdragen aan pull-aanvragen

Voorheen kon iedereen die een Git-opslagplaats kon bekijken, werken met de pull-aanvragen. We hebben een nieuwe machtiging toegevoegd met de naam Bijdragen aan pull-aanvragen die de toegang tot het maken en opmerkingen maken van pull-aanvragen regelen. Alle gebruikers en groepen die eerder de leesmachtiging hebben, krijgen standaard ook deze nieuwe machtiging. De introductie van deze nieuwe machtiging biedt beheerders extra flexibiliteit en controle. Als u ervoor wilt zorgen dat de groep Lezers werkelijk alleen-lezen is, kunt u de machtiging Bijdragen aan pull-aanvragen intrekken.

Zie de quickstart-documentatie voor het instellen van opslagplaatsmachtigingen voor meer informatie.

Meldingen over opmerkingen bij pull-aanvragen bevatten de threadcontext

Antwoorden op pull request-opmerkingen (PR) zijn vaak kort, waarbij wordt erkend dat er een wijziging wordt of is aangebracht. Dit is geen probleem bij het weergeven van deze opmerkingen in de webweergave, maar als u een opmerking leest in een e-mailmelding, gaat de context van de oorspronkelijke opmerking verloren. Een eenvoudige 'Ik zal het oplossen' heeft geen betekenis.

Telkens wanneer er nu een reactie wordt gegeven op een PR-opmerking, bevatten de opmerkingenmails automatisch de eerdere reacties in de hoofdtekst van het e-mailbericht. Hierdoor kunnen de threaddeelnemers rechtstreeks vanuit hun Postvak IN de volledige context van de opmerking zien. U hoeft de webweergave niet te openen.

Instellingen voor werkitems voltooien

De functie voor het voltooien van werkitems bij het voltooien van pull-aanvragen heeft nu een nieuwe opslagplaatsinstelling om het standaardgedrag te beheren. De nieuwe instelling voor Het onthouden van gebruikersvoorkeuren voor het voltooien van werkitems met pull-aanvragen is standaard ingeschakeld en respecteert de laatste status van de gebruiker bij het voltooien van toekomstige pull-aanvragen in de opslagplaats. Als de nieuwe instelling is uitgeschakeld, wordt de optie Gekoppelde werkitems voltooien na samenvoegen standaard uitgeschakeld voor alle pull-aanvragen in de opslagplaats. Gebruikers kunnen er nog steeds voor kiezen om gekoppelde werkitems over te zetten bij het voltooien van pull-aanvragen, maar ze moeten zich elke keer aanmelden.

Uitbreidbaarheid van pull-aanvraagstatus

Het gebruik van vertakkingsbeleid kan een uitstekende manier zijn om de kwaliteit van uw code te verhogen. Deze beleidsregels zijn echter beperkt tot alleen de integraties die systeemeigen worden geleverd door TFS. Met behulp van de nieuwe status-API voor pull-aanvragen en het bijbehorende vertakkingsbeleid kunnen services van derden deelnemen aan de werkstroom voor pull-aanvragen, net zoals systeemeigen TFS-functies.

Wanneer een service een bericht plaatst naar de Status API voor een pull-aanvraag, verschijnt deze onmiddellijk in de detailweergave van de pull-aanvraag in een nieuwe sectie Status. In de statussectie ziet u de beschrijving en maakt u een koppeling naar de URL die door de service wordt geleverd. Statusvermeldingen ondersteunen ook een actiemenu (...) dat kan worden uitgebreid voor nieuwe acties die door webextensies worden toegevoegd.

De status op zichzelf blokkeert de voltooiing van een pull-aanvraag niet - hier komt het beleid in beeld. Zodra de PR-status is gepubliceerd, kan een beleid worden geconfigureerd. Vanuit het branchbeleid is er een nieuw beleid beschikbaar om goedkeuring van externe diensten te vereisen. Selecteer + Service toevoegen om het proces te starten.

Selecteer in het dialoogvenster de service die de status in de lijst plaatst en selecteer de gewenste beleidsopties.

Zodra de beleidsregels actief zijn, wordt de status weergegeven in de sectie Beleidsregels, onder Vereist of Optioneel, en wordt de voltooiing van de pull request afgedwongen indien van toepassing.

Raadpleeg de documentatie en voorbeelden voor meer informatie over de status-API en om deze voor uzelf uit te proberen.

Samenvoegingsevenementen voor pull request servicehooks

Extensies met behulp van pull-aanvraagservicehook hebben nu meer details en filteropties voor samenvoegingsevenementen. Telkens wanneer een samenvoeging wordt uitgevoerd, wordt de gebeurtenis geactiveerd, ongeacht het slagen of mislukken van de samenvoeging. Wanneer een samenvoegpoging resulteert in een fout, worden details over de reden voor de fout opgenomen.

Verbeterde foutberichten voor werkitems die worden voltooid met een pull-aanvraag

Wanneer u werkitems probeert te voltooien met een pull-aanvraag, is het mogelijk dat het gekoppelde werkitem niet kan worden overgezet naar de voltooide status. Een specifiek veld kan bijvoorbeeld vereist zijn en heeft gebruikersinvoer nodig voordat de status kan worden overgegaan. We hebben de ervaring verbeterd om u te informeren wanneer iets de overgang van het werkitem blokkeert, zodat u actie kunt ondernemen om de benodigde wijzigingen aan te brengen.

Een pull-aanvraag vermelden

U kunt nu pull-aanvragen vermelden in pr-opmerkingen en discussies over werkitems. De ervaring voor het vermelden van een pull request is vergelijkbaar met die van een werkitem, maar gebruikt een uitroepteken ! in plaats van een hekje #.

Wanneer u een pull request wilt vermelden, voert u ! in, en krijgt u een interactieve omgeving te zien voor het kiezen van een pull request uit uw lijst met recente pull requests. Voer trefwoorden in om de lijst met suggesties te filteren of voer de ID in van de pull request die u wilt vermelden. Zodra een PR wordt vermeld, wordt deze inline weergegeven met de ID en de volledige titel, en wordt deze gekoppeld aan de pagina met de details van de PR.

Revisoren helpen bij het gebruik van labels voor pull-aanvragen

Soms is het belangrijk om extra informatie over een pull-aanvraag aan de revisoren te communiceren. Misschien is de pull-aanvraag nog steeds bezig of is het een hotfix voor een toekomstige release. U voegt dus extra tekst toe aan de titel, misschien een voorvoegsel '[WIP]' of 'NIET SAMENVOEGEN'. Labels bieden nu een manier om pull-aanvragen te taggen met extra informatie die kan worden gebruikt om belangrijke details te communiceren en pull-aanvragen te organiseren.

Opmerkingen bij pull-aanvragen volgen hernoemde bestanden

Soms worden bestanden hernoemd of verplaatst terwijl een pull-aanvraag actief is. Als er eerder opmerkingen waren op de bestanden waarvan de naam is gewijzigd, worden de opmerkingen niet weergegeven in de meest recente weergave van de code. We hebben nu het bijhouden van opmerkingen verbeterd voor het volgen van hernoemingen, door opmerkingen weer te geven op de nieuwste versie van hernoemde of verplaatste bestanden.

Samenvoegingsdoorvoering voor pull-aanvragen weergeven

Diff-weergaven voor pull requests zijn zeer geschikt voor het uitlichten van de wijzigingen die zijn geïntroduceerd in de bronvertakking. Echter, wijzigingen in de doelbranch kunnen ervoor zorgen dat de diff-weergave er anders uitziet dan verwacht. Er is nu een nieuwe opdracht beschikbaar om de diff van de "preview" merge-commit voor de pull-aanvraag te bekijken: Bekijk merge-commit. Deze samenvoegingsdoorvoering wordt gemaakt om te controleren op samenvoegingsconflicten en om te gebruiken met een pull-aanvraagbuild en geeft aan hoe de samenvoegingsdoorvoering eruitziet wanneer de pull-aanvraag uiteindelijk is voltooid. Wanneer de doelbranch wijzigingen bevat die niet in het diff terugkomen, kan de diff van de samenvoegcommit nuttig zijn om de meest recente wijzigingen in zowel de bron- als doelbranches te bekijken.

Een andere opdracht die handig is in combinatie met de opdracht Samenvoeging weergeven , is Samenvoegen opnieuw starten (beschikbaar in hetzelfde opdrachtmenu). Als de doelbranch is gewijzigd sinds de pull-aanvraag in eerste instantie is gemaakt, wordt met deze opdracht een nieuwe preview-merge-commit gemaakt, waarbij de merge-commit-diff-weergave wordt bijgewerkt.

Onlangs gebruikte revisoren

Als u regelmatig uw code door dezelfde personen hebt gecontroleerd, zult u het eenvoudiger dan ooit vinden om revisoren toe te voegen. Wanneer u revisoren toevoegt aan uw pull-aanvragen, wordt automatisch een lijst met onlangs toegevoegde revisoren weergegeven wanneer u de focus in het invoervak van revisoren plaatst. U hoeft niet op naam te zoeken. Selecteer ze zoals elke revisor.

Resterende beleidscriteria weergeven voor automatisch aanvullen van pull-aanvragen

Automatisch aanvullen is een handige functie voor teams die vertakkingsbeleid gebruiken, maar wanneer u optionele beleidsregels gebruikt, kan het onduidelijk zijn wat een pull-aanvraag blokkeert. Nu, wanneer u automatisch aanvullen instelt voor een pull-verzoek, wordt de exacte lijst met beleidscriteria die de voltooiing tegenhouden duidelijk vermeld in het uitroepvak. Wanneer aan elke vereiste wordt voldaan, worden items uit de lijst verwijderd totdat er geen resterende vereisten zijn en de pull-aanvraag wordt samengevoegd.

Wiskunde in pull-aanvragen bespreken

Wilt u een vergelijking of wiskundige expressie opnemen in uw pull-aanvraagopmerkingen? U kunt nu KaTeX-functies opnemen in uw opmerkingen, zowel in de vorm van inline als blokcommentaar. Zie de lijst met ondersteunde functies voor meer informatie.

Suggesties voor pullverzoeken voor forks

Wanneer een onderwerpbranch wordt bijgewerkt in een opslagplaats, wordt een 'suggestie' weergegeven voor het maken van een nieuwe pull-aanvraag (PR) voor de onderwerpbranch. Dit is erg handig voor het maken van nieuwe PR's, en we hebben dit ook ingeschakeld voor degenen die in een fork van een repository werken. Als u een vertakking in een fork bijwerkt, ziet u de volgende keer dat u de Code-hub bezoekt voor de fork of de upstream-opslagplaats, de suggestie om een pull-aanvraag te maken. Als u de koppeling 'Een pull-aanvraag maken' selecteert, wordt u doorverwezen naar de interface voor het maken van pull-aanvragen, waarbij de bron- en doelbranches en repositories vooraf zijn geselecteerd.

Padfilters voor pull request-beleidsregels

Vaak bevat één opslagplaats code die is gebouwd door meerdere CI-pijplijnen (continuous integration) om de build- en runtests te valideren. Het geïntegreerde buildbeleid ondersteunt nu een padfilteroptie waarmee u eenvoudig meerdere pull-request builds kunt configureren die voor elke pull request kunnen worden vereist en automatisch kunnen worden geactiveerd. Geef gewoon een pad op voor elke build die u wilt vereisen en stel de trigger- en vereisteopties in zoals gewenst.

Naast het bouwen, beschikt het statusbeleid ook over de optie voor padfiltering. Hiermee kunnen aangepaste of externe beleidsregels de handhaving van het beleid configureren voor specifieke paden.

Werk

Sneltoetsen in het formulier voor werkitems

Wijs een werkitem toe aan uzelf (Alt + i), ga naar discussie (Ctrl + Alt + d) en kopieer een snelle koppeling naar het werkitem (Shift + Alt + c) met behulp van sneltoetsen. Voor de volledige lijst met nieuwe sneltoetsen typt u '?' met een werkitemformulier geopend of raadpleegt u de onderstaande tabel.

Gemoderniseerde kolomopties

Het dialoogvenster Kolomopties dat wordt gebruikt om de kolommen van het werkitemraster in de Backlog, Query's en Test-hubs te configureren, is aangepast om gebruik te maken van een nieuw paneeldesign. Zoek naar een veld, sleep en zet neer om kolommen opnieuw te ordenen of verwijder bestaande kolommen die u niet meer wilt.

Informatie over de laatste uitvoering van de query

Naarmate de structuur gedeelde query's van uw project groeit, kan het lastig zijn om te bepalen of een query niet meer wordt gebruikt en kan worden verwijderd. Om u te helpen bij het beheren van uw gedeelde query's, hebben we twee nieuwe stukjes metagegevens toegevoegd aan de REST API's van onze query's, die voor het laatst zijn uitgevoerd en de laatste uitgevoerde datum, zodat u opschoningsscripts kunt schrijven om verlopen query's te verwijderen.

HTML-tags verwijderd in werkitemrasters

Op basis van feedback van klanten hebben we het gedrag van tekstvelden met meerdere regels in queryweergaven van werkitems in de web-, Excel- en Visual Studio IDE bijgewerkt om HTML-opmaak te verwijderen. Wanneer u als kolom aan de query toevoegt, worden tekstvelden met meerdere regels nu weergegeven als tekst zonder opmaak. Hier volgt een voorbeeld van een functie met HTML in de beschrijving.

In het verleden zouden de queryresultaten iets als <div><b><u>Customer Value</u>... laten zien.

Ondersteuning toegevoegd voor Niet-In-queryoperator

Velden die de queryoperator 'In' ondersteunen, bieden nu ook ondersteuning voor 'Niet In'. Schrijf query's voor werkitems 'Niet in' een lijst met id's, 'Niet in' een lijst met statussen en nog veel meer, allemaal zonder veel geneste 'Or'-componenten te hoeven maken.

Query's uitvoeren op @MyRecentActivity en @RecentMentions

We hebben twee nieuwe querymacro's voor het id-veld geïntroduceerd om u te helpen werkitems te vinden die voor u belangrijk kunnen zijn. Bekijk in welke items u de afgelopen 30 dagen bent genoemd met @RecentMentions of bekijk werkitems die u onlangs hebt bekeken of bewerkt met @MyRecentActivity.

Aangepaste velden en tags filteren in meldingen voor het bijhouden van werkitems

Meldingen kunnen nu worden gedefinieerd met voorwaarden voor aangepaste velden en tags; Niet alleen wanneer ze veranderen, maar wanneer aan bepaalde waarden wordt voldaan en een robuustere set meldingen kan worden ingesteld voor werkitems.

Instellingen voor meldingen van aangepast werkitem

Vermelde ondersteuning voor de pagina Mijn werkitems

We hebben een nieuwe Vermeld scharnier toegevoegd op de pagina Mijn werkitems. In deze sectie kunt u de werkitems bekijken waarin u de afgelopen 30 dagen bent genoemd. Met deze nieuwe weergave kunt u snel actie ondernemen op items die uw invoer vereisen en op de hoogte blijven van gesprekken die relevant voor u zijn.

Dit zelfde draaipunt is ook beschikbaar via onze mobiele ervaring, waardoor consistentie tussen zowel mobiel als desktop mogelijk is.

Filteren op plannen

De uitbreiding leveringsplannen maakt nu gebruik van ons algemene filteronderdeel en is consistent met onze rasterfilterervaringen voor werkitems en borden. Dit filterbeheer zorgt voor verbeterde bruikbaarheid en een consistente interface voor alle leden van uw team.

Navigatie voor bijgewerkte plannen

Velen van u hechten waarde aan een specifiek plan of een set plannen en maken gebruik van favorieten voor snelle toegang tot de inhoud. Eerst hebben we de Plannen-hub bijgewerkt om naar uw laatst bezochte plan te navigeren in plaats van naar de mappagina. Ten tweede kunt u de favorietenkiezer gebruiken om snel over te schakelen naar een ander abonnement of de breadcrumb te gebruiken om terug te gaan naar de mappagina.

Vereisten/personen op het takenbord uitvouwen/samenvouwen

U kunt nu met één klik alle items op het sprinttaakbord uitvouwen of samenvouwen.

De bypassrule-machtiging verlenen aan specifieke gebruikers

Bij het migreren van werkitems van een andere bron willen organisaties vaak alle oorspronkelijke eigenschappen van het werkitem behouden. U kunt bijvoorbeeld een fout maken die de oorspronkelijke gemaakte datum behoudt en die is gemaakt door waarden van het systeem waar het vandaan komt.

De API voor het bijwerken van een werkitem heeft een bypassrule-vlag om dat scenario in te schakelen. Voorheen moest de identiteit die die API-aanvraag heeft gedaan lid zijn van de groep Projectverzamelingsbeheerders. We hebben een machtiging toegevoegd op projectniveau om de API uit te voeren met de bypassrule-vlag.

Bouwen en lanceren

XAML-builds

In TFS 2015 hebben we een webgebaseerde, platformoverschrijdende buildsysteem geïntroduceerd. XAML-builds worden niet ondersteund in TFS 2018 RTW of Update 1, maar we hebben XAML-builds opnieuw ingeschakeld in TFS 2018 Update 2. We raden u aan uw XAML-builds te migreren.

Wanneer u een upgrade uitvoert naar TFS 2018 Update 2:

• Als u XAML-buildgegevens in uw teamprojectverzameling hebt, krijgt u een waarschuwing over de afschaffing van XAML-buildfuncties.

• U moet VS of Team Explorer 2017 gebruiken om XAML-builddefinities te bewerken of nieuwe XAML-builds in de wachtrij te plaatsen.

• Als u nieuwe XAML-buildagents moet maken, moet u deze installeren met het installatieprogramma van de TFS 2015-buildagent.

Zie het blogbericht Evolving TFS/Team Services build automation capabilities (Engelstalig) voor een uitleg van ons XAML-build-afschaffingsplan.

Verbeteringen aan builds met meerdere fasen

U hebt fasen kunnen gebruiken om uw buildstappen te organiseren en verschillende agents aan te passen aan de hand van verschillende vereisten voor elke fase. We hebben verschillende mogelijkheden toegevoegd om fasen te bouwen, zodat u nu het volgende kunt doen:

• Geef voor elke fase een andere agentwachtrij op. Dit betekent dat u bijvoorbeeld:

  • Voer één fase van een build uit op een macOS-agent en een andere fase op een Windows-agent. Als u een cool voorbeeld wilt zien van hoe nuttig dit kan zijn, raadpleegt u deze Connect(); Video van 2017: CI/CD DevOps Pipeline voor mobiele apps en services.
  • Voer buildstappen uit op een buildagentpool en teststappen op een testagentpool.

• Voer tests sneller uit door ze parallel uit te voeren. Elke fase met parallelle uitvoering die is geconfigureerd als 'Multi-agent' en bevat een VSTest-taak, parallelliseert de testuitvoering nu automatisch in het geconfigureerde aantal agents.

• Toestaan of weigeren dat scripts in elke fase toegang hebben tot het OAuth-token. Dit betekent bijvoorbeeld dat u nu kunt toestaan dat scripts die in uw buildfase worden uitgevoerd, via REST API's communiceren met Azure DevOps, en in dezelfde builddefinitie de scripts blokkeren die in uw testfase worden uitgevoerd.

• Voer een fase alleen uit onder specifieke voorwaarden. U kunt bijvoorbeeld een fase zo configureren dat deze alleen wordt uitgevoerd wanneer de vorige fasen slagen of alleen wanneer u code in de hoofdbranch bouwt.

Zie Fasen in build- en releasebeheer voor meer informatie.

Geplande builds overslaan als er niets is gewijzigd in de opslagplaats

Op populaire aanvraag kunt u nu opgeven dat een geplande build niet wordt uitgevoerd wanneer er niets in uw code is gewijzigd. U kunt dit gedrag beheren met behulp van een optie in het schema. Standaard plannen we geen nieuwe build als uw laatste geplande build (van hetzelfde schema) is verstreken en er geen verdere wijzigingen zijn ingecheckt in uw opslagplaats.

Bouwen met continue integratie vanuit GitHub Enterprise

U hebt nu betere integratie voor het uitvoeren van CI-builds (continue integratie) als u GitHub Enterprise gebruikt voor versiebeheer. Voorheen was u beperkt tot polling voor codewijzigingen met behulp van de externe Git-connector , waardoor de belasting op uw servers mogelijk is toegenomen en vertragingen werden veroorzaakt voordat builds werden geactiveerd. Nu, met officiële GitHub Enterprise-ondersteuning , worden team-CI-builds onmiddellijk geactiveerd. Daarnaast kan de verbinding worden geconfigureerd met behulp van verschillende verificatiemethoden, zoals LDAP of ingebouwde accounts.

Beveiligde bestanden kunnen tijdens de build of release naar agents worden gedownload

De nieuwe taak Beveiligd bestand downloaden ondersteunt het downloaden van versleutelde bestanden (naar agentcomputers) uit de VSTS Secure Files-bibliotheek . Wanneer het bestand wordt gedownload, wordt het ontsleuteld en opgeslagen op de schijf van de agent. Wanneer de build of release is voltooid, wordt het bestand verwijderd uit de agent. Hierdoor kan uw build of release gevoelige bestanden gebruiken, zoals certificaten of persoonlijke sleutels die anders veilig zijn versleuteld en opgeslagen in VSTS. Zie de documentatie voor Beveiligde bestanden voor meer informatie.

Apple-configuratieprofielen kunnen worden geïnstalleerd vanuit bronrepositories

De taak Apple-inrichtingsprofiel installeren ondersteunt het installeren van (op agentcomputers) inrichtingsprofielen die zijn opgeslagen in de VSTS Secure Files-bibliotheek . Inrichtingsprofielen worden door Xcode gebruikt voor het ondertekenen en verpakken van Apple-apps, zoals iOS, macOS, tvOS en watchOS. Nu kunnen inrichtingsprofielen worden geïnstalleerd vanuit broncodeopslagplaatsen. Hoewel het gebruik van de secure files-bibliotheek wordt aanbevolen voor een betere beveiliging van deze bestanden, is deze verbetering gericht op inrichtingsprofielen die al zijn opgeslagen in broncodebeheer.

GitHub-bronnen traceren voor builds met behulp van buildtags

Builds van GitHub of GitHub Enterprise zijn al gekoppeld aan de relevante doorvoer. Het is even belangrijk om een commit te kunnen traceren naar de builds die deze heeft gegenereerd. Dat is nu mogelijk door brontagging in TFS in te schakelen. Wanneer u uw GitHub-opslagplaats in een builddefinitie kiest, selecteert u de typen builds die u wilt taggen, samen met de tagindeling.

Bekijk vervolgens hoe buildtags worden weergegeven in uw GitHub- of GitHub Enterprise-opslagplaats.

Specifieke Java Development Kits (JDK's) kunnen worden geïnstalleerd tijdens builds en releases

Voor het bouwen van bepaalde Java-projecten zijn mogelijk specifieke JDK's vereist, maar niet beschikbaar op agentcomputers. Voor projecten zijn bijvoorbeeld oudere of andere versies van IBM, Oracle of opensource-JDK's vereist. De java tool installer-taak downloadt en installeert de JDK die nodig is voor uw project tijdens een build of release. De omgevingsvariabele JAVA_HOME wordt dienovereenkomstig ingesteld voor de duur van de build of release. Specifieke JDK's zijn beschikbaar voor het java-hulpprogramma-installatieprogramma met behulp van een bestandsshare, een opslagplaats voor broncode of Azure Blob Storage.

Verbeterde Xcode-buildconfiguratie

De Xcode-taak is bijgewerkt met een nieuwe primaire versie (4.*) die de configuratie van het bouwen, testen en verpakken van Xcode verbetert. Als uw Xcode-project één, gedeeld schema heeft, wordt dit automatisch gebruikt. Er is extra inline-help toegevoegd. Afgeschafte functies, zoals xcrun-packaging, zijn verwijderd uit de eigenschappen van de Xcode-taak. Bestaande build- en releasedefinities moeten worden gewijzigd om deze nieuwste 4.*-versie van de Xcode-taak te kunnen gebruiken. Als u voor nieuwe definities de afgeschafte mogelijkheden van een eerdere Xcode-taakversie nodig hebt, kunt u die versie selecteren in uw definitie.

Poorten vrijgeven

Continue bewaking is een integraal onderdeel van DevOps-pijplijnen. Ervoor zorgen dat de app in een release in orde is nadat de implementatie is geïmplementeerd, is zo essentieel als het succes van het implementatieproces. Ondernemingen hebben verschillende hulpprogramma's voor het automatisch detecteren van app-status in productie en voor het bijhouden van door de klant gerapporteerde incidenten. Tot nu toe moesten goedkeurders de status van de apps van alle systemen handmatig bewaken voordat ze de release promoten. Releasebeheer biedt nu echter ondersteuning voor het integreren van continue bewaking in release-pijplijnen. Gebruik dit om ervoor te zorgen dat het systeem herhaaldelijk alle gezondheidsstatussignalen voor de app opvraagt totdat ze allemaal op hetzelfde moment succesvol zijn, alvorens de release door te gaan.

U begint met het definiëren van pre-implementatie- of post-implementatiepoorten in de releasedefinitie. Elke poort kan een of meer statussignalen bewaken die overeenkomen met een bewakingssysteem van de app. Ingebouwde poorten zijn beschikbaar voor waarschuwingen van Azure Monitor (Application Insight) en Werkitems. U kunt integreren met andere systemen met behulp van de flexibiliteit die via Azure-functies wordt geboden.

Op het moment van uitvoering begint de release alle poorten te samplen en gezondheidssignalen van elk van deze poorten te verzamelen. Het herhaalt de steekproeven bij elk interval totdat de signalen die van alle poorten in hetzelfde interval zijn verzameld, succesvol zijn.

Initiële voorbeelden van de bewakingssystemen zijn mogelijk niet nauwkeurig, omdat er mogelijk onvoldoende informatie beschikbaar is voor de nieuwe implementatie. De optie Vertraging vóór evaluatie zorgt ervoor dat de release gedurende deze periode niet wordt voortgezet, zelfs als alle voorbeelden zijn geslaagd.

Er worden geen agents of pijplijnen gebruikt tijdens het steekproefsgewijs controleren van poorten. Zie de -documentatie voor releasepoorten voor meer informatie.

Selectief implementeren op basis van het artefact dat een release activeert

Er kunnen meerdere artefactbronnen worden toegevoegd aan een releasedefinitie en worden geconfigureerd om een release te activeren. Er wordt een nieuwe release gemaakt wanneer een nieuwe build beschikbaar is voor een van de bronnen. Hetzelfde implementatieproces wordt uitgevoerd, ongeacht de bron die de release heeft geactiveerd. U kunt het implementatieproces nu aanpassen op basis van de triggerbron. Voor automatisch geactiveerde releases is de releasevariabele Release.TriggeringArtifact.Alias nu ingevuld om de artefactbron te identificeren die de release heeft geactiveerd. Dit kan worden gebruikt in taakvoorwaarden, fasevoorwaarden en taakparameters om het proces dynamisch aan te passen. Als u bijvoorbeeld alleen de artefacten hoeft te implementeren die zijn gewijzigd via omgevingen.

Entiteitsspecifieke beveiliging beheren

Voorheen in beveiliging op basis van rollen, werden de rollen voor beveiligingstoegang ingesteld voor een gebruiker of groep op hubniveau voor implementatiegroepen, variabele groepen, agentwachtrijen en service-eindpunten. Nu kunt u overname voor een bepaalde entiteit in- en uitschakelen, zodat u de beveiliging op de gewenste manier kunt configureren.

Meerdere omgevingen goedkeuren

Het beheren van goedkeuringen met releases is nu eenvoudiger. Voor pijplijnen met dezelfde fiatteur voor meerdere omgevingen die parallel worden geïmplementeerd, moet de fiatteur momenteel afzonderlijk op elk van de goedkeuringen reageren. Met deze functie kunt u nu meerdere goedkeuringen in behandeling tegelijk voltooien.

Uitbreidbaarheid van releasesjablonen

Met releasesjablonen kunt u een basislijn maken om aan de slag te gaan bij het definiëren van een releaseproces. Eerder kunt u nieuwe uploaden naar uw account, maar nu kunnen auteurs releasesjablonen opnemen in hun extensies. U vindt een voorbeeld in de GitHub-opslagplaats.

Taken en fasen voor voorwaardelijke release

Net als bij voorwaardelijke buildtaken kunt u nu alleen een taak of fase uitvoeren als aan bepaalde voorwaarden wordt voldaan. Dit helpt u bij het modelleren van terugdraaiscenario's.

Als de ingebouwde voorwaarden niet aan uw behoeften voldoen of als u meer gedetailleerde controle nodig hebt wanneer de taak of fase wordt uitgevoerd, kunt u aangepaste voorwaarden opgeven. De voorwaarde uitdrukken als een geneste set functies. De agent evalueert de binnenste functie en werkt van binnen naar buiten. Het uiteindelijke resultaat is een Booleaanse waarde die bepaalt of de taak moet worden uitgevoerd.

Geschiedenis van aanvragen voor service-eindpunten

Service-eindpunten maken het mogelijk om verbinding te maken met externe en externe services om taken uit te voeren voor een build of implementatie. De eindpunten worden geconfigureerd in het projectbereik en gedeeld tussen meerdere build- en releasedefinities. Eigenaren van service-eindpunten kunnen nu een geconsolideerde weergave krijgen van builds en implementaties met behulp van een eindpunt, waarmee de controle en governance kunnen worden verbeterd.

Standaardeigenschappen voor Git- en GitHub-artefacttypen kunnen nu worden bewerkt

U kunt nu de standaardeigenschappen van git- en GitHub-artefacttypen bewerken, zelfs nadat het artefact is gekoppeld. Dit is met name handig in scenario's waarin de vertakking voor de stabiele versie van het artefact is gewijzigd en toekomstige continue leveringsreleases deze vertakking moeten gebruiken om nieuwere versies van het artefact te verkrijgen.

Omgevingen handmatig bulksgewijs implementeren vanuit de releaseweergave

U kunt nu handmatig een implementatieactie activeren in meerdere omgevingen van een release tegelijk. Hiermee kunt u meerdere omgevingen selecteren in een release met mislukte configuraties of implementaties en opnieuw implementeren in alle omgevingen in één bewerking.

Ondersteuning voor Jenkins-pijplijnen met meerdere vertakkingen en koppelingstaken in mappen

Het gebruik van projecten in Jenkins is zojuist verder verbeterd.

Eerst kunt u Jenkins-pijplijnprojecten met meerdere vertakkingen gebruiken als artefactbronnen in een releasedefinitie.

Ten tweede, terwijl u Voorheen Jenkins-projecten alleen als artefacten kon koppelen vanuit de hoofdmap van een Jenkins-server, kunnen Jenkins-projecten nu worden gebruikt wanneer ze zijn geordend op mapniveau. U ziet de lijst met Jenkins-projecten, samen met mappaden, in de lijst met bronnen waaruit u het project selecteert dat moet worden gebruikt als artefactbron.

Docker Hub of Azure Container Registry als een artefactbron

Met deze functie kunnen releases installatiekopieën gebruiken die zijn opgeslagen in een Docker Hub-register of een Azure Container Registry (ACR). Dit is een eerste stap in de richting van ondersteunende scenario's, zoals het implementeren van nieuwe wijzigingen per regio met behulp van de functie voor geo-replicatie van ACR of het implementeren in een omgeving (zoals productie) vanuit een containerregister met alleen installatiekopieën voor de productieomgeving.

U kunt Docker Hub of ACR nu configureren als een artefact van eerste klasse in de + Toevoegen artefactervaring van een releasedefinitie. Voorlopig moet de release handmatig of door een ander artifact worden geactiveerd, maar we kijken ernaar uit om binnenkort een trigger toe te voegen die is gebaseerd op het pushen van een nieuwe image naar het register.

Standaardversies van artefacten

Er zijn nu verschillende standaardversieopties bij het koppelen van artefacten voor versiebeheer aan een releasedefinitie. U kunt een specifieke doorvoer-/wijzigingenset configureren of gewoon de meest recente versie configureren die moet worden gekozen in de standaardbranch. Normaal gesproken configureert u deze om de nieuwste versie op te halen, maar dit is vooral handig in sommige omgevingen waarin een gouden artefactversie moet worden opgegeven voor alle toekomstige continue implementaties.

Release-triggers en verbeteringen aan vertakkingen

U kunt nu een releasetriggerfilter configureren op basis van de standaardbranch die is opgegeven in de builddefinitie. Dit is met name handig als uw standaardbuildbranch elke sprint wijzigt en de releasetriggerfilters moeten worden bijgewerkt in alle releasedefinities. U hoeft nu alleen de standaardbranch in de builddefinitie te wijzigen en alle releasedefinities gebruiken deze vertakking automatisch. Als uw team bijvoorbeeld releasebranches maakt voor elke sprintrelease-inhoud, werkt u deze bij in de builddefinitie om te verwijzen naar een nieuwe sprintreleasebranch en wordt dit automatisch verwerkt.

Releasetrigger voor een pakketbeheerartefact

U kunt nu een trigger instellen voor een pakketbeheerartefact in een releasedefinitie, zodat er automatisch een nieuwe release wordt gemaakt wanneer een nieuwe versie van het pakket is gepubliceerd. Zie de documentatie voor triggers in Releasebeheer voor meer informatie.

Definieer een variabelegroep voor specifieke omgevingen

Toen een variabelegroep werd toegevoegd aan een releasedefinitie, waren de variabelen die de groep bevatte, beschikbaar voor alle omgevingen in de release. U hebt nu de flexibiliteit om in plaats daarvan de variabelegroepen toe te kennen aan specifieke omgevingen. Hierdoor zijn ze beschikbaar voor één omgeving, maar niet voor andere omgevingen van dezelfde release. Dit is handig wanneer u een externe service hebt, zoals een SMTP-e-mailservice, die verschilt tussen omgevingen.

Automatisch vrijgeven vanuit Azure Container Registry en Docker Hub

Bij het implementeren van gecontaineriseerde apps wordt de containerafbeelding eerst naar een containerregister gepusht. Nadat de push is voltooid, kan de containerafbeelding worden geïmplementeerd in een Web App for Containers of een Kubernetes-cluster. U kunt nu het automatisch maken van releases inschakelen voor updates van de images die zijn opgeslagen in Docker Hub of Azure Container Registry door deze als artifact-bron toe te voegen.

Azure Container Registry als bron

Een standaardversie opgeven voor Jenkins-artefacten

Wanneer een release met meerdere artefacten automatisch wordt geactiveerd, worden standaardversies die zijn opgeslagen in de releasedefinitie, opgehaald voor alle artefacten. Voorheen hadden Jenkins-artefacten geen standaardversie-instelling en kon u dus geen continue implementatietrigger instellen voor een release met Jenkins als secundair artefact.

U kunt nu een standaardversie voor Jenkins-artefacten opgeven, met de opties waarmee u bekend bent:

• Latest
• Opgeven bij het aanmaken van de release
• Specifieke versie

Releasepoorten van extensies bijdragen

Releasepoorten maken het toevoegen van informatiegestuurde goedkeuringen mogelijk aan de release-pijplijnen. Een set statussignalen wordt herhaaldelijk verzameld vóór of na de implementatie, om te bepalen of de release moet worden gepromoveerd naar de volgende fase of niet. Er wordt een set ingebouwde poorten geleverd en 'Azure-functie aanroepen' is tot nu toe aanbevolen als een middel om te integreren met andere services. We vereenvoudigen nu de route voor integratie met andere services en voegen poorten toe via Marketplace-extensies. U kunt nu aangepaste poorttaken bijdragen en auteurs van releasedefinities een verbeterde ervaring bieden om de poort te configureren.

Meer informatie over het ontwerpen van gatetaken.

Implementaties schalen naar virtuele machines met behulp van implementatiegroepen

Implementatiegroepen, die robuuste, gebruiksklare implementatie over meerdere machines biedt, zijn nu algemeen beschikbaar. Met implementatiegroepen kunt u implementaties op meerdere servers organiseren en rolling updates uitvoeren, terwijl hoge beschikbaarheid van uw toepassing overal wordt gegarandeerd. U kunt ook implementeren op lokale servers of op virtuele machines in Azure of in elke cloud en eind-tot-eind traceerbaarheid hebben van geïmplementeerde artefactversies tot op serverniveau.

De implementatiemogelijkheid op basis van agents is afhankelijk van dezelfde build- en implementatieagents die al beschikbaar zijn. U kunt de volledige taakcatalogus op uw doelcomputers gebruiken in de fase Implementatiegroep. Vanuit het perspectief van uitbreidbaarheid kunt u ook de REST API's gebruiken voor implementatiegroepen en -doelen voor programmatische toegang.

Package

Openbare pakketten naadloos gebruiken met behulp van upstream-bronnen

Upstream-bronnen voor nuget.org en npmjs.com zijn nu beschikbaar. Voordelen zijn onder andere de mogelijkheid om pakketten te beheren (uit de lijst verwijderen, verwijderen, enzovoort) die zijn opgeslagen uit upstream-bronnen en gegarandeerde opslag van elk upstream-pakket dat u gebruikt.

Bewaarbeleid in TFS-feeds

Tot nu toe hebben TFS-pakketfeeds geen enkele manier geboden om oudere, ongebruikte pakketversies automatisch op te schonen. Voor frequente pakketuitgevers kan dit leiden tot tragere feedquery's in NuGet Package Manager en andere clients totdat sommige versies handmatig zijn verwijderd.

We hebben nu bewaarbeleid ingeschakeld voor TFS-feeds. Bewaarbeleid verwijdert automatisch de oudste versie van een pakket zodra aan de drempelwaarde voor retentie is voldaan. Pakketten die worden gepromoveerd naar weergaven, worden voor onbepaalde tijd bewaard, zodat u versies kunt beveiligen die in productie worden gebruikt of die overal in uw organisatie worden gebruikt.

Als u bewaarbeleid wilt inschakelen, bewerkt u uw feed en voert u een waarde in het maximum aantal versies per pakket in de sectie Bewaarbeleid .

Filteren in pakketbeheer

De pagina Pakketten is bijgewerkt voor gebruik van onze standaardpagina-indeling, opdrachtbalk en de nieuwe standaardfilterbalk.

Uw pakketten delen met behulp van een badge

In de opensource-community is het gebruikelijk om een badge te gebruiken die is gekoppeld aan de nieuwste versie van uw pakket in de README van uw opslagplaats. U kunt nu badges maken voor pakketten in uw feeds. Schakel de optie Pakketbadges inschakelen in de feedinstellingen in, selecteer een pakket en klik vervolgens op Badge maken. U kunt de badge-URL rechtstreeks kopiëren of vooraf gegenereerde Markdown kopiëren die de badge weer koppelt aan de pagina met details van uw pakket.

Vorige pakketversies zijn nu een volledige-pagina lijst

We hebben veel feedback ontvangen over de bijgewerkte pakketbeheerervaring, waar we de lijst met vorige pakketversies hebben verplaatst naar een breadcrumb-kiezer op de pagina met pakketgegevens. We hebben een nieuwe versiepivot toegevoegd die meer informatie over eerdere versies bevat en het eenvoudiger maakt om het versienummer te kopiëren of een koppeling naar een oude versie te krijgen.

Kwaliteit van een pakketversie weergeven in de pakketlijst

In de pakketlijst ziet u nu de weergave(s) van elke pakketversie om snel de kwaliteit ervan te bepalen. Raadpleeg de documentatie voor releaseoverzichten voor meer informatie. ) documentatie voor meer informatie.

Gulp, Yarn en meer ondersteuning voor geauthentiseerde feeds

De npm-taak werkt vandaag naadloos met geverifieerde npm-feeds (in Pakketbeheer of externe registers zoals npm Enterprise en Artifactory), maar tot nu toe is het lastig om een taakloper zoals Gulp of een alternatieve NPM-client zoals Yarn te gebruiken, tenzij die taak ook geverifieerde feeds ondersteunt. We hebben een nieuwe npm Authenticate-buildtaak toegevoegd waarmee referenties aan uw .npmrc worden toegevoegd, zodat volgende taken geverifieerde feeds kunnen gebruiken.

Standaardmachtigingen voor pakketfeeds omvatten nu Projectbeheerders

In het verleden stelt het maken van een feed de gebruiker in als de enige eigenaar van de feed, wat kan leiden tot beheeruitdagingen in grote organisaties als die gebruiker van teams wisselt of de organisatie verlaat. Om dit single point of failure te verwijderen, maakt het aanmaken van een feed nu gebruik van de huidige projectcontext van de gebruiker om de groep Projectbeheerders op te halen en deze ook als eigenaar van de feed in te stellen. Net als bij elke machtiging kunt u deze groep verwijderen en feedmachtigingen verder aanpassen met behulp van het dialoogvenster feedinstellingen.

Recycle en herstel pakketten

Het verwijderen van ongebruikte pakketten kan helpen de pakketlijst schoon te houden, maar soms kan dit per ongeluk worden gedaan. U kunt nu verwijderde pakketten terugzetten uit de Prullenbak. Verwijderde pakketten worden 30 dagen bewaard in de Prullenbak, zodat u voldoende tijd hebt om te herstellen als dat nodig is.

Koppeling naar pakketten vanaf elke locatie

Hoewel u de URL kunt delen met een pakket dat in het verleden in de Packages Hub is gevonden, was het vaak moeilijk om te gebruiken omdat u een project in de URL moest opnemen, dat al dan niet van toepassing is op die met behulp van de koppeling. Met deze update kunt u nu pakketten delen met behulp van een URL die automatisch een project selecteert waartoe de ontvanger toegang heeft.

De URL-indeling is: 'https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package'

Test

Visual Studio Test-taak heeft geen volledige Visual Studio nodig

Voor de Visual Studio-testtaak in build/release moet Visual Studio op de agent tests uitvoeren. In plaats van Visual Studio te installeren om tests uit te voeren in productieomgevingen of om alleen tests over meerdere agents te distribueren, gebruikt u de nieuwe taak voor het installatieprogramma van het Visual Studio-testplatform . Met deze taak wordt het testplatform opgehaald uit nuget.org en toegevoegd aan de cache van de hulpprogramma's. De installatietaak voldoet aan de vstest-vraag en een volgende Visual Studio Test-taak in de definitie kan worden uitgevoerd zonder dat er een volledige Visual Studio-installatie op de agent nodig is.

Voeg vanuit de taakcatalogus de installatietaak toe aan uw definitie.

Configureer de volgende Visual Studio Test-taak om de bits te gebruiken die zijn verkregen via het installatieprogramma.

Functionele tests uitvoeren en testagenttaken implementeren zijn nu afgeschaft

Vorig jaar zijn we begonnen met het unificeren van agents in build, release en test. Dit was bedoeld om verschillende pijnpunten aan te pakken die zijn gekoppeld aan het gebruik van Op WinRM gebaseerde Deploy Test Agent en Taken voor functionele tests uitvoeren . Hiermee kunt u ook de Visual Studio Test-taak (VSTest) gebruiken voor al uw testbehoeften, waaronder:

• Eenheidstests
• Functionele tests (UI/niet-UI)
• Op MSTest gebaseerde tests
• Op framework gebaseerde tests van derden
• Testspecificatie op assembly-basis of tests uitvoeren met Testplan/Testsuite
• Testuitvoering met een enkele agent en het distribueren van tests over meerdere agents

Met de geïntegreerde agents kunnen beheerders ook alle machines beheren die op een uniforme manier voor CI/CD worden gebruikt.

We hebben verschillende cruciale onderdelen geleverd om deze mogelijkheid mogelijk te maken, waaronder:

• Agents kunnen worden geconfigureerd voor het testen van de gebruikersinterface
• Met het installatieprogramma voor Visual Studio Test Platform kan VSTest-taak worden uitgevoerd zonder dat Visual Studio vooraf hoeft te worden geïnstalleerd
• Zowel build- als releasedefinities kunnen worden gemaakt met meerdere fasen en hebben de mogelijkheid om voor elke fase verschillende agentwachtrijen te gebruiken
• Geautomatiseerde testcases kunnen worden uitgevoerd vanuit de testhub met behulp van de VSTest-taak

Nu al het bovenstaande is ingesteld, zijn we klaar om deze twee taken te verwijderen. Hoewel bestaande definities die gebruikmaken van de afgeschafte taken blijven werken, raden we u aan om in de loop van de tijd gebruik te maken van VSTest om te profiteren van een voortdurende uitbreiding.

Grote testresultaten filteren

In de loop van de tijd worden testassets opgebouwd en kunnen grote toepassingen eenvoudig groeien tot duizenden tests. Teams zijn op zoek naar betere manieren om door grote sets testresultaten te navigeren om productief te zijn bij het identificeren van testfouten, de bijbehorende hoofdoorzaak of het eigendom van problemen. Om dit in te schakelen, hebben we drie nieuwe filters toegevoegd onder het tabblad Tests in build en release als testnaam, container (DLL's) en eigenaar (containereigenaar).

Daarnaast biedt het bestaande resultaatfilter nu de mogelijkheid om te filteren op meerdere resultaten. Het verschillende filtercriterium is cumulatief van aard. Als gebruiker, wanneer ik het resultaat van mijn tests wil zien voor een wijziging die ik zojuist heb doorgevoerd, kan ik filteren op de container (DLL-naam), eigenaar (DLL-eigenaar), testnaam of allemaal, om de resultaten te zien die relevant zijn voor mij.

Flaky tests identificeren

Soms zijn tests onbetrouwbaar: ze mislukken tijdens de ene testuitvoering en slagen bij een andere zonder wijzigingen. Flaky tests kunnen frustrerend zijn en het vertrouwen in testeffectiviteit ondermijnen, waardoor mislukkingen worden genegeerd en bugs door de mazen van het net glippen. Met deze update hebben we het eerste deel van een oplossing geïmplementeerd om het probleem van flaky tests aan te pakken. U kunt nu de Visual Studio Test-taak configureren om mislukte tests opnieuw uit te voeren. De testresultaten geven vervolgens aan welke tests in eerste instantie zijn mislukt en vervolgens opnieuw worden uitgevoerd. Ondersteuning voor het opnieuw uitvoeren van gegevensgestuurde en geordende tests komt later beschikbaar.

De Visual Studio Test-taak kan worden geconfigureerd om het maximum aantal pogingen om mislukte tests opnieuw uit te voeren en een drempelwaardepercentage voor fouten (bijvoorbeeld alleen tests opnieuw uitvoeren als minder dan 20% van alle tests is mislukt) om te voorkomen dat tests opnieuw worden uitgevoerd in geval van uitgebreide fouten.

Op het tabblad Tests onder Build en Release kunt u de testresultaten filteren met Resultaat als 'Geslaagd bij opnieuw uitvoeren' om de tests te identificeren die onbetrouwbaar gedrag hadden tijdens de uitvoering. Dit toont momenteel de laatste poging voor elke test die geslaagd is bij een hernieuwde uitvoering. De samenvattingsweergave wordt ook gewijzigd om 'Doorgegeven bij opnieuw uitvoeren (n/m)' weer te geven onder Totaal testen, waarbij n het aantal tests is dat is doorgegeven bij opnieuw uitvoeren en m het totaal aantal geslaagde tests is. Een hiërarchische weergave van alle pogingen komt in de volgende sprints.

Preview-verbeteringen en ondersteuning voor verschillende logboektypen die zijn gegenereerd door de Visual Studio Test-taak

We hebben de VSTest-taak uitgebreid om logboeken te publiceren die zijn gegenereerd door verschillende soorten logboekregistratie-instructies die overeenkomen met de standaarduitvoer en de standaardfout voor mislukte tests. We hebben ook de preview-ervaring verbeterd ter ondersteuning van het weergeven van tekst- en logboekbestandsindelingen, met de mogelijkheid om in de logboekbestanden te zoeken.

Wiki

Wiki zoeken

U kunt zoeken naar uw favoriete Wiki-pagina's op titel of inhoud naast code en werkitems. Meer informatie over Wiki-zoekopdrachten vindt u in de Microsoft DevOps-blog.

Wikipagina's afdrukken

Wiki kan worden gebruikt voor een verscheidenheid aan inhoud. Soms kan het handig zijn om inhoud van Wiki af te drukken om te lezen in uw vrije tijd, opmerkingen toe te voegen met pen en papier of zelfs een offline PDF-kopie te delen met degenen buiten uw VSTS-project. Klik nu op het contextmenu van een pagina en selecteer Pagina afdrukken.

Bijdragen aan Wiki-pagina's met gemak met sneltoetsen

U kunt nu sneltoetsen gebruiken om algemene bewerkings- en weergaveacties in Wiki nog sneller uit te voeren met alleen uw toetsenbord.

Tijdens het weergeven van een pagina kunt u een subpagina toevoegen, bewerken of maken, bijvoorbeeld:

Tijdens het bewerken van een pagina kunt u snel opslaan, opslaan en sluiten of gewoon sluiten.

Dit zijn naast standaardsneltoetsen voor bewerken, zoals Ctrl+B voor vet, Ctrl+I voor cursief, Ctrl+K voor koppelen, enzovoort. Zie de volledige lijst met sneltoetsen voor meer informatie.

Uitgebreide Markdown-rendering in de markdown-bestanden van de code-opslagplaats

U kunt nu uitgebreide README.MD-bestanden maken in de coderepositories. De Markdown-rendering van de MD-bestanden in codeopslagplaatsen ondersteunt nu HTML-tags, blokcitaten, emoji's, het wijzigen van het formaat van afbeeldingen en wiskundige formules. Er is pariteit in markdown-rendering in Wiki- en MD-bestanden in code.

Wiki ondersteunt wiskundige formules

Als uw toepassing omgaat met wiskundige formules en vergelijkingen, kunt u deze nu in Wiki plaatsen met behulp van de LaTeX-indeling.

Naslagwerkitems in Wiki

U kunt nu verwijzen naar werkitems in Wiki-pagina's door op de toets #te drukken om een lijst met de laatst geopende werkitems op te halen en het gewenste werkitem te selecteren. Dit is met name handig bij het schrijven van releaseopmerkingen, epics, specificaties of andere pagina's die naar een werkitem moeten verwijzen.

Werkitems en Wikipagina's koppelen

U kunt nu een werkitem koppelen aan een Wiki en omgekeerd. U kunt werkitems koppelen aan Wiki om epische pagina's, releaseopmerkingen en planningsinhoud te maken waarmee u de werkitems die zijn gekoppeld aan een Wiki-pagina kunt bijhouden en kunt controleren welk percentage van uw epische pagina is voltooid.

Gekoppelde werkitems worden vervolgens weergegeven op de Wiki-pagina.

Voeg een koppeling toe aan een Wiki-pagina vanuit een werkitem via het nieuwe koppelingstype Wikipagina.

Ctrl+S om wikipagina op te slaan

We hebben gehoord dat u een snellere en eenvoudigere manier wilde om een Wiki-pagina op te slaan. U kunt nu de sneltoets Ctrl+S gebruiken om een pagina op te slaan met een standaardrevisiebericht en door te gaan met bewerken. Als u een aangepast revisiebericht wilt toevoegen, klikt u op de dubbele punthaak naast de knop Opslaan.

Uitgebreide Wiki-inhoud plakken als HTML

U kunt nu rtf-tekst in de Markdown-editor van Wiki plakken vanuit browsertoepassingen zoals Confluence, OneNote, SharePoint en MediaWiki. Dit is met name handig voor degenen die uitgebreide inhoud hebben gemaakt, zoals complexe tabellen en deze willen weergeven in Wiki. Kopieer eenvoudig inhoud en plak deze als HTML.

Pagina verplaatsen in Wiki met behulp van het toetsenbord

Eerder in Wiki konden gebruikers de volgorde van pagina's niet wijzigen of pagina's aan een andere bovenliggende pagina toewijzen met behulp van het toetsenbord, en dit zou invloed hebben op gebruikers die liever toetsenbordbewerkingen gebruiken. U kunt nu de volgorde van pagina's wijzigen met de opdrachten Ctrl+Omhoog of Ctrl+Omlaag. U kunt pagina's ook herplaatsen door te klikken op Pagina verplaatsen in het contextmenu van een pagina en de nieuwe bovenliggende pagina te selecteren waarnaar u wilt verplaatsen.

Markering van filtertekst

Als u het navigatiedeelvenster in Wiki filtert, wordt de hele paginahiërarchie weergegeven. Als u bijvoorbeeld een pagina met de titel foobar filtert, worden ook alle bovenliggende pagina's weergegeven in het gefilterde navigatiedeelvenster. Dit kan verwarrend zijn omdat pagina's zonder de titel 'foobar' worden weergegeven in gefilterde resultaatsets. Nu markeert het filteren van inhoud in Wiki de tekst die wordt doorzocht om een duidelijk beeld te geven van de titels die zijn gefilterd en de titels die niet zijn.

U zult hetzelfde gedrag in alle code-navigatiedeelvensters waarnemen. Het navigatiedeelvenster voor bestanden in pull-aanvragen, commits, changesets en shelvesets.

Voorbeeldinhoud tijdens het bewerken van Wiki-pagina's

Gegevens laten zien dat gebruikers bijna altijd een wikipagina meerdere keren bekijken tijdens het bewerken van inhoud. Voor elke paginabewerking klikken gebruikers gemiddeld op Preview 1-2. Dit resulteert in een trage en suboptimale bewerkingservaring en kan met name tijdrovend zijn voor degenen die nieuw zijn voor Markdown. U kunt nu het voorbeeld van uw pagina zien tijdens het bewerken.

General

Profielkaarten

Er zijn meerdere gebieden in TFS waar informatie die aan een bepaalde persoon is gekoppeld, wordt weergegeven, zoals, maar niet beperkt tot: pull-aanvragen die zijn gemaakt door een persoon en werkitems die aan een persoon zijn toegewezen. Er is echter beperkte informatie over het individu zelf om volledige context te krijgen. De nieuwe profielkaart vervangt de bestaande profielkaart in TFS. Met de bijgewerkte profielkaart kunt u communiceren met en meer informatie over gebruikers in uw TFS-account. Via integraties met uw standaard-e-mail- en chatclient kunnen Active Directory-gebruikers (AD) e-mailberichten verzenden en chats rechtstreeks starten vanaf de profielkaart. AD-gebruikers kunnen ook de organisatiehiërarchie binnen de profielkaart zien. Profielkaarten kunnen worden geactiveerd op de startpagina van het project: sectie teamleden, versiebeheer, werkitems en Wiki-secties door te klikken op het pictogram van het visitekaartje, de profielfoto of de naam van gebruikers in opmerkingen.

Avatars in cirkelvorm

Cirkel avatars zijn hier! Alle profielafbeeldingen in de service worden nu weergegeven in een cirkelvorm in plaats van een vierkant. Hier is bijvoorbeeld de werkelijke pull-aanvraag voor deze wijziging (let op de cirkelvormige, niet-vierkante avatars).

Projecttags

U kunt nu projecten voorzien van belangrijke trefwoorden (tags). Tags kunnen eenvoudig rechtstreeks worden toegevoegd en verwijderd van de startpagina van het project (door beheerders), zodat gebruikers snel meer inzicht kunnen krijgen in het doel en het bereik van het project. We hebben meer gepland over hoe projecttags kunnen worden gebruikt, dus blijf hier op de hoogte van meer nieuws.

Favoriete groepen opnieuw orden

U kunt de groepen nu opnieuw ordenen op de pagina Mijn favorieten van het account met behulp van de pijl-omhoog en pijl-omlaag in elke groepskoptekst.

Feedback en suggesties

We horen graag van u! U kunt een probleem melden en volgen via de ontwikkelaarscommunity en advies krijgen over Stack Overflow.