Opmerkingen bij de release van Team Foundation Server 2018

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 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.

Zie de TFS-installatiepagina voor meer informatie.

Releasedatum: 15 november 2017

Samenvatting van wat er nieuw is in TFS 2018

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

• We hebben de Projectwizard en Processjabloonbeheerder op het web verbeterd.
• U kunt nu de koptekst van het werkitemformulier aanpassen.
• We hebben het formulier voor mobiele werkitems geoptimaliseerd.
• We hebben ondersteuning toegevoegd voor Git-forks.
• U kunt enorme Git-opslagplaatsen beheren met GVFS.
• U kunt de beveiliging van Git-tags bekijken, filteren, verwijderen en instellen.
• We hebben de minimap van het bestand, de koppeling tussen haakjes en de wisselknop witruimte toegevoegd om webcode te bewerken.
• We hebben veel verbeteringen aangebracht in pull-aanvragen.
• U hebt een nieuwe verbeterde Wiki-ervaring .
• We hebben ondersteuning toegevoegd voor Maven-pakketten.
• U kunt importeren en exporteren en builddefinities pauzeren.
• De nieuwe releasedefinitie-editor heeft standaard opt-in.
• U kunt implementeren met implementaties van virtuele machines.
• We hebben de traceerbaarheid van experimentele tests verbeterd.
• We hebben testbatches toegevoegd.
• U kunt nu een grafiekwidget bekijken voor testplannen en testsuites.

Nieuw in TFS 2018-video

XAML-build

We hadden oorspronkelijk XAML-build vermeld als verwijderd uit de TFS 2018 RTW en Update 1. Dit heeft er echter toe geleid dat te veel klanten geen upgrade kunnen uitvoeren of dat ze contact moeten opnemen met de ondersteuning om deze opnieuw in te schakelen nadat de upgrade is voltooid. In TFS 2018 Update 2 is XAML-build ingeschakeld, maar het wordt afgeraden. Dit betekent dat er geen verdere investering meer is in XAML Build en dat Microsoft Test Manager (MTM) geen ondersteuning meer biedt voor het gebruik van XAML-builds. We raden u ten zeerste aan om te converteren naar een van de nieuwere build definitie-indelingen. U kunt uw XAML-controllers blijven verbinden en XAML-builds uitvoeren met TFS 2018 Update 2. Meer informatie

Functies verwijderd in TFS 2018 RTW

• Ondersteuning voor Lab Center en geautomatiseerde teststromen in Microsoft Test Manager is verwijderd.
• We hebben de TFS-extensie voor SharePoint stopgezet.
• We hebben de functie Teamruimte verwijderd.

Details over wat nieuw is in TFS 2018

Werkitems bijhouden

Wizard voor projectcreatie op het web

We hebben de ervaring voor het maken van een teamproject verbeterd vanuit webtoegang. Deze bevat nu de meeste functies die beschikbaar zijn wanneer u een teamproject maakt in de Visual Studio-client. Het voordeel van het gebruik van de webinterface is dat u geen overeenkomende Visual Studio-versie nodig hebt. Het verschil tussen het gebruik van Visual Studio of de webversie is dat de webversie uw rapporten niet in SSRS inricht. Als u de webversie van het teamproject hebt gebruikt, kunt u de tfsconfig opdracht uitvoeren op de toepassingslaag om de SSRS-rapporten in te richten of bij te werken.

Processjabloonbeheer op het web

Met TFS 2018 kunt u webtoegang gebruiken om uw processjablonen te uploaden. De webinterface is een veel eenvoudigere ervaring omdat u niet de juiste versie van Visual Studio hoeft te installeren om te communiceren met uw processjablonen. Visual Studio 2017 Update 4 en eerder toont nog steeds het dialoogvenster Processjabloonbeheer , hoewel het raadzaam is om de webinterface te gebruiken. Visual Studio 2017 Update 5 en hoger leidt u automatisch naar het web.

De koptekst van het werkitemformulier aanpassen

U kunt nu de kop van het werkitemformulier aanpassen door de bestaande elementen te vervangen of elementen te verbergen die niet relevant zijn voor uw proces. Hiermee kunt u het pad Gebied vervangen door een aangepast teamveld, iteratie verbergen als uw teams meer gericht zijn op Kanban en Reden vervangen door een aangepast veld. Het veld Status kan niet worden verborgen of vervangen.

Formulier voor mobiel werkitem

We hebben een volledige end-to-end ervaring met een geoptimaliseerd uiterlijk voor werkitems (afbeelding 1). Het biedt een eenvoudige manier om vanaf uw telefoon te communiceren met items die aan u zijn toegewezen, die u volgt, die u heeft bezocht, of die u onlangs heeft bewerkt.

Naast het goede uiterlijk ondersteunt deze ervaring geoptimaliseerde besturingselementen voor alle veldtypen (afbeelding 2).

Met de nieuwe mobiele navigatie (afbeelding 3) kunnen gebruikers alle andere mobiele onderdelen van TFS bereiken en teruggaan naar de volledige desktopsite voor het geval ze moeten communiceren met andere hubs.

Filteren op achterstanden, Kanbanborden, sprints en query's

Al onze rasterervaringen voor het bijhouden van werkitems (query's, achterstanden, Kanbanborden, sprintsachterstanden en testcasebeheer) maken nu gebruik van ons algemene, consistente filtercomponent (afbeelding 4). Naast het toepassen van een trefwoordfilter voor weergegeven kolommen en het selecteren van tags, kunt u ook filteren op typen werkitems, statussen en toegewezen aan, om snel toegang te krijgen tot de werkitems die u zoekt.

Uitvouwen om lege velden weer te geven op een Kanban-kaart

Tegenwoordig hebt u de mogelijkheid om extra velden aan een kaart toe te voegen en lege velden(afbeelding 5) in de bordinstellingen te verbergen om onnodige rommel van het bord te verwijderen. Het nadeel van deze functie was dat nadat een leeg veld was verborgen, de enige manier om het veld bij te werken het werkitemformulier moest openen. Met de zojuist beschikbare uitbreidingsoptie op Kanban-kaarten kunt u nu profiteren van het verbergen van lege velden aan de hele kant van het bord, maar nog steeds met één klik toegang hebben om een bepaald veld op een kaart bij te werken. Beweeg de muisaanwijzer over de kaart en zoek naar het pijlpictogram omlaag onder aan de kaart om het verborgen veld te updaten.

Klik op de dubbele punthaak onder aan de kaart om het veld bij te werken (afbeelding 6).

Extensies blokkeren het opslaan van werkitems

Aangepaste besturingselementen, groepen en pagina's voor werkitems kunnen nu het opslaan van werkitems blokkeren om gegevens te valideren en ervoor te zorgen dat de gebruiker alle vereiste informatie invult voordat het werkitemformulier wordt opgeslagen.

Inline toevoegen aan leveringsplannen

Nieuwe functieideeën kunnen op elk moment binnenkomen, zodat we het eenvoudiger hebben gemaakt om nieuwe functies rechtstreeks aan uw leveringsplannen toe te voegen (afbeelding 7). Klik op de knop Nieuw item die verschijnt wanneer u erover beweegt, voer een naam in en druk op enter. Er wordt een nieuwe functie gemaakt met het gebiedspad en het iteratiepad dat u zou verwachten.

Versiebeheer

Vorken

TFS 2018 voegt ondersteuning toe voor Git-forks (afbeelding 8). Een fork is een kopie van een opslagplaats aan de serverzijde. Met forks kunt u een breed scala aan personen toestaan om bij te dragen aan uw opslagplaats zonder hen directe doorvoertoegang te geven. In plaats daarvan zetten ze hun werk vast aan hun eigen fork van de opslagplaats. Dit biedt u de mogelijkheid om de wijzigingen in een pull-aanvraag te controleren voordat u deze wijzigingen accepteert in de centrale opslagplaats.

GVFS

Git Virtual File System (GVFS) wordt nu ondersteund. Met GVFS kunnen Git-opslagplaatsen worden geschaald naar miljoenen bestanden door de werking van Git op het bestandssysteem te virtualiseren en optimaliseren.

Een map maken in een opslagplaats met web

U kunt nu mappen maken via het web in uw Git- en TFVC-opslagplaatsen (afbeelding 9). Deze vervangt de extensie Mapbeheer, die nu wordt uitgefaseerd.

Als u een map wilt maken, klikt u op Nieuwe > map in de opdrachtbalk of het contextmenu:

Voor TFVC geeft u een mapnaam op en checkt u deze vervolgens in. Voor Git, omdat lege mappen niet zijn toegestaan, moet u ook een bestandsnaam opgeven, eventueel het bestand bewerken en het vervolgens doorvoeren.

Daarnaast is voor Git het dialoogvenster Nieuw bestand(afbeelding 10) verbeterd om slashes te accepteren om submappen te maken.

Minimap van bestand

U kunt nu een minimap van een bestand bekijken terwijl u dit bekijkt of bewerkt, zodat u een kort overzicht krijgt van de code (afbeelding 11). Als u de minimap wilt inschakelen, opent u het opdrachtenpalet (F1 of klikt u met de rechtermuisknop) en selecteert u Minimap in-/uitschakelen.

Haakjeskoppeling

Wanneer u een bestand bewerkt of bekijkt, zijn er nu richtlijnen aan de linkerkant zodat u gemakkelijk uw haakjes overeen kunt laten komen (afbeelding 12).

Witruimte in-/uitschakelen

U kunt nu witruimte in- en uitschakelen wanneer u een bestand bekijkt of bewerkt. We zijn nog steeds een functie aan het ontwikkelen waarmee u witruimte kunt in- of uitschakelen bij het vergelijken van verschillen. Als u witruimte (afbeelding 13) wilt weergeven, opent u het opdrachtenpalet (F1 of klikt u met de rechtermuisknop) en selecteert u Witruimte in-/uitschakelen, zodat u onderscheid kunt maken tussen spaties en tabbladen.

Instelling voor het uitschakelen van webbewerking voor TFVC-opslagplaatsen

Teams die TFVC gebruiken, gebruiken vaak check-in-beleid in Visual Studio om codekwaliteit te garanderen. Omdat incheckbeleidsregels echter worden afgedwongen op de client, wordt code die op internet wordt bewerkt, niet onderworpen aan hetzelfde beleid.

Verschillende mensen hebben gevraagd om webbewerking te deactiveren om te beschermen tegen wijzigingen die het incheckbeleid omzeilen. We hebben een manier voor u ingeschakeld om webbewerkingen uit te schakelen (toevoegen, verwijderen, de naam wijzigen en bewerken) voor TFVC op project-/opslagplaatsbasis.

Als u webbewerking vanaf de pagina Bestanden niet wilt toestaan, gaat u naar Instellingen en vervolgens versiebeheer(afbeelding 14). Klik op de TFVC-opslagplaats in de structuur, navigeer naar het draaipunt Opties en schakel Webbewerking inschakelen uit voor deze TFVC-opslagplaats. Webbewerking is standaard ingeschakeld.

Als u een webbewerking probeert uit te voeren in een project waarvoor webbewerking is uitgeschakeld, wordt u gewaarschuwd dat webbewerking niet is toegestaan (afbeelding 15).

Identificeer verouderde vertakkingen

Door uw opslagplaats schoon te houden door vertakkingen te verwijderen die u niet meer nodig hebt, kunnen teams vertakkingen vinden die ze belangrijk vinden en favorieten instellen op de juiste granulariteit. Als u echter veel vertakkingen in uw repository hebt, kan het lastig zijn te bepalen welke inactief zijn en verwijderd kunnen worden. We hebben het nu eenvoudiger gemaakt om "verouderde" vertakkingen te identificeren (vertakkingen die verwijzen naar commits die ouder zijn dan 3 maanden). Als u uw verouderde vertakkingen wilt zien, gaat u naar het verouderde tabblad op de Vertakkingen pagina (Afbeelding 16).

Een verwijderde vertakking zoeken en opnieuw maken

Wanneer u per ongeluk een vertakking van de server verwijdert, kan het lastig zijn om erachter te komen wat er met de vertakking is gebeurd. U kunt nu zoeken naar een verwijderde vertakking, zien wie de vertakking heeft verwijderd en wanneer, en deze desgewenst opnieuw maken.

Als u wilt zoeken naar een verwijderde vertakking, voert u de volledige vertakkingsnaam in het zoekvak van de vertakking in. Het zal alle bestaande vertakkingen retourneren die overeenkomen met die tekst. U ziet ook een optie om te zoeken naar een exacte overeenkomst in de lijst met verwijderde takken. Klik op de koppeling om verwijderde vertakkingen te doorzoeken (afbeelding 17).

Als er een overeenkomst wordt gevonden, ziet u wie deze heeft verwijderd en wanneer. U kunt de vertakking ook herstellen (afbeelding 18).

Het herstellen van de vertakking zal deze opnieuw aanmaken bij de commit waarnaar als laatste werd verwezen. Er worden echter geen beleidsregels en machtigingen hersteld.

Zoek naar een commit in vertakkingen die beginnen met een voorvoegsel

Als u een vertakkingsstructuur hebt in een hiërarchische indeling waarbij alle vertakkingen worden voorafgegaan door een tekst, kunt u met deze functie een doorvoering vinden in alle vertakkingen die beginnen met die voorvoegseltekst. Als u bijvoorbeeld wilt zien of een doorvoering de weg heeft gemaakt naar alle vertakkingen die zijn voorafgegaan door 'dev', typt u 'dev' in het zoekvak en selecteert u Zoeken in vertakkingen die beginnen met 'dev'(afbeelding 19).

Uitgebreidere pull-aanvraagvermelding op de commit-detailpagina

In de pull-aanroep op de commitdetailpagina ziet u meer relevante informatie om beter te diagnosticeren (afbeelding 20). Nu laten we ook de eerste pull-aanvraag zien die de commit heeft geïntroduceerd in een branch en de pull-aanvraag die is gekoppeld aan de standaardbranch in de oproep.

Filteren van boomweergave in Code

Nu hoeft u niet door alle bestanden te bladeren die een doorvoer heeft gewijzigd om alleen naar uw bestanden te gaan. De structuurweergave over doorvoergegevens, pull-aanvragen, plankendetails en detailspagina voor wijzigingensets ondersteunt nu het filteren van bestanden en mappen. Dit is een slim filter waarin onderliggende bestanden van een map worden weergegeven wanneer u filtert op mapnaam en een samengevouwen structuurweergave van een bestand weergeeft om de bestandshiërarchie weer te geven wanneer u filtert op bestandsnaam.

Zoek een bestand of mapfilter op doorvoerstructuur (afbeelding 21) en (afbeelding 22):

De pagina met Vertakkingsupdates heet nu Pushes

De pagina Vertakkingsupdates heeft een enorme waarde. Het was echter verborgen als een draaipuntfunctie onder de hub Geschiedenis. De pagina met vertakkingsupdates is nu zichtbaar als een hub met de naam Pushes(afbeelding 23) onder Code, naast doorvoeringen, vertakkingen, tags en pull-aanvragen. De nieuwe URL voor de pushpagina is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. De oude URL's blijven functioneren.

Tegelijkertijd wordt de naam van de hub Geschiedenis gewijzigd in Doorvoeringen(afbeelding 24), omdat in de hub alleen doorvoeringen worden weergegeven. We hebben feedback ontvangen dat mensen het moeilijk vonden om problemen met betrekking tot doorvoeren op te lossen, omdat de doorvoerlijstweergave alleen gedetailleerde tijd aanwijsde. In de commitlijstweergave in uw exemplaar van de software wordt datum en tijd nu weergegeven als dd/mm/jj uu:mm. De nieuwe URL voor de doorvoerpagina is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. De oude URL's blijven functioneren.

Bestandsnaam behouden bij het verplaatsen van bestanden naar commits

We hebben feedback van mensen gehoord dat wanneer ze het directory filteren op een bepaald bestand in de Bestanden-sectie van de Code-hub en later schakelen naar de Geschiedenis-sectie, de bestandsnaam niet behouden blijft als de commit meer dan 1000 bestanden heeft gewijzigd. Dit heeft geresulteerd in mensen die meer bestanden moeten laden en inhoud moeten filteren om het bestand te vinden, wat de productiviteit heeft beïnvloed. Ontwikkelaars werken normaal gesproken in dezelfde map en willen de mappen waarin ze werken behouden wanneer ze wijzigingen traceren. Nu behouden we de bestandsnaam terwijl u tussen Code hub-overzichten navigeert, ongeacht het aantal bestanden dat in een commit is gewijzigd. Dit betekent dat u niet hoeft te klikken op Meer laden om het gewenste bestand te vinden.

Git-tags weergeven

U kunt alle tags in uw opslagplaats weergeven op de pagina Tags(afbeelding 25). Als u al uw tags als releases beheert, kan een gebruiker de pagina tags bezoeken om een vogelvlucht te krijgen van alle productreleases.

U kunt eenvoudig onderscheid maken tussen een lichtgewicht en een geannoteerde tag. Aantekeningstags geven de tagger en de aanmaakdatum naast de bijbehorende commit weer, terwijl lichtgewicht tags alleen de commit-informatie weergeven.

Git-tags verwijderen

Het kan voorkomen dat u een tag uit uw externe opslagplaats wilt verwijderen. Dit kan het gevolg zijn van een typefout in de tagnaam of misschien heeft u de verkeerde commit getagd. U kunt eenvoudig tags uit de webgebruikersinterface verwijderen door te klikken op het contextmenu van een tag op de pagina Tags en tag verwijderente selecteren (afbeelding 26).

Git-tags filteren

Voor oude opslagplaatsen kan het aantal tags aanzienlijk toenemen met de tijd; er kunnen ook opslagplaatsen zijn die tags hebben gemaakt in hiërarchieën, waardoor het lastig kan zijn om tags te vinden.

Als u de tag die u zoekt niet kunt vinden op de pagina Tags, kunt u gewoon zoeken naar de tagnaam met behulp van het filter boven op de pagina Tags(afbeelding 27).

Beveiliging van Git-tags

U kunt nu gedetailleerde machtigingen verlenen aan gebruikers van de opslagplaats om tags te beheren. U kunt gebruikers de machtiging geven om tags te verwijderen of tags te beheren vanuit deze interface (afbeelding 28).

Automatisch werkitems voltooien bij het voltooien van pull-aanvragen

Als u werkitems koppelt aan uw pull requests, is het bijhouden van alles nu eenvoudiger geworden. Wanneer u een pull request voltooit, hebt u de mogelijkheid om de gekoppelde werkitems automatisch te voltooien nadat de pull request succesvol is samengevoegd (afbeelding 29). Als u beleidsregels gebruikt en pull-aanvragen instelt om automatisch te worden voltooid, ziet u dezelfde optie. Vergeet niet meer om terug te gaan naar werkitems om de status bij te werken zodra de pull-aanvraag is voltooid. Dit wordt automatisch voor u gedaan.

Stemmen opnieuw instellen voor push-/nieuwe iteratie

Teams die kiezen voor een strakker goedkeuringsproces in pull-aanvragen, kunnen kiezen om stemmen opnieuw in te stellen wanneer nieuwe wijzigingen worden doorgevoerd (afbeelding 30). De nieuwe instelling is een optie onder het beleid om een minimum aantal revisoren te vereisen.

Wanneer deze optie is ingesteld, worden alle stemmen van alle revisoren opnieuw ingesteld wanneer de bronbranch van de pull-aanvraag wordt bijgewerkt. Op de PR-tijdlijn wordt een vermelding vastgelegd wanneer de stemmen worden gereset als gevolg van deze optie (Afbeelding 31).

Boom van pull requests filteren op bestandsnaam

Het vinden van een specifiek bestand in een pull-aanvraag is eenvoudiger dan ooit. Met het nieuwe filtervak in de weergave Bestanden kunnen gebruikers de lijst met bestanden in de structuurweergave filteren (afbeelding 32).

Het filter komt overeen met een deel van het pad van de bestanden in de pull-aanvraag, zodat u kunt zoeken op mapnamen, gedeeltelijke paden, bestandsnamen of extensies (afbeelding 33).

Meer filteropties voor opmerkingen bij pull-aanvragen

Opmerkingen in zowel het overzicht van de pull-aanvraag als de bestandsweergave hebben nu dezelfde opties (afbeelding 34). U kunt ook filteren om alleen de discussies weer te geven waaraan u hebt deelgenomen.

Oorspronkelijke diff voor codeopmerkingen in pull-requestdetails weergeven

Soms is het moeilijk om uit een pr-opmerking te komen nadat de code waarnaar wordt verwezen, is gewijzigd (vaak wanneer een aangevraagde wijziging is aangebracht) (afbeelding 35).

Wanneer dit gebeurt, ziet u nu een badge met een updatenummer waarop u kunt klikken om te zien hoe de code eruit zag op het moment dat de opmerking oorspronkelijk is gemaakt (afbeelding 36).

Samenvouwbare opmerkingen bij pull-aanvragen

Het controleren van code is een essentieel onderdeel van de ervaring met pull-aanvragen, dus we hebben nieuwe functies toegevoegd om revisoren zich gemakkelijker te richten op de code. Coderevisoren kunnen eenvoudig opmerkingen verbergen om ze voor het eerst uit de weg te halen bij het beoordelen van nieuwe code (afbeelding 37).

Als u opmerkingen verbergt (afbeelding 38), worden deze verborgen in de structuurweergave en worden de opmerkingenthreads in de bestandsweergave samengevouwen:

Wanneer opmerkingen zijn samengevouwen, kunnen ze eenvoudig worden uitgevouwen door op het pictogram in de marge te klikken en vervolgens opnieuw samenvouwen met een andere klik. Tooltips(afbeelding 39) maken het eenvoudig om een opmerking snel te bekijken zonder de hele thread te zien.

Taaklijsten in beschrijvingen en opmerkingen van pull-aanvragen

Wanneer u een pull-aanvraag of opmerking voorbereidt, hebt u soms een korte lijst met dingen die u wilt bijhouden, maar vervolgens de tekst bewerkt of meerdere opmerkingen toevoegt. Lichtgewicht taaklijsten zijn een uitstekende manier om de voortgang van een takenlijst bij te houden, zowel voor een PR-maker als een reviewer, of dit nu gebeurt in de beschrijving of als een enkele geconsolideerde opmerking. Klik op de Markdown-werkbalk om aan de slag te gaan of pas de opmaak toe op geselecteerde tekst (afbeelding 40).

Nadat u een takenlijst (afbeelding 41) hebt toegevoegd, kunt u gewoon de selectievakjes inschakelen om items als voltooid te markeren. Deze worden uitgedrukt en opgeslagen in de opmerking als [ ] en [x] in Markdown. Zie markdown-richtlijnen voor meer informatie.

Mogelijkheid om opmerkingen leuk te vinden in pull-aanvragen

Toon uw ondersteuning voor een pr-opmerking met één klik op de knop Vind ik leuk(afbeelding 42). U kunt de lijst weergeven met alle personen die de opmerking leuk vonden door de muisaanwijzer over de knop te bewegen.

Verbeterde werkstroom bij het goedkeuren van suggesties

Het gebruik van de optie voor automatisch aanvullen (afbeelding 43) met pull-aanvragen is een uitstekende manier om uw productiviteit te verbeteren, maar het mag geen actieve discussies met coderevisoren verkorten. Om deze discussies beter te vergemakkelijken, wordt de goedkeuring met suggesties nu gevraagd wanneer een pull-aanvraag is ingesteld om automatisch te worden voltooid. De gebruiker heeft de mogelijkheid om het automatisch aanvullen te annuleren, zodat hun feedback kan worden gelezen, of de set voor automatisch aanvullen behouden en toestaan dat de pull-aanvraag automatisch wordt voltooid wanneer aan alle beleidsregels wordt voldaan.

Ondersteuning voor padfiltering voor Git-meldingen

In plaats van meldingen te ontvangen voor alle mappen in een opslagplaats, kunt u er nu voor kiezen om een melding te ontvangen wanneer teamleden pull-aanvragen of pushcode maken in alleen de mappen die u belangrijk vindt. Wanneer u aangepaste e-mailabonnementen maakt voor Git-push- of Git-pullverzoeken, ziet u een nieuwe optie om deze meldingen te filteren op basis van het mappad (Afbeelding 44).

E-mailsjablonen bijgewerkt voor pull-aanvraagwerkstromen

E-mailwaarschuwingen voor pull-aanvragen zijn vernieuwd om ze duidelijk, beknopt en uitvoerbaar te maken (afbeelding 45). De onderwerpregel begint nu met de titel van de pull request en secundaire informatie, zoals de naam van de opslagplaats, en de id wordt naar het einde verplaatst. De naam van de auteur is toegevoegd aan het onderwerp, zodat het eenvoudiger is om regels en filters toe te passen op basis van de persoon die de pull request heeft gemaakt.

De hoofdtekst van de waarschuwingsmails heeft een vernieuwde sjabloon die eerst samenvat waarom de waarschuwing is verzonden, gevolgd door de kritieke metagegevens (titel, vertakkingsnamen en beschrijving) en een hoofdknop voor het aanroepen naar actie. Aanvullende details zoals de reviewers, bestanden en commits worden verderop in de e-mail opgenomen.

Voor de meeste waarschuwingen is de oproep tot actie (afbeelding 46) om de pull request op het web weer te geven. Wanneer u echter op de hoogte wordt gesteld van een specifieke opmerking, wordt de aanroep-naar-actie rechtstreeks aan die opmerking gekoppeld , zodat u eenvoudig de code en het vorige gesprek voor context kunt vinden.

Bijgewerkte e-mailsjablonen voor pushmeldingen

Pushmeldingen zijn bijgewerkt zodat deze overeenkomen met de nieuwe e-mailsjablonen die zijn geoptimaliseerd om duidelijk, beknopt en uitvoerbaar te zijn (afbeelding 47). Met de onderwerpregel kunt u push-e-mailberichten duidelijk onderscheiden, de vertakking, opslagplaats en auteur identificeren en het aantal doorvoeringen in de push samenvatten. Deze wijzigingen maken het ook eenvoudiger om regels en filters te maken om deze e-mailmeldingen te beheren.

De hoofdtekst van de e-mail is consistent met andere e-mailberichten, waarin wordt benadrukt waarom de e-mail is verzonden, wie de actie heeft gestart en precies wat er is gebeurd. Bij pushwaarschuwingen zijn de details over de opslagplaats, branch, bestanden en commits opgenomen om de ontvangers te informeren over het bereik van de wijzigingen. De belangrijkste actie voor pushwaarschuwingen is Push weergeven, waarmee de weergave voor de specifieke push die de waarschuwing heeft gegenereerd, wordt geopend.

Wiki

Elk project ondersteunt nu een eigen Wiki (afbeelding 48). U kunt nu gemakkelijk pagina's schrijven die uw teamleden helpen uw project te begrijpen, te gebruiken en eraan bij te dragen.

Enkele van de belangrijkste functies van de nieuwe wiki zijn:

• Vereenvoudigde bewerkingservaring met behulp van markdown-syntaxis.
• Met de nieuwe pagina kunt u een titel opgeven en inhoud toevoegen. (Afbeelding 49)

• Ondersteuning voor HTML-tags in Markdown (afbeelding 50).

• Pas het formaat van afbeeldingen in de markdown-map (afbeelding 51) aan.

• Krachtige paginabeheervensters waarmee u pagina's opnieuw kunt ordenen, opnieuw kunt ordenen, opnieuw kunt maken en beheren.
• Mogelijkheid om pagina's te filteren op titel voor grote wiki's (afbeelding 52).

• Offline-updates van Wiki voor hoofdgebruikers.

Naarmate u Wiki meer gebruikt, is er een kans dat u onbedoelde wijzigingen opslaat. U kunt nu een revisie terugzetten naar een Wiki-pagina door naar de revisiedetails te gaan en op de knop Terugdraaiente klikken (afbeelding 53).

Een Wiki-pagina maken op basis van een verbroken koppeling

We hebben een patroon waargenomen tijdens het maken van wiki's waarbij een inhoudsopgave op een Wiki-pagina niet-bestaande koppelingen bevatte (afbeelding 54). Gebruikers klikken op deze koppelingen in een poging om een werkelijke pagina te maken. We hebben dit scenario eerder verwerkt door een waarschuwing te geven die aangeeft dat de koppeling is verbroken of dat de pagina niet bestond. We behandelen dit nu als een basisscenario voor Wiki, doordat u in plaats daarvan pagina's kunt maken.

Dieptekoppeling van wikipagina's

Wiki ondersteunt nu secties met dieptekoppelingen binnen een pagina en op verschillende pagina's, wat zeer nuttig is voor het maken van een inhoudsopgave. U kunt verwijzen naar een kop op dezelfde pagina of een andere pagina met behulp van de volgende syntaxis:

• Dezelfde pagina: [text to display](#section-name)
• Een andere pagina: [text to display](/page-name#section-name)

De Wiki-extensie op marketplace is nu afgeschaft. Als u een bestaande Wiki-extensiegebruiker bent, kunt u uw Wiki-pagina's migreren naar de nieuwe Wiki met behulp van dit migratieprogramma. Meer informatie over het migreren van uw bestaande Wiki-pagina's naar de nieuwe Wiki.

Pakketbeheer

Updates van de pakketbeheerervaring

Pakket-URL's werken nu met de pakketnaam en -versie in plaats van met behulp van GUID's. Dit maakt het eenvoudiger om handmatig pakket-URL's (afbeelding 55) te maken. De indeling is: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

U kunt nu verwijderde pakketversies (afbeelding 56) verbergen voor alle feedgebruikers (geen doorgehaalde pakketten meer).)

Elke actie die u op de pagina met pakketgegevens kunt uitvoeren, kan nu worden uitgevoerd vanuit het contextmenu in de lijst met pakketten.

De pakketlijst bevat een nieuwe kolom 'Laatst gepusht' (Afbeelding 57) met leesbare datums, zodat u eenvoudig onlangs bijgewerkte pakketten kunt vinden.

Maven-pakketten

We hebben ondersteuning gelanceerd voor het hosten van Maven-artefacten in TFS 2018 (afbeelding 58). Met Maven-artefacten kunnen Java-ontwikkelaars naadloos code en onderdelen delen. Bekijk onze introductiehandleiding voor het delen van Maven-artefacten met behulp van Pakketbeheer.

Nieuwe uniforme NuGet-taak

We hebben de taak NuGet Restore, NuGet Packager en NuGet Publisher gecombineerd tot een uniforme NuGet-buildtaak om beter af te stemmen op de rest van de build-taakbibliotheek; de nieuwe taak maakt standaard gebruik van NuGet 4.0.0. Daarom hebben we de oude taken afgeschaft en raden we u aan om naar de nieuwe NuGet-taak te gaan wanneer u tijd hebt. Deze wijziging valt samen met een golf van verbeteringen die hieronder worden beschreven, die u alleen kunt openen met behulp van de gecombineerde taak.

Als onderdeel van dit werk hebben we ook een nieuwe NuGet Tool Installer-taak uitgebracht waarmee de versie van NuGet wordt bepaald die beschikbaar is op het PAD en wordt gebruikt door de nieuwe NuGet-taak. Als u dus een nieuwere versie van NuGet wilt gebruiken, voegt u een NuGet Tool Installer-taak toe aan het begin van uw build (afbeelding 59).

NuGet'Toestaan dat duplicaten worden overgeslagen' optie

We hebben van veel NuGet-klanten gehoord dat ze een set pakketten genereren, waarvan er slechts enkele updates kunnen hebben (en daarom bijgewerkte versienummers). De NuGet-buildtaak heeft een nieuwe optie Duplicaten toestaan om te worden overgeslagen , zodat de taak kan doorgaan als wordt geprobeerd pakketten te pushen naar een VSTS/TFS-feed waar de versie al in gebruik is.

npm-buildtaakupdates

Of u nu uw npm-project bouwt in Windows, Linux of Mac, de nieuwe NPM-buildtaak werkt naadloos. We hebben de taak ook opnieuw georganiseerd om zowel npm-installatie als npm-publicatie eenvoudiger te maken. Voor installatie en publicatie hebben we vereenvoudigde referentieverwerving, zodat referenties voor registers die worden vermeld in het .npmrc projectbestand veilig worden opgeslagen in een service-eindpunt. Als u een VSTS-/TFS-feed gebruikt, hebben we ook een kiezer waarmee u een feed kunt selecteren en vervolgens een .npmrc met vereiste referenties genereert die door de buildagent worden gebruikt.

Maven ondersteunt nu geverifieerde feeds

In tegenstelling tot NuGet en npm werkte de Maven-buildtaak niet eerder met geverifieerde feeds. We hebben de Maven-taak bijgewerkt, zodat u eenvoudig kunt werken met VSTS-/TFS-feeds (afbeelding 60).

dotnet-taak ondersteunt geverifieerde feeds, webprojecten

In de volgende primaire versie van de dotnet-taak (2.x) worden veel van uw feedbackaanvragen verwerkt en wordt een aantal bugs opgelost die we een tijdje hebben bijgehouden. Dit omvat het volgende:

1. Eerst ondersteunt dotnet nu geverifieerde pakketbronnen, zoals Pakketbeheer, zodat u de NuGet-taak niet meer hoeft te gebruiken om pakketten uit privépakketbronnen te herstellen.
2. Het gedrag van het veld Pad naar project(en) is gewijzigd in de 2.0-versie van de taak. Als in eerdere versies van de taak de projectbestanden die overeenkomen met het opgegeven patroon niet zijn gevonden, wordt de taak gebruikt om een waarschuwing te registreren en vervolgens te slagen. In dergelijke scenario's kan het soms lastig zijn om te begrijpen waarom de build is geslaagd, maar afhankelijkheden niet zijn hersteld. De taak mislukt nu als de projectbestanden die overeenkomen met het opgegeven patroon niet worden gevonden. Dit is in overeenstemming met het gedrag van andere taken en is gemakkelijk te begrijpen en te gebruiken.
3. In eerdere versies van de opdracht Publiceren van de taak heeft de taak het uitvoerpad gewijzigd door alle bestanden in een map met de naam van het projectbestand te plaatsen, zelfs wanneer u een expliciet uitvoerpad hebt doorgegeven. Dit maakt het moeilijk om opdrachten aan elkaar te koppelen. U hebt nu controle over het uitvoerbestandspad.

We hebben ook een nieuwe dotnet Tool Installer-taak uitgebracht waarmee de versie van dotnet wordt bepaald die beschikbaar is op het PAD en die wordt gebruikt door de nieuwe dotnet-taak. Als u dus een nieuwere versie van dotnet wilt gebruiken, voegt u een dotnet Tool Installer-taak toe aan het begin van uw build.

Werken buiten uw account/verzameling

Het is nu eenvoudiger om te werken met feeds (afbeelding 61) buiten uw TFS-server of VSTS-account, ongeacht of dit pakketbeheerfeeds zijn in een ander VSTS-account of TFS-server of niet-pakketbeheerfeeds, zoals NuGet.org/npmjs.com, Artifactory of MyGet (afbeelding 60). Toegewezen service-eindpunttypen voor NuGet en npm maken het eenvoudig om de juiste referenties in te voeren en ervoor te zorgen dat de buildtaken naadloos kunnen werken in pakketdownload- en pakketpushbewerkingen.

Feedkiezer voor VSTS-/TFS-feeds

Het is altijd raadzaam om een configuratiebestand (bijvoorbeeld NuGet.Config, .npmrc, enzovoort) in te checken, zodat uw bronopslagplaats een record heeft van waaruit uw pakketten afkomstig zijn. We hebben echter verschillende scenario's gehoord waarin dit niet ideaal is, dus hebben we een nieuwe optie Use packages from this VSTS/TFS feed toegevoegd, waarmee u een feed kunt selecteren en automatisch een configuratiebestand kunt genereren dat wordt gebruikt voor die bouwstap (Afbeelding 62).

Build en Release

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-buildprocessen te migreren. Als u nog niet klaar bent om te migreren en XAML-builds wilt blijven gebruiken, voert u een upgrade uit naar TFS 2018 Update 2.

Wanneer u een upgrade uitvoert naar TFS 2018 RTW of Update 1:

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

• U kunt voltooide XAML-builds weergeven, maar u kunt geen nieuwe builds in de wachtrij plaatsen.

• Er is geen nieuwe versie van de XAML-buildcontroller of -agent in TFS 2018.

Wanneer u een upgrade uitvoert naar TFS 2018 Update 2:

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

• U moet Visual Studio of Team Explorer 2017 gebruiken om XAML-builddefinities te bewerken of om 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.

Build-definities exporteren en importeren

Builddefinities worden intern geïmplementeerd als .json bestanden, zodat u details kunt zien over wijzigingen in de geschiedenis van het bestand. U kunt sjablonen al klonen en maken van uw builddefinities, maar veel gebruikers hebben een kopie van hun CI-buildlogica willen maken en opnieuw willen gebruiken in een ander teamproject. Dit was een top-tien aanvraag op UserVoice.

We zijn blij om aan te kondigen dat dit nu mogelijk is (afbeelding 63) en (afbeelding 64)!

Extensies met bouwsjablonen

Met bouwsjablonen kunt u een basislijn maken voor gebruikers om aan de slag te gaan met het definiëren van hun buildproces. We verzenden er vandaag een aantal in de doos en terwijl u nieuwe naar uw account kon uploaden, was het nooit mogelijk voor extensieauteurs om nieuwe sjablonen op te nemen als onderdeel van een extensie. U kunt nu buildsjablonen opnemen in uw extensies. Voorbeeld:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

Zie voor het volledige voorbeeld https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

Een taak in een extensie verwijderen

U kunt nu een taak in uw extensie verwijderen. Als u dit wilt laten werken, moet u de volgende variabele toevoegen aan de nieuwste versie van uw taak:

"deprecated": true

Wanneer de gebruiker naar afgeschafte taken zoekt (afbeelding 65), pushen we deze taken naar het einde en groeperen we ze onder een samenvouwbare sectie die standaard is samengevouwen. Als een definitie al een afgeschafte taak gebruikt, wordt een afgeschafte taakbadge weergegeven om gebruikers aan te moedigen over te schakelen naar de vervanging.

U kunt uw gebruikers helpen meer te weten te komen over de vervangende taak door deze te vermelden in de taakbeschrijving (afbeelding 66). De beschrijving wijst gebruikers vervolgens aan die de taak in de juiste richting gebruiken vanuit zowel de taakcatalogus als de bestaande build-/releasedefinities.

Laat bijgedragen build-secties de zichtbaarheid van secties beheersen.

Als u eerder een extensie gebruikt met buildtaken en overzichtssecties voor bouwen, ziet u de sectie samenvatting van de build, zelfs als u de build-taak in die build niet gebruikt. U kunt deze sectie nu verbergen of weergeven op de overzichtspagina van de build door de volgende regel toe te voegen aan uw extensiecode en de waarde in te stellen op waar of onwaar:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

Bekijk het voorbeeld dat is opgenomen in de opslagplaats microsoft vsts-extension-samples.

Ondersteuning voor variabele groepen

Variabelegroepen zijn beschikbaar voor gebruik in releasedefinities en nu zijn ze ook gereed voor gebruik in builddefinities. Meer informatie over het maken van een variabelegroep. Dit is ontwikkeld en geprioriteerd op basis van gerelateerde suggesties voor build-/releasevariabelen op projectniveau en variabelegroepen in builddefinities.

Werken met beveiligde bestanden zoals Apple-certificaten

We hebben een bibliotheek voor beveiligde bestanden voor algemeen gebruik toegevoegd (afbeelding 67).

Gebruik de beveiligde bestandenbibliotheek om bestanden op te slaan, zoals ondertekeningscertificaten, Apple-inrichtingsprofielen, Android Keystore-bestanden en SSH-sleutels op de server zonder dat u ze hoeft door te voeren naar uw bronopslagplaats.

De inhoud van beveiligde bestanden wordt versleuteld en kan alleen worden gebruikt tijdens build- of releaseprocessen door ernaar te verwijzen vanuit een taak. Beveiligde bestanden zijn beschikbaar in meerdere build- en releasedefinities in het teamproject op basis van beveiligingsinstellingen. Beveiligde bestanden volgen het bibliotheekbeveiligingsmodel.

We hebben ook enkele Apple-taken toegevoegd die gebruikmaken van deze nieuwe functie:

• Hulpprogramma: Apple Certificate installeren

• Hulpprogramma: Apple-voorzieningsprofiel installeren

Build-definities onderbreken

U kunt nu build-definities onderbreken of uitschakelen. Als u van plan bent om wijzigingen aan te brengen in uw builddefinitie en u wilt voorkomen dat nieuwe builds in de wachtrij worden gezet totdat u klaar bent, schakelt u de builddefinitie uit. Als u van plan bent om agentmachines te upgraden, kunt u er ook voor kiezen om een builddefinitie te onderbreken, waardoor VSTS nog steeds nieuwe buildaanvragen accepteert, maar deze in de wachtrij houdt zonder de definitie uit te voeren totdat u de definitie hervat.

Ondersteuning voor taakinvoervalidaties

Het typen van de parameters in builddefinitietaken kan soms foutgevoelig zijn. Met taakinvoervalidatie kunnen taakauteurs ervoor zorgen dat de juiste waarden worden opgegeven. Validatie-expressies volgen de vertrouwde expressiesyntaxis die wordt gebruikt voor taakvoorwaarden en kunnen een van de ondersteunde functies gebruiken naast de algemene functies die worden ondersteund door taakvoorwaarden, waaronder URL, IPV4, e-mail, nummerbereik, sha1, lengte of overeenkomst.

Nieuwe releasedefinitie-editor

Door verder te gaan met het vernieuwen van de build- en release-ervaringen, hebben we de releasedefinitie-editor opnieuw voorgesteld om een intuïtievere ervaring te bieden, enkele pijnpunten op te lossen en nieuwe mogelijkheden toe te voegen. Een van de krachtigste functies van de nieuwe editor is de mogelijkheid om u te helpen visualiseren hoe implementaties in uw omgevingen zouden worden voortgezet. Bovendien zijn goedkeuringen, omgevingseigenschappen en implementatie-instellingen nu in context en eenvoudig te configureren.

Visualisatie van de pijplijn

De pijplijn (afbeelding 68) in de editor biedt een grafische weergave van de voortgang van implementaties in een release. De artefacten worden gebruikt door de release en geïmplementeerd in de omgevingen. De indeling en het koppelen van de omgevingen weerspiegelen de triggerinstellingen die voor elke omgeving zijn gedefinieerd.

In contextconfiguratiegebruikersinterface

Artefacten, releasetriggers, goedkeuringen vóór de implementatie en goedkeuringen na de implementatie, omgevingseigenschappen en implementatie-instellingen zijn nu in context en eenvoudig te configureren (afbeelding 69).

Aan de slag met implementatiesjablonen

Alle ingebouwde implementatiesjablonen zijn uitgerust met procesparameters die het proces voor gebruikers vereenvoudigen door de belangrijkste parameters op te geven zonder dieper in te gaan op de taken (afbeelding 70).

Vereenvoudigd beheer van release- en omgevingsvariabelen

Gebruik de lijstweergave om snel release- of omgevingsvariabelen en de rasterweergave toe te voegen om variabelen naast elkaar te vergelijken en te bewerken. Daarnaast kunt u de zoekfunctie voor filters en trefwoorden gebruiken om de set variabelen te beheren waarmee u in beide weergaven kunt werken.

Verbeterde taak- en fase-editor

Alle verbeteringen in de nieuwe builddefinitie-editor zijn nu ook beschikbaar in de releasedefinitie-editor (afbeelding 72). U kunt taken zoeken en toevoegen met behulp van de knop Toevoegen of met behulp van slepen/neerzetten. U kunt taken opnieuw ordenen of klonen met behulp van slepen/neerzetten.

Tabbladen Variabelegroepen, Retentie en Opties

U kunt nu variabelengroepen koppelen/ontkoppelen (afbeelding 73), bewaarbeleid instellen voor afzonderlijke omgevingen en instellingen op releasedefinitieniveau wijzigen, zoals indeling voor releasenummers op het tabblad Opties . U kunt een omgeving ook opslaan als een implementatiesjabloon, machtigingen op omgevingsniveau instellen en fasen opnieuw ordenen op het tabblad Taken .

Gebruik bewerkingen op omgevingsniveau om op te slaan als sjabloon en beveiliging in te stellen (afbeelding 74).

Implementatie van virtuele machines met behulp van implementatiegroepen

Releasebeheer biedt nu ondersteuning voor robuuste out-of-the-box implementatie met meerdere machines. U kunt nu implementaties op meerdere computers organiseren en rolling updates uitvoeren en tegelijkertijd hoge beschikbaarheid van de toepassing overal garanderen.

Agentgebaseerde implementatiemogelijkheden zijn afhankelijk van dezelfde build- en distributieagents. In tegenstelling tot de huidige benadering waarbij u de build- en implementatieagents op een set proxyservers in een agentgroep installeert en implementaties naar externe doelservers installeert, installeert u de agent op elk van uw doelservers rechtstreeks en worden rollende implementaties naar die servers gestuurd. U kunt de volledige taakcatalogus op uw doelcomputers gebruiken.

Een implementatiegroep (afbeelding 75) is een logische groep doelen (machines) met agents die op elk ervan zijn geïnstalleerd. Implementatiegroepen vertegenwoordigen uw fysieke omgevingen, zoals Dev met één box, QA voor meerdere machines en een farm met machines voor UAT/Prod. Ze geven ook de beveiligingscontext voor uw fysieke omgevingen op.

U kunt dit gebruiken op elke virtuele machine waarmee u onze agent registreert. We hebben het ook heel eenvoudig gemaakt om u bij Azure te registreren met ondersteuning voor een azure-extensie voor virtuele machines waarmee de agent automatisch wordt geïnstalleerd wanneer de virtuele machine wordt uitgevoerd. Tags worden automatisch overgenomen op de virtuele Azure-machine wanneer deze is geregistreerd.

Zodra u een implementatiegroep hebt, configureert u gewoon wat u wilt dat we uitvoeren op die implementatiegroep (afbeelding 76). U kunt bepalen op welke machines wordt uitgevoerd met behulp van tags en bepalen hoe snel of traag de implementatie plaatsvindt.

Wanneer de implementatie wordt uitgevoerd, tonen de logboeken de voortgang van de hele groep machines die u wilt instellen (afbeelding 77).

Deze functie is nu een geïntegreerd onderdeel van Release Management. Er zijn geen extra licenties nodig.

Verbeterde gebruikersinterface voor implementatiegroepen

Door te gaan met het vernieuwen van de build- en release-ervaringen, hebben we onze pagina's voor implementatiegroepen nu opnieuw voorgesteld om het een overzichtelijkere en intuïtievere ervaring te maken (afbeelding 78). Vanaf de landingspagina kunt u de status van de doelen in de implementatiegroep bekijken. U kunt ook beveiliging voor een afzonderlijke implementatiegroep beheren of standaardmachtigingen instellen voor implementatiegroepen.

Voor een doel binnen een implementatiegroep kunt u een samenvatting, recente implementaties en de mogelijkheden van het doel bekijken (afbeelding 79). U kunt tags instellen op het doel en bepalen wat er op elk doel wordt uitgevoerd. We voegen filterondersteuning toe voor implementatiegroepen in toekomstige releases.

Verwijzingen naar taakgroepen

Met taakgroepen kunt u een set taken definiëren die u kunt toevoegen aan uw build- of releasedefinities (afbeelding 80). Dit is handig als u dezelfde groep taken in meerdere builds of releases moet gebruiken. Om u te helpen de consumenten van een taakgroep bij te houden, hebt u nu een overzicht van de builddefinities, releasedefinities en taakgroepen die verwijzen naar uw taakgroep (afbeelding 79).

Wanneer u een taakgroep probeert te verwijderen waarnaar nog steeds wordt verwezen, wordt u gewaarschuwd en krijgt u een koppeling naar deze pagina.

Versiebeheer van taakgroepen

Wanneer u wijzigingen aanbrengt in taakgroepen, kan dit riskant zijn omdat de wijziging effectief is voor alle definities die gebruikmaken van de taakgroep. Met versiebeheer voor takengroepen kunt u nu versies van taakgroepen ontwerpen en bekijken, terwijl u nog steeds stabiele versies aanbiedt aan uw belangrijkste definities totdat u klaar bent om over te schakelen. Na enige formulering en iteratie kunt u een stabiele versie publiceren en, als de wijzigingen ingrijpend zijn, kunt u ervoor kiezen om de taakgroep als preview (een nieuwe primaire versie) te publiceren. U kunt het ook rechtstreeks publiceren als een bijgewerkte stabiele versie (afbeelding 81).

Wanneer er een nieuwe primaire versie (of preview) van de taakgroep beschikbaar is, adviseert de definitie-editor u dat er een nieuwe versie is. Als die belangrijkste versie een voorbeeldversie is, ziet u zelfs het bericht "probeer het uit". Wanneer de taakgroep uit de preview-versie komt, worden definities die deze gebruiken automatisch bijgewerkt en verschuiven ze langs dat primaire kanaal (afbeelding 82).

Takengroep importeren en exporteren

Hoewel taakgroepen hergebruik binnen een project hebben ingeschakeld, weten we dat het opnieuw maken van een taakgroep tussen projecten en accounts pijnlijk kan zijn. Met taakgroep importeren/exporteren (afbeelding 83) zoals we hebben gedaan voor releasedefinities, kunt u nu exporteren als een JSON-bestand en importeren waar u het wilt. We hebben ook geneste taakgroepen ingeschakeld, die eerst worden uitgebreid wanneer ze worden geëxporteerd.

Ondersteuning voor meerdere configuraties in taken aan de serverzijde (zonder agent)

Door variabele vermenigvuldigers op te geven voor taken aan de serverzijde (zonder agent) (afbeelding 84), kunt u nu dezelfde set taken uitvoeren in een fase op meerdere configuraties, die parallel worden uitgevoerd.

Ondersteuning voor variabelen in handmatige interventietaak

De handmatige interventietaak(afbeelding 85) ondersteunt nu het gebruik van variabelen in de instructietekst die aan gebruikers wordt weergegeven wanneer de taak wordt uitgevoerd, op het moment waarop de gebruiker de uitvoering van het releaseproces kan hervatten of het kan weigeren. Variabelen die in de release zijn gedefinieerd en beschikbaar zijn, kunnen worden opgenomen en de waarden worden gebruikt in de meldingen en in de e-mail die naar gebruikers wordt verzonden (afbeelding 86).

Releases beheren in een omgeving op basis van de bronbranch

Een releasedefinitie kan worden geconfigureerd om automatisch een implementatie te activeren wanneer er een nieuwe release wordt gemaakt, meestal nadat een build van de bron is geslaagd. Het is echter mogelijk dat u alleen builds van specifieke vertakkingen van de bron wilt implementeren in plaats van wanneer een build slaagt.

U wilt bijvoorbeeld dat alle builds worden geïmplementeerd in ontwikkel- en testomgevingen, maar dat alleen specifieke builds naar Productie worden geïmplementeerd. Voorheen moest u twee releasepijplijnen onderhouden voor dit doel, een voor de ontwikkel- en testomgevingen en een andere voor de productieomgeving.

Releasebeheer ondersteunt nu het gebruik van artefactfilters voor elke omgeving. Dit betekent dat u de releases kunt opgeven die in elke omgeving worden geïmplementeerd wanneer aan de voorwaarden voor de implementatietrigger (zoals een build is geslaagd en een nieuwe release wordt gemaakt) wordt voldaan. Selecteer in de sectie Trigger van het dialoogvenster Implementatievoorwaarden van de omgeving (afbeelding 87) de artefactvoorwaarden, zoals de bronbranch en tags voor builds die een nieuwe implementatie naar die omgeving activeren.

Daarnaast bevat de pagina Releasesamenvatting(afbeelding 88) nu een pop-uptip die de reden aangeeft waarom alle implementaties die niet zijn gestart, in die staat staan en wordt voorgesteld hoe of wanneer de implementatie wordt gestart.

Releasetriggers voor Git-repositories als artefactbron

Releasebeheer biedt nu ondersteuning voor het configureren van een trigger voor continue implementatie (afbeelding 89) voor Git-opslagplaatsen die zijn gekoppeld aan een releasedefinitie in een van de teamprojecten in hetzelfde account. U kunt hiermee automatisch een release starten wanneer u een nieuwe commit naar de repository doet. U kunt ook een tak specificeren in de Git-opslagplaats waarvoor commits een release activeren.

Releasetriggers: continue implementatie voor wijzigingen die naar een Git-opslagplaats zijn gepusht

Releasebeheer biedt altijd de mogelijkheid om continue implementatie te configureren wanneer een build is voltooid. U kunt nu echter ook continue implementatie configureren in Git Push. Dit betekent dat u GitHub- en Team Foundation Git-opslagplaatsen als artefactbronnen kunt koppelen aan een releasedefinitie en vervolgens automatisch releases kunt activeren voor toepassingen zoals Node.JS en PHP die niet worden gegenereerd op basis van een build en dus geen buildactie nodig hebben voor continue implementatie.

Filters voor vertakkingen in omgevingstriggers

In de nieuwe releasedefinitie-editor kunt u nu artefactvoorwaarden voor een bepaalde omgeving opgeven. Als u deze artefactvoorwaarden gebruikt, hebt u gedetailleerdere controle over welke artefacten in een specifieke omgeving moeten worden geïmplementeerd. Voor een productieomgeving wilt u er bijvoorbeeld voor zorgen dat builds die alleen zijn gegenereerd op basis van de hoofdbranch, worden geïmplementeerd. Dit filter moet worden ingesteld voor alle artefacten die u denkt te voldoen aan dit criterium.

U kunt ook meerdere filters toevoegen voor elk artefact dat is gekoppeld aan de releasedefinitie (afbeelding 90). Implementatie wordt alleen in deze omgeving uitgevoerd als aan alle voorwaarden voor artefacten is voldaan.

Verbeteringen aan taken aan de serverzijde

We hebben twee verbeteringen aangebracht aan taken aan de serverzijde (taken die binnen een serverfase worden uitgevoerd).

We hebben een nieuwe taak toegevoegd die een algemene HTTP REST API (afbeelding 91) aanroept als onderdeel van de geautomatiseerde pijplijn. Het kan bijvoorbeeld worden gebruikt om specifieke verwerking aan te roepen met een Azure-functie en te wachten tot deze is voltooid.

We hebben ook een sectie Besturingsopties(afbeelding 92) toegevoegd aan alle taken aan de serverzijde. Taakgedrag omvat nu het instellen van de opties Ingeschakeld, Doorgaan bij fout, Altijd uitvoeren en Time-out .

Badge Releasestatus in Code Hub

Als u vandaag de dag wilt weten of een doorvoer is geïmplementeerd in uw productieomgeving van de klant, moet u eerst bepalen welke build de doorvoer verbruikt en vervolgens alle releaseomgevingen controleren waar deze build is geïmplementeerd. Deze ervaring is nu veel eenvoudiger met de integratie van de implementatiestatus in de codehubstatusbadge om de lijst met omgevingen weer te geven waarin uw code is geïmplementeerd. Voor elke implementatie wordt de status geplaatst op de meest recente commit die deel uitmaakte van de implementatie. Als een commit wordt geïmplementeerd in meerdere releasedefinities (met meerdere omgevingen), heeft elk een vermelding in de badge, waarbij de status voor elke omgeving wordt weergegeven (afbeelding 93). Dit verbetert de traceerbaarheid van het doorvoeren van code voor implementaties.

Wanneer u een releasedefinitie maakt, wordt standaard de implementatiestatus voor alle omgevingen gepost. U kunt echter selectief de omgevingen kiezen waarvan de implementatiestatus moet worden weergegeven in de statusbadge (bijvoorbeeld alleen productieomgevingen weergeven) (afbeelding 94).

Verbeteringen in het menu Definitie bouwen bij het toevoegen van artefacten

Wanneer u buildartefacten toevoegt aan een releasedefinitie, kunt u de definities nu bekijken met de organisatiegegevens van hun map en het kiezen van de gewenste definitie vereenvoudigen (afbeelding 95). Hierdoor kunt u eenvoudig dezelfde builddefinitienaam onderscheiden, maar in verschillende mappen.

De lijst met definities wordt gefilterd op basis van definities die de filterterm bevatten.

De releasedefinitie herstellen naar een oudere versie

Als een releasedefinitie momenteel wordt bijgewerkt, kunt u niet rechtstreeks terugkeren naar een eerdere versie. De enige manier is om de releasedefinitiegeschiedenis te bekijken om de verschillen van de wijzigingen te vinden en vervolgens de releasedefinitie handmatig te bewerken. Met behulp van de functie Definitie herstellen(afbeelding 96) kunt u nu een oudere versie van een releasedefinitie kiezen en terugkeren naar een oudere versie van een releasedefinitie op het tabblad Geschiedenis van de releasedefinitie.

Gepersonaliseerde meldingen voor releases

Releasemeldingen zijn nu geïntegreerd met de ervaring met VSTS-meldingsinstellingen. Degenen die releases beheren, worden nu automatisch op de hoogte gesteld van in behandeling zijnde acties (goedkeuringen of handmatige interventies) en belangrijke implementatiefouten. U kunt deze meldingen uitschakelen door te navigeren naar de instellingen voor meldingen onder het profielmenu en releaseabonnementen uit te schakelen. U kunt zich ook abonneren op aanvullende meldingen door aangepaste abonnementen te maken. Beheerders kunnen abonnementen voor teams en groepen beheren via de instellingen voor meldingen onder Team - en Accountinstellingen .

Auteurs van releasedefinities hoeven geen e-mailberichten meer handmatig te verzenden voor goedkeuringen en implementatievoltooiingen.

Dit is vooral handig voor grote accounts met meerdere belanghebbenden voor releases en voor andere accounts dan de fiatteur, releasemaker en omgevingseigenaar die mogelijk op de hoogte willen worden gesteld (afbeelding 97).

Testen

Ondersteuning voor Lab Center en geautomatiseerde teststromen verwijderen in Microsoft Test Manager

Met de ontwikkeling van build- en releasebeheer worden XAML-builds niet meer ondersteund in TFS 2018 en daarom werken we ondersteuning bij voor het gebruik van Microsoft Test Manager (MTM) met TFS. Het gebruik van Test Center/Lab Center in MTM voor geautomatiseerde tests wordt niet meer ondersteund door TFS, vanaf TFS 2018. Als u niet klaar bent om te migreren van XAML-builds en Lab Center, moet u geen upgrade uitvoeren naar TFS 2018.

Zie de gevolgen van een upgrade naar TFS 2018 hieronder:

Labcentrum:

• Niet meer ondersteund:
  • Testcontrollers kunnen niet worden geregistreerd bij TFS voor het maken en beheren van labomgevingen.
  • Bestaande testcontrollers die zijn geregistreerd bij TFS, gaan offline en bestaande labomgevingen worden weergegeven als 'Niet gereed'.
• Aanbevolen alternatief:
  • U kunt verbinding maken met uw SCVMM-server met behulp van de SCVMM TFS-extensie, virtuele machines maken en beheren en uw werkstromen erop uitvoeren. Zie Labbeheerbewerkingen uitvoeren in Build en Release voor meer informatie.

Geautomatiseerd testen:

• Niet meer ondersteund:
  • Geautomatiseerde testwerkstromen die afhankelijk zijn van testcontroller- en labomgevingen zoals XAML Build-Deploy-Test-werkstroom of het uitvoeren van geautomatiseerde tests vanuit een testplan met MTM worden niet meer ondersteund.
• Aanbevolen alternatieven:
  • U kunt geautomatiseerde tests uitvoeren in Build en Release.
  • U kunt geautomatiseerde tests uitvoeren vanuit een testplan met behulp van de Test-hub.

Handmatig testen:

• Alle scenario's voor handmatig testen blijven volledig ondersteund. Hoewel handmatige tests kunnen worden uitgevoerd met MTM met TFS 2018, kunnen labomgevingen niet worden gebruikt om handmatige tests uit te voeren.
• Voor alle handmatige testscenario's raden we u ten zeerste aan om de testhub in TFS-webtoegang te gebruiken.

Traceerbaarheidsverbeteringen bij exploratief testen voor werkitemkoppelingen, iteraties en gebiedspaden

Op basis van de feedback die we hebben ontvangen van teams die verkennende tests uitvoeren, verbeteren we traceerbaarheidskoppelingen tijdens het indienen van bugs, taken of testcases uit de extensie Test & Feedback. Fouten en taken die zijn gemaakt tijdens het verkennen van vereisten, worden nu gemaakt met hetzelfde gebiedspad en dezelfde iteratie als die van de vereiste in plaats van de standaardinstellingen van het team. Testcases die zijn gemaakt tijdens het verkennen van vereisten, worden nu gekoppeld aan een Tests <-> Getest door koppeling in plaats van de koppeling Bovenliggend <-> Onderliggend, zodat de door u gemaakte testcases automatisch worden toegevoegd aan testsuites op basis van vereisten. Ten slotte worden werkitems die zijn gemaakt terwijl er geen specifieke vereisten worden verkend, opgeslagen in de standaarditeratie van het team in plaats van de huidige iteratie, zodat er geen nieuwe werkitems in de huidige iteratie komen nadat de sprintplanning is voltooid.

Filters voor testcasewerkitems in testplannen en -suites in Test Hub

Naast de filters voor testvelden, zoals Resultaat, Configuratie en Tester, kunt u nu filteren op de werkitemvelden Test Case, zoals Titel, Staat en Toegewezen aan(afbeelding 98).

Trendgrafieken voor testen van releaseomgevingen en testruns

We voegen ondersteuning toe voor releaseomgevingen in de widget Trend voor testresultaten(afbeelding 99), zodat u de status van testomgevingen op VSTS-dashboards kunt bijhouden. Net zoals u trendgrafieken kunt maken voor testresultaten in Build, kunt u nu trendgrafieken maken die het testsuccespercentage, het aantal geslaagde of mislukte tests, en de testduur voor Release Omgevingen tonen. U kunt de grafieken ook filteren op een specifieke testuitvoering in een omgeving met het titelfilter Testuitvoering .

Markdown-opmaakondersteuning voor opmerkingen over testuitvoering en testresultaten

We voegen ondersteuning toe voor het opmaken van opmerkingen over testuitvoering en testresultaten met markdown-syntaxis. U kunt deze functie gebruiken om opgemaakte tekst of snelle koppelingen naar URL's in uw opmerkingen te maken. U kunt opmerkingen over Test Resultaat bijwerken op de Resultaatoverzicht pagina met Analyse bijwerken en opmerkingen over Testuitvoering bijwerken op de Uitvoeringssamenvatting pagina met Opmerkingen bijwerken in de Test hub.

Koppeling toevoegen aan bestaande fout voor een mislukte test

Tijdens het analyseren van het testresultaat op de overzichtspagina build of release of in de testhub , kunt u nu een bestaande bug aan een mislukte test koppelen. Dit is handig wanneer een test mislukt vanwege een bekende oorzaak waarvoor al een bugrapport is ingediend.

Bijlagen uploaden naar testuitvoeringen en testresultaten

U kunt nu bestanden, zoals schermopnamen en logboekbestanden, bijvoegen om uitvoeringen of testresultaten te testen als aanvullende informatie. Tot nu toe was deze mogelijkheid alleen beschikbaar via de MTM-client (Microsoft Test Manager), waardoor u moet schakelen tussen de testhub in VSTS/TFS en de MTM-client.

Batchen testen

In de Visual Studio-testtaak in Build/Release-beheer zijn opties beschikbaar om te bepalen hoe tests moeten worden gegroepeerd (in batch) voor een efficiënte uitvoering. Tests kunnen op twee manieren worden gegroepeerd:

1. Gebaseerd op het aantal tests en agents dat deelneemt aan de run, waarbij tests eenvoudig worden gegroepeerd in een aantal batches van een opgegeven grootte.
2. Op basis van de eerdere uitvoeringstijd van tests, die rekening houdt met de eerdere uitvoeringstijd om batches van tests te maken, zodat elke batch ongeveer gelijke looptijd heeft (afbeelding 100). Snelle lopende tests worden samen in batches uitgevoerd, terwijl langer lopende tests mogelijk tot een afzonderlijke batch behoren. Deze optie kan worden gecombineerd met de fase-instelling voor meerdere agents om de totale testtijd tot een minimum te beperken.

Webtests uitvoeren met behulp van de VSTest-taak

Met behulp van de Visual Studio-testtaak kunnen webtests, ook wel webprestatietests genoemd, nu worden uitgevoerd in de CI/CD-pijplijn. Webtests kunnen worden uitgevoerd door de tests op te geven die moeten worden uitgevoerd in de invoer van de taakassembly. Elk werkitem voor testcases dat een gekoppelde automatisering heeft en verbonden is met een webtest, kan ook worden uitgevoerd door het testplan/testsuite in de taak (afbeelding 101) te selecteren.

Webtestresultaten zijn beschikbaar als bijlage bij het testresultaat (afbeelding 102). Dit kan worden gedownload voor offlineanalyse in Visual Studio.

Deze mogelijkheid is afhankelijk van wijzigingen in het Visual Studio-testplatform en vereist dat Visual Studio 2017 Update 4 is geïnstalleerd op de build/release-agent. Webtests kunnen niet worden uitgevoerd met eerdere versies van Visual Studio.

Op dezelfde manier kunnen webtests worden uitgevoerd met behulp van de taak Functionele test uitvoeren. Deze mogelijkheid is afhankelijk van wijzigingen in de testagent, die beschikbaar zijn in Visual Studio 2017 Update 5.

Grafiekwidget voor testplannen en testsuites

Voorheen kunt u grafieken maken voor testplannen en -suites in Test Hub en deze vastmaken aan het dashboard. We hebben nu een widget toegevoegd waarmee u grafieken kunt maken voor testplannen en suites vanuit de widgetcatalogus op het dashboard. U kunt grafieken maken voor de ontwerpstatus van de test of de uitvoeringsstatus van de test. Bovendien kunt u met het toevoegen van grafieken vanuit de widget grotere grafieken maken wanneer u meer gegevens wilt weergeven in een grafiek (afbeelding 103).

Schermafbeelding en ondersteuning voor aantekeningen voor desktop-apps met de Chrome-browser voor handmatige tests

We voegen ondersteuning toe voor een van de belangrijkste suggesties van handmatig testen: het vastleggen van schermopnamen van bureaubladtoepassingen van de Web Test Runner in Test Hub. Tot nu toe moest u TestRunner in Microsoft Test Manager gebruiken om schermopnamen van bureaublad-apps vast te leggen. U moet de Test & Feedback-extensie installeren om deze functionaliteit te kunnen gebruiken. We implementeren ondersteuning voor de Chrome-browser en Firefox volgt hierna.

De TFS-extensie voor SharePoint wordt stopgezet

TFS 2018 en latere versies bieden geen ondersteuning meer voor de TFS-extensie voor SharePoint. Daarnaast zijn de schermen die worden gebruikt voor het configureren van integratie tussen een TFS-server en een SharePoint-server verwijderd uit de Team Foundation-beheerconsole.

We hebben een oplossing gemaakt waarmee u integratie op de SharePoint-server kunt uitschakelen. Zie het bericht over de toekomst van onze TFS/SharePoint-integratie voor meer informatie.

Stoppen met teamruimten

Moderne ontwikkelteams zijn sterk afhankelijk van samenwerking. Mensen willen (en hebben) een plaats om de activiteit (meldingen) te bewaken en erover te praten (chat). Een paar jaar geleden hebben we deze trend herkend en de Team Room gebouwd ter ondersteuning van deze scenario's. Sinds die tijd hebben we meer oplossingen gezien om samen te werken in de markt. Met name de toename van Slack. En recenter, de aankondiging van Microsoft Teams.

Omdat er zoveel goede oplossingen beschikbaar zijn die goed kunnen worden geïntegreerd met TFS en Visual Studio Team Services, hebben we in januari de plannen aangekondigd om de functie Teamruimte te verwijderen uit TFS 2018 en Visual Studio Team Services.

Hoe doen we het?

We horen graag van u! U kunt een probleem melden en bijhouden via Developer Community- en advies krijgen over Stack Overflow-.