Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Ontwikkelaarscommunity | Systeemvereisten en compatibiliteit | Licentiebepalingen | TFS DevOps-blog | SHA-1 Hashes | | Meest recente opmerkingen bij de release van Visual Studio 2019|
Opmerking
Dit is niet de nieuwste versie van Team Foundation Server. Als u de nieuwste versie wilt downloaden, gaat u naar de huidige releaseopmerkingen voor Team Foundation Server 2018 Update 3. U kunt de taal van deze pagina wijzigen door op het wereldbolpictogram in de paginavoettekst te klikken en de gewenste taal te selecteren.
In dit artikel vindt u informatie over Team Foundation Server 2017. Klik op de knop om te downloaden.
Voor meer informatie over Team Foundation Server 2017 raadpleegt u de pagina Vereisten compatibiliteitsvereisten voor Team Foundation-servers en -compatibiliteit .
Zie de TFS-installatiepagina voor meer informatie.
Releasedatum: 28 februari 2018
Met deze update worden mogelijke XSS-scripts (Cross Site Scripting) en andere beveiligingsproblemen opgelost. Zie het blogbericht voor meer informatie. Het is een volledige upgrade, zodat u rechtstreeks kunt upgraden naar TFS 2017.0.1.
releasedatum: 16 november 2016
Overzicht van wat er nieuw is in Team Foundation Server 2017
- Code zoeken
- Pakketbeheer
- Agile-verbeteringen
- Dashboards en widgetverbeteringen
- Git-verbeteringen
- Buildverbeteringen
- Verbeteringen in releasebeheer
- Testverbeteringen
- Marketplace-verbeteringen
- Beheerverbeteringen
- Persoonlijke toegangstokens
Bekende problemen
Details van wat er nieuw is in Team Foundation Server 2017
Code zoeken
Codezoekopdrachten bieden snelle, flexibele en nauwkeurige zoekopdrachten voor al uw code. Naarmate uw codebasis wordt uitgebreid en verdeeld over meerdere projecten en opslagplaatsen, wordt het steeds moeilijker om te vinden wat u nodig hebt. Code Search lokaliseert snel en efficiënt relevante informatie in al uw projecten om de samenwerking tussen teams en het delen van code te maximaliseren.
Van het ontdekken van voorbeelden van de implementatie van een API, door de definitie ervan bladeren, tot het zoeken naar fouttekst. Code Search biedt een eenmalige oplossing voor al uw codeverkennings- en probleemoplossingsbehoeften (afbeelding 1).
Code Search biedt:
- Zoeken in een of meer projecten
- Semantische rangschikking
- Uitgebreid filteren
- Samenwerken aan code
Zie zoeken in al uw code voor meer informatie.
Pakketbeheer
Met pakketten kunt u code in uw organisatie delen: u kunt een groot product opstellen, meerdere producten ontwikkelen op basis van een gemeenschappelijk gedeeld framework of herbruikbare onderdelen en bibliotheken maken en delen. Pakketbeheer (afbeelding 2) vereenvoudigt het delen van code door uw pakketten te hosten, ze te delen met de personen die u selecteert en ze gemakkelijk toegankelijk te maken voor Team Build en Release Management.
Pakketbeheer elimineert de noodzaak om een afzonderlijke NuGet-server of bestandsshare te hosten door NuGet-pakketten rechtstreeks in uw Team Foundation Server te hosten. Het biedt eersteklas ondersteuning voor NuGet 3.x en ondersteuning voor verouderde NuGet 2.x-clients. Het werkt naadloos samen met uw bestaande TFS-infrastructuur, teams en machtigingen, dus er is geen noodzaak om identiteiten te synchroniseren, groepen op meerdere plaatsen te beheren, enzovoort. Het kan ook eenvoudig worden geïntegreerd met Team Build, zodat u pakketten kunt maken en gebruiken in werkstromen voor continue integratie.
Zie het overzicht van Pakketbeheer voor meer informatie.
Agile-verbeteringen
In Team Foundation Server 2017 hebben we nieuwe functies en functionaliteit toegevoegd aan werkitems en Kanbanborden.
Nieuw werkitemformulier
Het nieuwe werkitem (afbeelding 3) heeft een nieuw uiterlijk. Er worden ook enkele geweldige nieuwe functies toegevoegd:
- Een rijke discussie-ervaring voor werkitems.
- Ondersteuning voor bijlagen slepen en neerzetten.
- Verbeterde geschiedeniservaring (geschiedenis en controle).
- Verbeterde integratie van code en build.
- Statuskleuring.
- Responsief ontwerp.
Opmerking
Het nieuwe werkitemformulier is alleen de standaard voor nieuwe verzamelingen. Als u een bestaande verzameling migreert, moet u het nieuwe werkitemformulier inschakelen vanuit de beheerinstellingen. Zie De implementatie van het nieuwe webformulier beheren voor meer informatie.
Een werkitem volgen
U kunt nu een waarschuwing instellen voor het bijhouden van wijzigingen in één werkitem door te klikken op de nieuwe knop Volgen (afbeelding 4) in het formulier. Wanneer u een werkitem volgt, ontvangt u een melding wanneer het werkitem wordt gewijzigd, inclusief veldupdates, koppelingen, bijlagen en opmerkingen.
Zie voor meer informatie.
Kanbanbord live-updates
Uw Kanbanbord is nu live!
Heb je F5 geraakt om erachter te komen wat er de hele dag aan de hand is met je Kanban board? Probeer het pictogram in de onderstaande schermopname (afbeelding 5).
Wanneer iemand in uw team een werkitem op het bord maakt, bijwerkt of verwijdert, ontvangt u direct live updates op uw bord. Wanneer de beheerder updates op board- of team-niveau uitvoert, zoals het toevoegen van een nieuwe kolom of het activeren van bugs in de achterstand, wordt u op de hoogte gesteld om het scrumboard te vernieuwen om de indeling bij te werken. U hoeft alleen maar het torenpictogram op uw Kanbanbord in te schakelen en samen te werken met uw team.
Zie De basisbeginselen van Kanban voor meer informatie.
Controlelijstverbeteringen
We hebben verschillende verbeteringen aangebracht in de werking van controlelijsten.
Titels van controlelijsten worden nu weergegeven als hyperlinks (afbeelding 6). U kunt op de titel klikken om het werkitemformulier te openen.
Controlelijsten ondersteunen nu ook contextmenu's waarmee u controlelijstitems (afbeelding 7) kunt openen, bewerken of verwijderen.
Zie Controlelijsten voor taken toevoegen voor meer informatie.
Epic en Feature Board Uitsplitsen
U kunt nu dieper ingaan op uw Epic- en Feature-boards (Afbeelding 8). Met de controlelijstindeling kunt u eenvoudig werk markeren als voltooid en biedt u een handig overzicht van het voltooide versus uitstekende werk.
Zie Kanban-functies en epics voor meer informatie.
Annotaties op het bord in-/uitschakelen
We geven u meer controle over de aanvullende informatie die op de kaarten op uw borden wordt weergegeven. U kunt nu aantekeningen selecteren die u wilt weergeven op uw Kanbankaarten (afbeelding 9). Deselecteer eenvoudig een aantekening en deze verdwijnt van de kaarten op uw Kanban-bord. De eerste twee aantekeningen die hier worden weergegeven, zijn subwerkitems (taken in dit voorbeeld) en de Test-aantekening.
Zie Kaarten aanpassen voor meer informatie.
Opmaak wissen opdracht
We hebben een nieuw commando toegevoegd aan alle rich text controls op werkitems, waarmee je alle opmaak van geselecteerde tekst kunt wissen. Als u zoals de meeste gebruikers bent, heeft u waarschijnlijk in het verleden problemen ondervonden toen u opgemaakte tekst in dit veld kopieerde en plakte die u niet kunt ongedaan maken (of wissen). U kunt nu gewoon tekst markeren, de werkbalkknop Opmaak wissen selecteren (of op Ctrl+spatiebalk drukken) en u ziet dat de tekst teruggaat naar de standaardindeling.
Filteren op het Kanbanbord
Pas uw Kanbanborden aan door filters in te stellen op gebruikers, iteraties, werkitemtypen en tags (afbeelding 10). Deze filters blijven behouden, zodat u uw persoonlijke bord kunt bekijken, zelfs wanneer u verbinding maakt vanaf meerdere apparaten.
Teamleden kunnen hun werkborden filteren om ook de voortgang van een specifiek bovenliggend werkitem weer te geven. Een gebruiker kan bijvoorbeeld gebruikersverhalen bekijken die zijn gekoppeld aan een functie of werk weergeven in twee of meer functies die samen een episch verhaal vormen. Deze functie, net als checklists, is nog één stap in onze inspanningen om inzicht te krijgen in de verschillende achterstandsniveaus.
Zie Het Filter Kanban-bord voor meer informatie.
Standaard iteratiepad voor nieuwe werkitems
Wanneer u een nieuw werkitem maakt op het tabblad Query's of vanuit de dashboardwidget Nieuw werkitem, wordt het iteratiepad van dat werkitem altijd ingesteld op de huidige iteratie. Dit is niet wat alle teams willen, omdat dit betekent dat bugs onmiddellijk op het takenbord kunnen verschijnen. Met deze verbetering kunnen teams het standaarditeratiepad (een specifieke of de huidige iteratie) kiezen die moet worden gebruikt voor nieuwe werkitems. Navigeer naar het beheergebied voor uw team om een standaarditeratie te kiezen.
Zie de pagina Gebied aanpassen en iteratiepaden voor meer informatie.
Selectievakje
U kunt nu een selectievakje toevoegen aan uw werkitems (afbeelding 11). Dit nieuwe veldtype (Booleaanse waarde) heeft alle eigenschappen van normale velden en kan worden toegevoegd aan elk type in uw proces. Wanneer deze wordt weergegeven op kaarten of in een queryresultaat, wordt de waarde weergegeven als Waar/Onwaar.
Zie Een veld aanpassen voor meer informatie.
Tags bulksgewijs bewerken
U kunt nu tags toevoegen aan en verwijderen uit meerdere werkitems met behulp van het dialoogvenster bulkbewerking (afbeelding 12).
Zie Tags toevoegen aan werkitems voor meer informatie.
Nieuwe uitbreidingspunten
We hebben een nieuw bijdragepunt toegevoegd op de board- en backlogpagina's, zodat u extensies kunt schrijven als een zwenktabblad naast de Board/Backlog/Capacity-tabbladen.
We hebben een nieuw extensiepunt op de backlog beschikbaar gesteld. Extensies kunnen zich richten op het deelvenster aan de rechterkant, waar momenteel de toewijzings- en werkdetails zijn (afbeelding 13).
E-mailverbeteringen
We hebben de opmaak en bruikbaarheid van waarschuwingen, volgactiviteiten en @mention e-mailberichten die door TFS worden verzonden aanzienlijk verbeterd (afbeelding 14). E-mailberichten bevatten nu een consistente koptekst, een duidelijke aanroep naar actie en verbeterde opmaak om ervoor te zorgen dat de informatie in de e-mail gemakkelijker te gebruiken en te begrijpen is. Bovendien zijn al deze e-mailberichten ontworpen om ervoor te zorgen dat ze goed worden weergegeven op mobiele apparaten.
Zie Waarschuwingen voor werkitems voor meer informatie.
Sjablonen voor werkitems
We hebben de mogelijkheid toegevoegd om uitgebreide werkitemsjablonen rechtstreeks te maken in de systeemeigen webervaring (afbeelding 15). Deze mogelijkheid was voorheen zeer beperkt in de webomgeving en alleen beschikbaar in deze nieuwe vorm via een krachtige tool voor Visual Studio. Teams kan nu een set sjablonen maken en beheren om snel algemene velden te wijzigen.
Zie Werkitemsjablonen voor meer informatie.
Project Server-integratie wordt niet meer ondersteund
Team Foundation Server 2017 en latere versies bieden geen ondersteuning meer voor Project Server-integratie. Als u vanaf RC2 een TFS-database bijwerkt waarvoor Project Server-integratie is geconfigureerd, ontvangt u de volgende waarschuwing:
Er is vastgesteld dat u Project Server-integratie hebt geconfigureerd voor deze database. Team Foundation Server 2017 en latere versies bieden geen ondersteuning meer voor Project Server-integratie.
Na de upgrade werkt de Integratie van Project Server niet meer.
In de toekomst vertrouwen we op Partners om integratieoplossingen te bieden.
Lees het volgende onderwerp voor meer informatie over deze wijziging: TFS synchroniseren met Project Server.
Verbeteringen in dashboards en widgets
Team Foundation Server 2017 heeft verbeteringen aangebracht op meerdere widgets, zoals de querytegel en pull-aanvraagwidgets.
Opnieuw ontworpen widgetcatalogus
We hebben onze widgetcatalogus opnieuw ontworpen voor de groeiende set widgets en bieden een betere algehele ervaring (afbeelding 16). Het nieuwe ontwerp bevat een verbeterde zoekervaring en is aangepast aan het ontwerp van onze widgetconfiguratiepanelen.
Zie Widgetcatalogus voor meer informatie.
Widget updates
De widget Querytegel ondersteunt nu maximaal 10 voorwaardelijke regels en heeft selecteerbare kleuren (afbeelding 17). Dit is zeer handig als u deze tegels wilt gebruiken als kritieke prestatie-indicatoren (KPI) om de gezondheid en/of actie te identificeren die mogelijk nodig zijn.
De widget Pull-aanvraag ondersteunt nu meerdere grootten, zodat gebruikers de hoogte van de widget kunnen beheren. We werken eraan om de meeste widgets die we leveren resizeerbaar te maken, dus houd hier meer in de gaten.
Met de widget Nieuw werkitem kunt u nu het standaardtype werkitem selecteren in plaats van dat u gedwongen wordt iedere keer het meest voorkomende type te selecteren uit de vervolgkeuzelijst.
We hebben WIT-grafiekwidgets aanpasbaar gemaakt. Hierdoor kunnen gebruikers een uitgebreide weergave van een WIT-grafiek op het dashboard zien, ongeacht de oorspronkelijke grootte.
We hebben de widget Teamleden bijgewerkt om het gemakkelijker te maken om iemand aan uw team toe te voegen (afbeelding 18).
Teams kan nu de grootte van de widget Queryresultaten van het dashboard configureren, zodat er meer resultaten kunnen worden weergegeven.
De widget Sprint-overzicht is opnieuw ontworpen, zodat teams gemakkelijker kunnen zien of ze op schema zijn.
Met de widget Toegewezen aan mij kunnen gebruikers het werk beheren dat aan hen is toegewezen zonder de context van het dashboard (afbeelding 19) te verlaten. Door een widget te bieden die aan dit doel is toegewezen, kunnen teambeheerders deze functionaliteit met 16 klikken toevoegen aan hun dashboards, geen contextswitches en geen typen vereist. Gebruikers kunnen nu het werk bekijken, sorteren, filteren en beheren dat aan hen is toegewezen in de widgetcontext.
REST API's voor dashboards
U kunt nu REST API's gebruiken om programmatisch informatie op een dashboard toe te voegen, te verwijderen en op te halen. Met de API's kunt u ook informatie toevoegen, verwijderen, bijwerken, vervangen en ophalen over een widget of een lijst met widgets op een dashboard. De documentatie is beschikbaar in onlinedocumenten van Visual Studio.
Toegestane dashboards
Niet-beheerders kunnen nu teamdashboards maken en beheren. Teambeheerders kunnen niet-beheerdersmachtigingen beperken via de dashboardmanager.
Zie Dashboards voor meer informatie.
Git-verbeteringen
Er zijn enkele belangrijke wijzigingen aangebracht in Git voor Team Foundation Server 2017. Inbegrepen zijn een herontwerp van de pagina 'Branches' en een nieuwe optie om 'squash merge' te gebruiken.
Opnieuw ontworpen Vertakkingen-pagina
De pagina Branches is volledig opnieuw ontworpen. Het heeft een "eigen" draaipunt met de vertakkingen die u hebt gemaakt, gepusht naar of als voorkeurs gemarkeerd(afbeelding 20). Elke vertakking toont de status van build- en pull-aanvragen, evenals andere opdrachten, zoals Delete. Als er een slash in een vertakkingsnaam staat, zoals 'features/jeremy/fix-bug', wordt het weergegeven als een boomstructuur, zodat je eenvoudig door een grote lijst met vertakkingen kunt bladeren. Als u de naam van uw tak kent, kunt u snel de gewenste tak vinden.
Zie Vertakkingen beheren voor meer informatie over vertakkingen.
Nieuwe ervaring voor pull-aanvragen
De ervaring met pull-aanvragen heeft enkele belangrijke updates voor deze release, waardoor een aantal zeer krachtige diff-mogelijkheden, een nieuwe ervaring voor opmerkingen en een volledig vernieuwde gebruikersinterface worden toegevoegd.
Zie Code controleren met pull-aanvragen voor meer informatie.
Opnieuw ontworpen gebruikersinterface
Bij het openen van een pull-aanvraag is het nieuwe uiterlijk onmiddellijk duidelijk (afbeelding 21). We hebben de header opnieuw ingedeeld om alle kritieke status en acties samen te vatten, zodat ze toegankelijk zijn vanuit elke weergave in de ervaring.
Overzicht
Het overzicht markeert nu de beschrijving van de Pull Request en maakt het eenvoudiger dan ooit om feedback te leveren (afbeelding 22). Gebeurtenissen en opmerkingen worden weergegeven met de nieuwste items bovenaan, zodat beoordelaars de laatste wijzigingen en opmerkingen direct en centraal kunnen zien. Beleidsregels, werkitems en revisoren worden allemaal gedetailleerd en gereorganiseerd om duidelijker en beknopter te zijn.
Files
De grootste nieuwe functie in deze release is de mogelijkheid om eerdere updates voor een pull-aanvraag (afbeelding 23) te zien. In eerdere previews hebben we de mogelijkheid geïntroduceerd om opmerkingen correct bij te houden als een pull request wordt bijgewerkt met wijzigingen. Het is echter niet altijd gemakkelijk om te zien wat er tussen updates is. In de weergave Bestanden kunt u nu precies zien wat er is gewijzigd telkens wanneer er nieuwe code naar uw pull request wordt gepusht. Dit is erg handig als u feedback hebt gegeven over bepaalde code en precies wilt zien hoe deze is gewijzigd, geïsoleerd van alle andere wijzigingen in de beoordeling.
Updates
In de nieuwe weergave Updates ziet u hoe de PR in de loop van de tijd verandert (afbeelding 24). Waar de weergave Bestanden laat zien hoe de bestanden in de loop van de tijd zijn gewijzigd, worden in de weergave Updates de doorvoeringen weergegeven die in elke update zijn toegevoegd. Als er ooit een geforceerde push plaatsvindt, worden in de weergave Updates de eerdere updates weergegeven zoals ze zich in de geschiedenis hebben voorgedaan.
Opmerkingen, nu met markdown en emoji
Gebruik de volledige kracht van Markdown in al uw discussies, inclusief opmaak, code met syntaxismarkering, koppelingen, afbeeldingen en emoji (afbeelding 25). De besturingselementen voor opmerkingen hebben ook een gebruiksvriendelijkere bewerkingservaring, zodat meerdere opmerkingen tegelijk kunnen worden bewerkt (en vervolgens opgeslagen).
Revisoren toevoegen aan en verwijderen uit pull-aanvragen
Het is nu eenvoudiger om revisoren toe te voegen aan en te verwijderen uit uw pull-aanvragen. Als u een revisor of groep wilt toevoegen aan uw pull-aanvraag, voert u de naam in het zoekvak in de sectie Revisoren in. Als u een revisor wilt verwijderen, plaatst u de muisaanwijzer op de tegel in de sectie Revisoren en klikt u op de X om deze te verwijderen (afbeelding 26).
Verbeterde tracering van build- en pull-aanvragen
De traceerbaarheid tussen builds en pull-aanvragen is verbeterd, waardoor u eenvoudig kunt navigeren van een pull-aanvraag naar een build en terug. In de weergave met builddetails voor een build die wordt geactiveerd door een pull-aanvraag, wordt in de bron nu een koppeling weergegeven naar de pull-aanvraag die de build in de wachtrij heeft geplaatst. In de weergave Build-definities geeft elke build die wordt geactiveerd door een pull-aanvraag een koppeling naar de pull-aanvraag in de kolom Geactiveerd door. Ten slotte worden in de weergave Build Explorer pull-aanvragen in de bronkolom weergegeven.
Opmerkingen bijhouden voor pull-aanvragen
Pull-aanvragen in VSTS zijn verbeterd om opmerkingen weer te geven die op de juiste regel in bestanden staan, zelfs als deze bestanden zijn gewijzigd sinds de opmerkingen zijn toegevoegd. Eerder werden opmerkingen altijd weergegeven op de regel van het bestand waar ze oorspronkelijk werden toegevoegd, zelfs als de bestandsinhoud werd gewijzigd, met andere woorden, een opmerking op regel 10 zou altijd worden weergegeven op regel 10. Met de nieuwste verbeteringen volgt u de code om aan te geven wat de gebruiker verwacht: als er een opmerking wordt toegevoegd op regel 10 en er vervolgens twee nieuwe regels aan het begin van het bestand zijn toegevoegd, wordt de opmerking weergegeven op regel 12.
Hier volgt een voorbeeldwijziging met een opmerking op regel 13 (afbeelding 27):
Zelfs nadat de code is gewijzigd om de regel met de oorspronkelijke opmerking van 13 naar 14 te verplaatsen, wordt de opmerking weergegeven op de verwachte plaats op regel 14 (afbeelding 28).
Automatisch voltooien van pull-aanvragen die wachten op beleid
Teams die vertakkingsbeleid gebruiken om hun vertakkingen te beveiligen, willen de actie voor automatisch voltooien bekijken. Vaak is de auteur van een pull-aanvraag klaar om hun PR samen te voegen, maar ze wachten totdat een build voltooid is voordat ze op Voltooid kunnen klikken. Soms slaagt de build, maar is er één reviewer die de definitieve goedkeuring nog niet heeft gegeven. In deze gevallen kan de auteur met de actie voor automatisch aanvullen de pull-aanvraag zo instellen dat deze automatisch wordt voltooid zodra alle beleidsregels zijn goedgekeurd (afbeelding 29).
Net als bij de handmatige bewerking voor het voltooien van de bewerking, heeft de auteur de mogelijkheid om het bericht van de samenvoegingsdoorvoering aan te passen en de juiste samenvoegopties te selecteren (afbeelding 30).
Zodra autocompleteren is ingesteld, wordt in de pull request een banner weergegeven die bevestigt dat de autocompletering is ingesteld en wacht tot de policies zijn afgerond (afbeelding 31).
Wanneer aan alle beleidsregels wordt voldaan (bijvoorbeeld wanneer de build is voltooid of de definitieve goedkeuring is verleend), wordt de pull request samengevoegd met behulp van de opgegeven opties en opmerkingen. Als er een buildfout optreedt of de beoordelaar niet goedkeurt, blijft de pull request actief totdat aan de beleidsregels is voldaan.
Pull-verzoeken voor squash merge
Wanneer u een pull-aanvraag voltooit, hebt u nu de mogelijkheid om samen te voegen (afbeelding 32). Deze optie creëert een enkele commit met de wijzigingen van de topicbranch die op de targetbranch wordt toegepast. Het meest opvallende verschil tussen een reguliere samenvoegcommit en een squashsamenvoegcommit is dat de squashsamenvoegcommit slechts één bovenliggende commit heeft. Dit betekent een eenvoudiger commitgeschiedenis, omdat tussenliggende commits die zijn gemaakt in de thematische tak niet bereikbaar zijn in het resulterende commitdiagram.
Meer informatie vindt u bij Squash merge pull-aanvragen.
Traceerbaarheid doorvoeren
De buildstatus (geslaagd of mislukt) is nu duidelijk zichtbaar in de weergaven CodeVerkenner en Details doorvoeren (afbeelding 33). Meer details zijn slechts een klik verwijderd, dus u zult altijd weten of de wijzigingen in de doorvoering de build hebben doorgegeven of niet. U kunt ook aanpassen welke builds de status publiceren in de repositoryopties voor de builddefinitie. Daarnaast bieden de meest recente wijzigingen in de weergave Doorvoerdetails meer inzicht in uw wijzigingen. Als u pull requests gebruikt om uw wijzigingen samen te voegen, ziet u de koppeling naar de pull request die de wijzigingen heeft geïntroduceerd in de hoofdvertakking (of in het geval van een merge commit, de pull request die deze heeft gemaakt). Wanneer uw wijzigingen de main branch hebben bereikt, verschijnt de branch-link om te bevestigen dat de wijzigingen zijn opgenomen.
Git LFS-bestanden weergeven op het web
Als u al werkt met grote bestanden in Git (audio, video, gegevenssets, enzovoort), weet u dat Git Large File Storage (LFS) deze bestanden vervangt door aanwijzers in Git, terwijl u de bestandsinhoud opslaat op een externe server. Hierdoor kunt u de volledige inhoud van deze grote bestanden bekijken door gewoon op het bestand in uw opslagplaats te klikken.
Zie Grote bestanden beheren met Git voor meer informatie.
Koppelingen maken en verzenden naar specifieke secties met code
U kunt eenvoudig codeverwijzingen delen met codekoppelingen (afbeelding 34). Selecteer gewoon tekst in een bestand en klik op het pictogram Koppeling. Er wordt een koppeling naar de geselecteerde code gekopieerd. Wanneer iemand die koppeling bekijkt, heeft de code die u hebt gemarkeerd een gouden achtergrond. Het werkt zelfs voor gedeeltelijke lijnselecties.
Status-API
Het slagen of mislukken van de build is nu duidelijk zichtbaar in de codeverkenner en doorvoergegevensweergaven (afbeelding 35). Meer details zijn slechts een klik verwijderd, dus u weet altijd of de wijzigingen in de doorvoering de build hebben doorgegeven of niet. U kunt ook aanpassen welke builds hun buildstatus in de repository-instellingen van de builddefinitie posten.
Pictogrammen voor bestandstype
U ziet nieuwe bestandspictogrammen die overeenkomen met de extensie van het bestand in de verkenner, pull requests, commitdetails, shelveset, changeset of een andere weergave die een lijst met bestanden toont (afbeelding 36).
Een Leesmij toevoegen bij het aanmaken van een opslagplaats
Het maken van de nieuwe Git-opslagplaats is verbeterd door gebruikers de mogelijkheid te bieden een ReadMe-bestand toe te voegen (afbeelding 37). Door een ReadMe aan de repository toe te voegen, kunnen anderen niet alleen het doel van de codebase begrijpen, maar kunt u de repository ook meteen klonen.
Buildverbeteringen
In deze release hebben we de grootte van de logboeken vergroot, Java-buildsjablonen toegevoegd en verbeteringen aan onze Xamarin-ondersteuning toegevoegd om enkele wijzigingen te noemen.
Opnieuw ontworpen tabblad buildwachtrij
We hebben een nieuw ontwerp geïmplementeerd voor de pagina Builds in wachtrij waarin een langere lijst met builds in de wachtrij en actieve builds wordt weergegeven, en op een intuïtievere manier (afbeelding 38).
Zie Uw buildsysteem beheren voor meer informatie.
Extensies voor buildresultaten inschakelen om volgorde en kolom op te geven
Sectie-extensies voor build-resultaten kunnen nu aangeven in welke kolom en in welke volgorde ze worden weergegeven (afbeelding 39). De resultaatweergave heeft twee kolommen en alle extensies bevinden zich standaard in de eerste kolom. Opmerking: alle extensies van derden worden weergegeven na de secties met buildresultaten die we opnemen.
Opbouwen naar regelnummer
U kunt nu van een buildfout naar de coderegel springen die dit heeft veroorzaakt. Als u de meest recente fout bekijkt in de primaire build die we intern gebruiken als beleid voor pull-aanvragen, ziet u dit
De buildlogboekweergave ondersteunt veel grotere logboeken
De vorige logboekweergave ondersteunt alleen logboeken tot 10.000 regels. De nieuwe viewer is gebaseerd op de Monaco-editor die wordt gebruikt in VS Code en ondersteunt logboeken tot 150.000 regels.
Java-buildsjablonen
We hebben het voor Java-ontwikkelaars nog eenvoudiger gemaakt om aan de slag te gaan met bouwen door buildsjablonen toe te voegen voor Ant, Maven en Gradle (afbeelding 41).
Zie Build-stappen voor meer informatie over sjablonen.
Xamarin-buildtaken
We hebben enkele belangrijke verbeteringen aangebracht in onze Xamarin-ondersteuning:
- De Xamarin.Android-stap ondersteunt nu Mac en Linux.
- De Xamarin.iOS-stap ondersteunt nu ondertekening en verpakking.
- Xamarin Test Cloud-resultaten kunnen worden weergegeven op de overzichtspagina van de build.
- Een nieuwe herstelstap voor Xamarin-onderdelen.
- De stap NuGet Installer ondersteunt nu Mac OS.
De Xamarin-licentiestap is niet meer nodig en is verwijderd uit de buildsjablonen. Als onderdeel van deze inspanningen heffen we de taak op. Alle builddefinities die deze taak gebruiken, moeten worden bijgewerkt om deze te verwijderen om onderbrekingen te voorkomen wanneer de taak eindelijk wordt verwijderd.
Ten slotte hebben we de Xamarin-builddefinitiesjablonen uitgebreid om deze nieuwe taken te gebruiken. Bouw uw Xamarin-app.
Docker-integratie voor build- en releasebeheer
Profiteer van de bouwmogelijkheden om Docker-images te maken en te uploaden naar de Docker Hub in uw continue integratiestroom (afbeelding 42). Implementeer deze installatiekopieën vervolgens op een aantal Docker-hosts als onderdeel van Releasebeheer. Met de Marketplace-extensie worden alle typen service-eindpunten en taken toegevoegd die nodig zijn om met Docker te werken.
SonarQube-resultaten in pull-aanvraagweergave
Als de build-uitvoering voor het samenvoegen van een pull-aanvraag SonarQube MSBuild-taken bevat, ziet u nu nieuwe problemen met codeanalyse als discussieopmerkingen in de pull-aanvraag (afbeelding 43). Deze ervaring werkt voor elke taal waarvoor een invoegtoepassing is geïnstalleerd op de SonarQube-server. Zie voor meer informatie de blogpost Integratie van SonarQube Code Analysis problemen in Pull Requests.
Status-API-rapportage configureren voor een builddefinitie
U kunt nu kiezen welke builddefinities hun status weer rapporteren aan de Git-status-API. Dit is met name handig als u veel definities hebt die een bepaalde repository of vertakking bouwen, maar slechts één definitie heeft die de echte status weergeeft.
Zie de naslaginformatie over de Build REST API voor meer informatie.
VNext-ondersteuning bouwen in teamruimten
Het is altijd mogelijk om meldingen van XAML-builds toe te voegen in de teamruimte. Met deze sprint kunnen gebruikers ook meldingen ontvangen van Build vNext-voltooiingen.
Padfilters inschakelen voor Git CI-triggers
CI-triggers voor gehoste Git-opslagplaatsen kunnen bepaalde paden bevatten of uitsluiten. Hiermee kunt u een builddefinitie zo configureren dat deze alleen wordt uitgevoerd wanneer bestanden in specifieke paden zijn gewijzigd (afbeelding 44).
Verbeteringen in releasebeheer
Sinds de introductie van geïntegreerd webgebaseerde releasebeheer in Team Foundation Server 2015 hebben we verschillende verbeteringen aangebracht in deze versie.
Releasedefinities klonen, exporteren en importeren
We hebben de mogelijkheid opgenomen om releasedefinities te klonen, exporteren en importeren in Release Hub, zonder dat hiervoor een extensie hoeft te worden geïnstalleerd (afbeelding 45).
Zie de documentatie over het klonen, exporteren en importeren van een releasedefinitie voor meer informatie.
Testresultaten weergegeven in de releasesamenvatting
Op de overzichtspagina van de release hebben we een bijdragepunt ingeschakeld voor een externe service om omgevingsspecifieke informatie weer te geven.
In Team Services wordt deze functionaliteit gebruikt om een samenvatting van de testresultaten weer te geven wanneer tests worden uitgevoerd als onderdeel van een releaseomgeving (afbeelding 46).
Zie De overzichtsweergave van een releasedocumentatie begrijpen voor meer informatie.
OAuth-tokens doorgeven aan scripts
Als u een aangepast PowerShell-script moet uitvoeren waarmee de REST API's in Team Services worden aangeroepen, moet u mogelijk een werkitem maken of een query uitvoeren op een build voor informatie. U moet het OAuth-token doorgeven in het script.
Met een nieuwe optie wanneer u een omgeving configureert, kunnen scripts als taken in de omgeving worden uitgevoerd voor toegang tot het huidige OAuth-token (afbeelding 47).
Zie de documentatie over algemene opties voor omgevingen voor meer informatie.
Dit is een eenvoudig voorbeeld waarin wordt getoond hoe u een builddefinitie kunt ophalen
Trigger bij gedeeltelijk geslaagde implementaties
Build- en releasetaken hebben de optie om door te gaan ondanks fout in de controleoptiesparameters voor elke taak.
In een builddefinitie resulteert dit in een gedeeltelijk voltooid buildresultaat als een taak met deze optieset mislukt.
Hetzelfde gedrag is nu beschikbaar in releasedefinities. Als een taak mislukt, wordt het algehele releaseresultaat weergegeven als 'Release gedeeltelijk geslaagd' (afbeelding 49).
Een gedeeltelijk geslaagde release activeert standaard niet automatisch een release naar een volgende omgeving, zelfs als dit gedrag is opgegeven in de implementatieopties voor de omgeving.
Er kan echter een nieuwe optie worden ingesteld in elke releaseomgeving waarmee releasebeheer wordt geïnstrueerd om een release naar een volgende omgeving te activeren wanneer de vorige release gedeeltelijk is geslaagd (afbeelding 50).
Zie de documentatie over implementatietriggers voor omgevingen voor meer informatie.
Artefacten gebruiken die rechtstreeks zijn opgeslagen in GitHub
Soms wilt u artefacten die zijn opgeslagen in een versiebeheersysteem rechtstreeks gebruiken, zonder ze door te geven via een buildproces, zoals beschreven in dit onderwerp.
U kunt nu hetzelfde doen als uw code is opgeslagen in een GitHub-opslagplaats (afbeelding 51).
Zie de documentatie over TFVC-, Git- en GitHub-bronnen voor meer informatie.
Implementatie van web-apps met ARM
Er is een nieuwe versie van de azure-web-app-implementatietaak beschikbaar, genaamd AzureRM-web-app-implementatie.
Het maakt gebruik van MSDeploy en een Azure Resource Manager-service-eindpuntverbinding. Gebruik deze taak om Azure-webtaken en Azure API-apps te implementeren, naast ASP.NET 4-, Node- en Python-web-apps.
De taak ondersteunt ook algemene publicatieopties, zoals de mogelijkheid om app-gegevens te bewaren, een app off-line te halen en extra bestanden op de bestemming te verwijderen.
Meer functies, zoals configuratietransformaties, kunnen worden weergegeven in toekomstige versies (afbeelding 52).
Taakgroepen
Met een taakgroep kunt u een reeks taken inkapselen die al zijn gedefinieerd in een build- of releasedefinitie in één herbruikbare taak die kan worden toegevoegd aan een build- of releasedefinitie, net zoals elke andere taak (afbeelding 53).
U kunt ervoor kiezen om de parameters uit de ingekapselde taken als configuratievariabelen te extraheren en de rest van de taakgegevens te abstraheren.
De nieuwe taakgroep wordt automatisch toegevoegd aan de taakcatalogus, klaar om toe te voegen aan andere release- en builddefinities.
Zie de documentatie voor taakgroepen voor meer informatie.
Voorlopig verwijderen van releases
Wanneer u een release verwijdert of automatisch wordt verwijderd door een bewaarbeleid, wordt de release verwijderd uit de overzichts- en detaillijsten.
Het wordt echter bewaard met de releasedefinitie voor een periode (meestal 14 dagen) voordat deze definitief wordt verwijderd.
Tijdens deze periode wordt deze weergegeven op het tabblad Verwijderd van de overzichts- en detaillijsten.
U kunt een van deze releases herstellen door het snelmenu te openen en Undelete(afbeelding 54) te kiezen.
Zie de documentatie over verwijderde releases herstellen voor meer informatie.
Behoud releases en builds voor elke omgeving
Het bewaarbeleid voor release voor een releasedefinitie bepaalt de retentieduur voor een release en gekoppelde build.
Standaard wordt een release 60 dagen bewaard. Releases die gedurende die tijd niet zijn geïmplementeerd of gewijzigd, worden automatisch verwijderd.
Het is echter mogelijk dat u meer releases wilt behouden die zijn geïmplementeerd in specifieke omgevingen, zoals uw productieomgeving, of langer bewaren dan de releases die zojuist zijn geïmplementeerd in andere omgevingen, zoals testen, faseren en QA.
U kunt de build ook behouden die is gekoppeld aan een release gedurende dezelfde periode als de release om ervoor te zorgen dat de artefacten beschikbaar zijn als u die release opnieuw moet implementeren (afbeelding 55).
Voor meer details, zie de documentatie van release- en buildretentie.
Verbeteringen aan gekoppelde artefacten
Met twee nieuwe functies kunt u eenvoudiger werken met artefacten en artefactbronnen:
- U kunt meerdere artefactbronnen koppelen aan een releasedefinitie (afbeelding 56). Elk artefact wordt gedownload naar een map op de agent met de naam bron-alias. U kunt nu de bronalias van een gekoppeld artefact bewerken. Wanneer u bijvoorbeeld de naam van de builddefinitie wijzigt, kunt u de bronalias bewerken om de naam van de build-definitie weer te geven.
- Een aantal variabelen van de indeling Build.* (zoals Build.BuildId en Build.BuildNumber) worden weergegeven voor gebruik in taakparameters. Wanneer er meerdere bronnen aan een release zijn gekoppeld, worden deze variabelen nu gevuld met waarden uit de artefactbron die u opgeeft als de primaire bron. Zie de documentatie voor artefactvariabelen voor meer informatie.
Implementatie - Handmatige interventietaak
U kunt nu de uitvoering onderbreken tijdens de implementatie naar een omgeving.
Als u een handmatige interventietaak in een omgeving opneemt, kunt u een implementatie tijdelijk stoppen, handmatige stappen uitvoeren en vervolgens verdere geautomatiseerde stappen hervatten.
U kunt de implementatie ook afwijzen en voorkomen dat verdere stappen worden uitgevoerd na een handmatige interventie (afbeelding 57).
Zie de documentatie voor handmatige interventie voor meer informatie.
SQL Database-implementatie taak scripts
De azure SQL Database-implementatietaak(afbeelding 58) is verbeterd om SQL-scripts uit te voeren op een Azure SQL Database. De scripts kunnen worden opgegeven als een bestand of inline binnen de taak.
Samenvatting van releasedefinitie - dashboardwidget
Maak een releasedefinitie vast aan het dashboard. Dit is een eenvoudige manier om een samenvatting van releases voor die definitie zichtbaar te maken voor al uw team.
Zie Release-informatie toevoegen aan de dashboarddocumentatie voor meer informatie.
Releases op een vooraf bepaald tijdstip naar een omgeving promoveren
Wilt u dat al uw productie-implementaties om middernacht plaatsvinden? U kunt een voorwaarde configureren voor een omgeving die een geslaagde implementatie (of alleen de meest recente) uit een andere omgeving selecteert en deze op het opgegeven tijdstip implementeert (afbeelding 59).
Implementeren op basis van voorwaarden in meerdere omgevingen
Tot de vorige versie kunt u parallelle implementaties (forkdeployments) uitvoeren, maar u kunt geen implementatie starten in een omgeving op basis van de status van meerdere omgevingen (join-implementaties). Je kunt het nu.
Zie de documentatie over parallelle geforkte en gekoppelde implementaties voor meer informatie.
REST API's voor releasebeheer
U kunt de REST API's voor de Release Management-service gebruiken om releasedefinities en releases te maken en veel aspecten van het implementeren van een release te beheren.
Zie de API-referentiedocumentatie voor meer informatie.
De integratie van service hooks
Releasemeldingen verzenden wanneer nieuwe releases worden gemaakt, implementaties worden gestart of voltooid, of wanneer goedkeuringen in behandeling of voltooid zijn. Integreer met hulpprogramma's van derden, zoals Slack, om dergelijke meldingen te ontvangen.
Implementatie naar nationale Azure-clouds
Gebruik de nieuwe omgevingsinstelling in een klassiek Azure-service-eindpunt om een specifieke Azure-cloud te richten, waaronder vooraf gedefinieerde nationale clouds, zoals Azure China-cloud, Azure US Government-cloud en De Duitse Azure-cloud.
Zie de documentatie voor het klassieke Azure-service-eindpunt voor meer informatie.
Testverbeteringen
Belangrijke testverbeteringen zijn toegevoegd in Team Foundation Server 2017.
Opslagschema voor testresultaten bijgewerkt
In deze release migreren we de testresultatenartefacten naar een nieuw compact en efficiënt opslagschema. Omdat testresultaten een van de belangrijkste consumenten van opslagruimte in TFS-databases zijn, verwachten we dat deze functie wordt omgezet in een verminderde opslagvoetafdruk voor TFS-databases. Voor klanten die een upgrade uitvoeren van eerdere versies van TFS, worden de testresultaten tijdens de TFS-upgrade gemigreerd naar het nieuwe schema. Deze upgrade kan leiden tot lange upgradetijden, afhankelijk van de hoeveelheid testresultatengegevens in uw databases. Het is raadzaam om het te configureren en te wachten tot het beleid wordt geactiveerd en de opslag voor testresultaten vermindert, zodat de TFS-upgrade sneller verloopt. Na de installatie van TFS, maar voordat u het TFS-exemplaar bijwerken, kunt u het TFSConfig.exe gebruiken om testresultaten op te schonen. Zie TFSConfig.exe help voor meer informatie. Als u niet de flexibiliteit heeft om de retentie van tests in te stellen of testresultaten op te schonen voordat u upgradet, zorg er dan voor dat u het upgradevenster goed plant. Zie Testresultaten bewaren met Team Foundation Server 2015 voor meer voorbeelden over het configureren van testretentiebeleid.
Verbeteringen in Test Hub
Configuratiebeheer testen in Test Hub
We hebben testconfiguratiebeheer toegevoegd aan de webgebruikersinterface door een nieuw tabblad Configuraties toe te voegen in de Test Hub (afbeelding 61). U kunt nu testconfiguraties maken en beheren en configuratievariabelen testen vanuit de Test-hub.
Zie Configuraties en configuratievariabelen maken voor meer informatie.
Configuraties toewijzen aan testplannen, testsuites en testcases
Het toewijzen van configuraties is zojuist eenvoudiger geworden. U kunt testconfiguraties rechtstreeks vanuit de testhub ( afbeelding 62) toewijzen aan een testplan, testsuite of testcase(s). Klik met de rechtermuisknop op een item, selecteer Configuraties toewijzen aan ..., en u bent aan het werk. U kunt ook filteren op configuraties in de testhub (afbeelding 63).
Zie Configuraties toewijzen aan testplannen en testsuites voor meer informatie.
Testplan- en testsuitekolommen weergeven in het resultatenvenster van de test
We hebben nieuwe kolommen toegevoegd aan het deelvenster Testresultaten waarin het testplan en het testpakket worden weergegeven waarin de testresultaten zijn uitgevoerd. Deze kolommen bieden de nodige context wanneer u de resultaten van uw tests nader onderzoekt (Figuur 64).
Volgorde van tests in Test Hub en op de kaartjes
U kunt nu handmatige tests bestellen vanuit de Test Hub (afbeelding 65), ongeacht het type suite waarin ze zijn opgenomen: statische, op vereiste gebaseerde of op query's gebaseerde suites. U kunt gewoon een of meer tests slepen en neerzetten of het contextmenu gebruiken om de volgorde van tests te wijzigen. Zodra de volgorde is voltooid, kunt u uw tests sorteren op het veld Order en deze vervolgens uitvoeren vanuit de webloper. U kunt de tests ook rechtstreeks bestellen op een gebruikersverhaalkaart op het Kanbanbord (afbeelding 66).
Testsuites bestellen in Test Hub
Testteams kunnen nu de testsuites bestellen op basis van hun behoeften. Vóór deze mogelijkheid werden de suites alleen alfabetisch geordend. Met behulp van de mogelijkheid voor slepen/neerzetten in testhub kunnen suites nu opnieuw worden gerangschikt tussen de peersuites of worden verplaatst naar een andere suite in de hiërarchie (afbeelding 67).
Als onderdeel van het toewijzen van testers, gebruikers zoeken
Als onderdeel van de implementatie van nieuwe besturingselementen voor identiteitskiezers in de verschillende hubs hebben we in Test Hub ook de optie ingeschakeld om te zoeken naar gebruikers bij het toewijzen van testers aan een of meer tests (afbeelding 68). Dit is zeer nuttig in scenario's waarin het aantal teamleden groot is, maar in het contextmenu wordt alleen een beperkte set vermeldingen *(afbeelding 69) weergegeven.
Kies een build om mee te testen
U kunt nu de 'build' kiezen waarmee u wilt testen en vervolgens de webloper starten met behulp van 'Uitvoeren met opties' in testhub (afbeelding 70). Bugs die tijdens het uitvoeren zijn ingediend, worden automatisch gekoppeld aan de geselecteerde build. Daarnaast wordt het testresultaat gepubliceerd op basis van die specifieke build.
Microsoft Test Runner-client starten vanuit Test Hub met gegevensverzamelaars
U kunt nu uw gegevensverzamelaars en build kiezen om te koppelen aan de testuitvoering (afbeelding 71) en de Microsoft Test Runner 2017 (client) op een performante manier starten vanuit testhub, zonder ze te hoeven configureren in de Microsoft Test Manager-client. De Microsoft Test Runner wordt gestart zonder de volledige Microsoft Test Manager-shell te openen en wordt afgesloten na voltooiing van de testuitvoering.
Zie Tests uitvoeren voor desktop-apps voor meer informatie.
Gegevensverzamelaars kiezen en de Exploratory Runner-client starten vanuit testhub
U kunt nu uw gegevensverzamelaars kiezen en de Exploratory Runner 2017 (client) op een performante manier starten vanuit testhub, zonder ze te hoeven configureren in de Microsoft Test Manager-client. Selecteer 'Uitvoeren met opties' vanuit het contextmenu (afbeelding 72) voor een op vereisten gebaseerde suite en kies Verkennende runner en de gegevensverzamelaars die u nodig hebt. De Exploratory-runner wordt opgestart op een manier die vergelijkbaar is met Microsoft Test Runner, zoals hierboven beschreven.
Testresultaten configureren voor tests in verschillende testsuites
We hebben nu de mogelijkheid toegevoegd om het gedrag van testresultaten te configureren voor tests die worden gedeeld in verschillende testsuites onder hetzelfde testplan (afbeelding 73). Als deze optie is geselecteerd en u het resultaat voor een test instelt (markeer deze als Pass/Fail/Blocked van de testhub, webrunner, Microsoft Test Runner of kaarten op het Kanban-bord), wordt dat resultaat doorgegeven aan alle andere tests die aanwezig zijn in verschillende testsuites onder hetzelfde testplan, met dezelfde configuratie. Gebruikers kunnen de optie "Testresultaten configureren" voor een bepaald testplan instellen in het contextmenu van het testplan in de Test hub, of op de testpagina van het Kanban-bord in het dialoogvenster voor de configuratie van algemene instellingen. Deze optie is standaard uitgeschakeld en u moet deze expliciet inschakelen om van kracht te worden.
Fouten van werkitem controleren
U kunt nu een fout controleren door de tests opnieuw uit te voeren die de fout hebben geïdentificeerd (afbeelding 74). U kunt de optie Verifiëren aanroepen vanuit het contextmenu van het bugwerkitem om de relevante testcase in de webtestomgeving te starten. Voer uw validatie uit met behulp van de webrunner en werk het bugwerkitem rechtstreeks in de webrunner bij.
REST API's voor testplan/kloon van testsuite
We hebben REST API's toegevoegd voor het klonen van testplannen en testsuites. U vindt deze onder de sectie Testbeheer op de site Team Services Integreren.
Voortgang van uw Kanban-kaarten testen
U kunt nu rechtstreeks vanuit uw verhalen op het Kanbanbord testcases toevoegen, bekijken en ermee werken. Gebruik de nieuwe menuoptie Test toevoegen om een gekoppelde testcase te maken en bewaak vervolgens de status rechtstreeks vanaf de kaart naarmate dingen vorderen (afbeelding 75).
Met deze nieuwe mogelijkheid kunt u nu de volgende acties rechtstreeks vanuit een kaart op uw bord uitvoeren:
- Voeg tests toe.
- Open testen.
- Een test opnieuw maken door het slepen/neerzetten van het ene naar het andere gebruikersverhaal.
- Kopieer dezelfde test naar een ander gebruikersverhaal met ctrl+slepen/neerzetten (voor scenario's waarin dezelfde testcase meer dan één gebruikersverhaal test).
- Werk de teststatus bij door deze snel op Pass/Fail/etc. te zetten.
- Voer de test uit door deze te starten in de Web Test Runner, waarin u afzonderlijke stappen kunt goed- of afkeuren, bugs rapporteren, enzovoort.
- Bekijk een samenvatting van de samengetelde status die aangeeft hoeveel tests zijn geslaagd en hoeveel er overblijven voor dat verhaal.
Als u geavanceerde testbeheermogelijkheden nodig hebt (zoals testers toewijzen, configuraties, gecentraliseerde parameters toewijzen, testresultaten exporteren, enzovoort), kunt u vervolgens overschakelen naar Test Hub en beginnen met het gebruik van de standaardtestplan/op vereiste gebaseerde suites die automatisch voor u zijn gemaakt. Zie Inlinetests toevoegen, uitvoeren en bijwerken voor meer informatie.
Ga naar een testplan/testpakket vanaf de kaart
U kunt nu eenvoudig doorkruisen naar het onderliggende testplan/testpakket waaronder de tests worden gemaakt, rechtstreeks vanaf een kaart op het Kanban-bord. Als u op deze koppeling ( afbeelding 76) klikt, gaat u naar de testhub, opent u het juiste testplan en selecteert u vervolgens het specifieke pakket waarmee deze inlinetests worden beheerd.
Testpagina in algemene instellingenconfiguratie van Kanban-bord
Gebruik de nieuwe pagina Tests in het dialoogvenster Configuratie van algemene instellingen op kanbanbord om het testplan te bepalen waar de inlinetests worden gemaakt (afbeelding 77). Eerder werden alle tests die op een kaart zijn gemaakt, automatisch toegevoegd aan een nieuw testplan, mits er geen testplannen bestonden die overeenkomen met de gebieds- en iteratiepaden van de kaart. U kunt dit gedrag nu overschrijven door een bestaand testplan van uw keuze te configureren. Alle tests worden toegevoegd aan het geselecteerde testplan. Houd er rekening mee dat deze functie alleen is ingeschakeld als de annotatie Test is ingeschakeld.
Verbeteringen van webtoepassingen
Bijlagen bij teststappen toevoegen tijdens handmatig testen
We hebben de webtestloper verbeterd om u de mogelijkheid te bieden om teststapbijlagen toe te voegen tijdens het handmatig testen (afbeelding 78). Deze stapresultatenbijlagen worden automatisch weergegeven in eventuele fouten die u in de sessie hebt opgeslagen en vervolgens in het deelvenster Testresultaten.
Schermafbeelding, schermopname, ondersteuning voor actielog voor afbeeldingen en systeeminformatie in Web runner (in de Chrome-browser)
U kunt nu schermafbeeldingen maken en aantekeningen maken inline wanneer u Webrunner in Chrome gebruikt (afbeelding 79). U kunt ook schermopnamen op aanvraag vastleggen van niet alleen de web-apps, maar ook uw bureaublad-apps. Deze schermafbeeldingen en schermopnamen worden automatisch toegevoegd aan de huidige Teststap. Naast schermafbeeldingen en schermopnamen kunt u ook op aanvraag actielogboeken van afbeeldingen vastleggen vanuit uw web-apps. U moet het browservenster opgeven waarop u uw acties wilt vastleggen: alle acties in dat venster (bestaande of nieuwe tabbladen die u in dat venster opent) of nieuwe onderliggende browservensters die u start, worden automatisch vastgelegd en gecorreleerd met de teststappen die worden getest in de webloper. Deze schermafbeeldingen, schermopnames en actielogboeken voor afbeeldingen worden vervolgens toegevoegd aan eventuele fouten die u tijdens de uitvoering tegenkomt en zijn gekoppeld aan het huidige testresultaat. Op dezelfde manier worden de systeeminformatiegegevens automatisch vastgelegd en opgenomen als onderdeel van eventuele bugs die u van de webrunner opgeeft. Al deze maken gebruik van de mogelijkheid van de op Chrome gebaseerde Test & Feedback-extensie.
Zie Diagnostische gegevens verzamelen tijdens tests voor meer informatie.
Bugs die zijn opgeslagen als kinderen - Web runner/test & feedback-extensie
Bij het uitvoeren van tests in de Web runner, gestart vanaf een kaart op het bord of vanuit een vereisten-gebaseerde suite in Test Hub, worden alle nieuwe bugs die zijn ingediend, nu automatisch aangemaakt als een subtak van dat gebruikersverhaal. Als u een gebruikersverhaal uit de experimentele testextensie verkent, worden eventueel nieuwe bugs die u aanmaakt ook als subitems van dat gebruikersverhaal gemaakt. Dit nieuwe gedrag maakt eenvoudiger traceerbaarheid mogelijk voor verhalen en bugs. Dit is alleen van toepassing als de instellingen 'Werken met bugs' op de Algemene instellingenconfiguratiepagina zijn ingesteld op 'Bugs verschijnen niet in achterstanden of borden' of 'Bugs verschijnen in de achterstanden en borden met taken'. Voor alle andere instellingen voor de optie 'Werken met bugs' en in bepaalde andere scenario's, zoals het toevoegen aan een bestaande fout waarvoor al een bovenliggende fout is gedefinieerd, wordt in plaats daarvan een gerelateerde koppeling gemaakt.
Bestaande bugs van Web runner bijwerken
Naast het maken van nieuwe bugs van de Web runner, kunt u nu ook een bestaande fout bijwerken (afbeelding 80). Alle diagnostische gegevens die worden verzameld, reproductiestappen en koppelingen voor tracering van de huidige sessie worden automatisch toegevoegd aan de bestaande bug.
Test- en feedbackextensie - verbeteringen
De browsergebaseerde test- en feedbackextensie kan worden geïnstalleerd vanuit Visual Studio Marketplace. Het ondersteunt zowel Visual Studio Team Services als Team Foundation Server (2015 of hoger).
Werkitems verkennen
U kunt nu verkennende tests uitvoeren voor een specifiek werkitem (afbeelding 81). Hiermee kunt u het geselecteerde werkitem koppelen aan uw doorlopende testsessie en de acceptatiecriteria en beschrijving bekijken vanuit de extensie. Het creëert ook einde-tot-einde traceerbaarheid tussen bugs of taken die u op het geselecteerde werkitem meldt. U kunt het werkitem rechtstreeks vanuit een werkitem of vanuit de extensie verkennen:
• Rechtstreeks vanuit een werkitem (afbeelding 81): start een experimentele testsessie voor een specifiek werkitem rechtstreeks vanuit het product met behulp van de optie Verkennend testen in het contextmenu. We hebben toegangspunten toegevoegd voor alle kaarten, rasters en in de testhub.
• Zoek in de extensie (afbeelding 82): zoek een werkitem vanuit de XT-sessie en koppel het vervolgens aan de lopende sessie.
Zie Werkitems verkennen met de extensie Test & Feedback voor meer informatie.
Afbeeldingsactielogboek, schermopnamen en laadgegevens van webpagina's vastleggen met behulp van test & feedback
Actielogboek voor afbeeldingen: De extensie biedt u een nieuwe optie om met slechts één klik automatisch de stappen toe te voegen die naar de bug leiden. Selecteer de optie Actielogboek voor afbeeldingen opnemen (afbeelding 83) om de acties voor de muis, het toetsenbord en de aanraakbewerkingen vast te leggen en voeg de bijbehorende tekst en afbeeldingen rechtstreeks toe aan de fout of taak.
Schermopname als video: U kunt ook schermopnamen op aanvraag vastleggen met behulp van de extensie. Deze schermopnamen kunnen niet alleen worden vastgelegd vanuit de web-apps, maar ook uw desktop-apps. U kunt de extensie zo configureren dat schermopnamen automatisch worden gestopt en gekoppeld aan een fout die wordt ingediend via de optiepagina van de extensie.
Paginalaadgegevens: we hebben een nieuwe mogelijkheid voor het vastleggen van achtergrond toegevoegd aan de extensie: het vastleggen van gegevens over het laden van webpagina's. Net zoals het "beeldactie-logboek" dat uw handelingen vastlegt die u uitvoert bij het verkennen van een webapplicatie in de vorm van achtergrondafbeeldingen, legt de functie "pagina laden" automatisch details vast voor een webpagina om de laadbewerking te voltooien. In plaats van te vertrouwen op subjectieve/waargenomen traagheid van het laden van webpagina's, kunt u nu objectief de traagheid in de bug kwantificeren. Zodra de fout is opgeslagen, wordt naast de tegelweergave ook een gedetailleerd rapport toegevoegd aan de fout, wat de ontwikkelaar kan helpen bij de eerste set onderzoeken.
Testcases maken op basis van actielogboekgegevens van afbeeldingen
Wanneer u testcases maakt tijdens uw verkennende sessie, worden de teststappen met afbeeldingen automatisch voor u ingevuld (afbeelding 84). Gelijktijdige testontwerp en testuitvoering vormen de basis van echte verkennende tests en deze nieuwe mogelijkheid maakt dit een realiteit. U kunt de vastgelegde tekst bewerken, het verwachte resultaat toevoegen, rijen uitschakelen die niet relevant zijn en opslaan voor toekomstige testpassen/uitvoeringen.
Zie Testcases maken op basis van afbeeldingsactielogboekgegevens voor meer informatie.
Inzichten uit verkennende testsessies
U kunt nu de voltooide experimentele testsessies bekijken, hetzij op team- of individueel niveau, voor een bepaalde periode die is gemaakt met behulp van de extensie Test & Feedback. U kunt deze inzichtenpagina openen door te klikken op de koppeling Recente verkennende sessies in de hub Runs binnen de Test Hub-groep in webtoegang. Met deze nieuwe weergave kunt u zinvolle inzichten afleiden, waaronder:
- De overzichtsweergave met een uitsplitsing van de verkende werkitems, de gemaakte werkitems en de sessie-eigenaren, samen met de totale tijd die aan deze sessies is besteed (afbeelding 85).
- De groeperingsweergave kan worden aangepast op basis van verkende werkitems, sessies, sessie-eigenaren of geen van beiden. Voor elke pivot kunt u de lijst met alle werkitems (bugs, taken, testcases) bekijken die zijn gemaakt of de lijst beperken tot een specifiek type werkitem.
- De weergave detailvenster waarin informatie wordt weergegeven op basis van selectie in de groepsweergave. Voor een geselecteerde draaitabelrij (bijvoorbeeld verkende werkitems), kunt u de samenvattingsgegevens bekijken in het detailvenster, zoals het totale aantal sessies, de totale tijd die is besteed aan deze sessies, de sessie-eigenaren die deze hebben verkend en de bugs/taken/testcases die hierop zijn gemaakt, samen met hun status en prioriteit. Voor een geselecteerde rij met werkitems kunt u het werkitemformulier inline weergeven en desgewenst wijzigingen aanbrengen.
Zie Inzichten verkrijgen in uw experimentele testsessies voor meer informatie.
Verkennende testsessies: Niet-onderzochte werkitems weergeven
Naast het bekijken van de details van alle verkende werkitems in de weergave 'recente verkennende sessies', gefilterd op alle/mijn sessies voor een bepaald datumbereik, hebben we nu de mogelijkheid toegevoegd om ook een lijst te zien met alle werkitems die NIET zijn verkend, in dezelfde weergave (afbeelding 86). U begint met het opgeven van een gedeelde query voor werkitems waarin u geïnteresseerd bent en op de pagina sessies ziet u een lijst met alle werkitems uit de query, met een uitsplitsing van zowel verkende als niet-verkende items in de samenvattingssectie. Daarnaast kunt u met behulp van de groep Onontgonnen werkitem via pivot de lijst bekijken van items die nog niet zijn verkend. Dit is zeer handig om te achterhalen hoeveel verhalen nog niet zijn verkend of door een bug-bash zijn gegaan.
Van begin tot eind stroom van feedback voor belanghebbenden
Feedback vragen
Gebruikers met basistoegangsniveau kunnen nu rechtstreeks feedback aanvragen van belanghebbenden voor doorlopende of voltooide functies/verhalen met behulp van de optie Feedback aanvragen in het menu werkitem (afbeelding 87). Hiermee opent u het feedbackformulier Aanvragen, waar u de belanghebbenden kunt kiezen waaruit u feedback wilt geven en eventueel een eenvoudige set instructies kunt opgeven waarin wordt gevraagd naar de gebieden van het product dat u wilt invoeren. Hiermee worden afzonderlijke e-mailberichten verzonden naar de geselecteerde belanghebbenden, samen met de verstrekte instructies, indien van toepassing.
Zie Feedback van belanghebbenden aanvragen met behulp van de extensie Test & Feedback voor meer informatie.
Feedback geven
Belanghebbenden kunnen reageren op de feedbackaanvraag door te klikken op de koppeling Feedback geven in de e-mail die ze hebben ontvangen, waarmee de extensie Test & Feedback (voorheen Exploratory Testing) automatisch wordt geconfigureerd met de geselecteerde feedbackaanvraag (de extensie wordt gevraagd om de extensie te installeren, als deze nog niet is geïnstalleerd). Belanghebbenden kunnen vervolgens de volledige opnamemogelijkheden van de extensie gebruiken om hun bevindingen vast te leggen en hun feedback in te dienen in de vorm van feedbackreactie-/bug-/taakwerkitems. Daarnaast kunnen belanghebbenden naar de pagina Feedbackaanvragen navigeren om alle feedbackaanvragen te bekijken die door hen zijn ontvangen. In de lijst kunnen ze de feedbackaanvraag selecteren waarop ze feedback willen geven, hun "In behandeling zijnde feedbackaanvragen" (afbeelding 88) beheren door ze als voltooid te markeren of door ze te weigeren en kunnen schakelen tussen verschillende typen feedbackaanvragen door op het gewenste keuzerondje (afbeelding 89) te klikken.
Zie Feedback geven met behulp van de extensie Test & Feedback voor meer informatie.
Vrijwillige feedback
Naast de hierboven genoemde gevraagde stroom kunnen belanghebbenden ook de uitbreiding gebruiken om vrijwillige feedback te geven (afbeelding 90). Ze kunnen de extensie openen, de modus Verbonden selecteren op de pagina Verbindingsinstellingen en verbinding maken met het account en Project/Team aan wie ze feedback willen geven. Vervolgens kunnen ze de extensie gebruiken om hun bevindingen vast te leggen en hun feedback in te dienen in de vorm van feedbackreactie-/bug-/taakwerkitems.
Zie Vrijwillig feedback geven met behulp van de extensie Test & Feedback voor meer informatie.
Geautomatiseerde testverbeteringen
Consolelogs en testduur op het tabblad Tests in de build- en release-samenvatting
Testresultatenconsolelogs die zijn vastgelegd in .trx-bestanden worden geëxtraheerd en gepubliceerd als testresultaatbijlagen (afbeelding 91). U hebt een optie om ze te bekijken op het tabblad Tests en hoeft het trx-bestand niet meer te downloaden om logboeken weer te geven.
Trendwidget testen voor builds
We hebben een nieuwe widget Testresultatentrend toegevoegd aan de widgetgalerie (afbeelding 92). Gebruik deze widget om een trenddiagram met testresultaten toe te voegen van maximaal 30 meest recente builds voor een builddefinitie aan het dashboard. Met widgetconfiguratieopties kunt u de grafiek aanpassen om draaitabellen op te nemen, zoals geslaagde testtelling, aantal mislukte tests, totaal aantal tests, percentage geslaagde tests en testduur.
Teststatus met samenvatting van de release-omgeving
Het is een aanbevolen procedure om Release-omgevingen te gebruiken om toepassingen te implementeren en tests erop uit te voeren. Met deze release hebben we het slaging percentage van tests van release-omgevingen geïntegreerd in de omgevingensectie van de pagina Releaseoverzicht (afbeelding 93). Zoals u in de schermopname ziet, kunt u, als een omgeving is mislukt, snel afleiden of de fout te maken heeft met mislukte tests door naar de kolom Tests te kijken. U kunt op het slagingspercentage klikken om naar het tabblad Tests te navigeren en de niet-geslaagde tests voor die omgeving te onderzoeken.
Geautomatiseerde testgeschiedenis voor vertakkingen en release-omgevingen
Het is een veelvoorkomend scenario dat een afzonderlijke test wordt uitgevoerd op meerdere vertakkingen, omgevingen en configuraties. Wanneer een dergelijke test mislukt, is het essentieel om vast te stellen of de fout zich voordoet in ontwikkelingsbranches, zoals de hoofdbranch, of dat storingen ook impact hebben op releasebranches die naar productieomgevingen worden geïmplementeerd. U kunt nu de geschiedenis van een test visualiseren in verschillende vertakkingen die worden getest door naar het tabblad Geschiedenis te kijken op de overzichtspagina met resultaten (afbeelding 94). Op dezelfde manier groepeert u op de omgevingspivot om de geschiedenis van een test te visualiseren in de verschillende Release Omgevingen waarin deze test wordt uitgevoerd.
Traceerbaarheid met continue tests
Gebruikers kunnen nu de kwaliteit van hun vereisten rechtstreeks op hun dashboard bijhouden (afbeelding 95). We hebben al een oplossing voor de kwaliteit van vereisten voor onze geplande testgebruikers en we brengen deze naar onze gebruikers die continue tests volgen. Gebruikers kunnen geautomatiseerde tests rechtstreeks koppelen aan vereisten en vervolgens dashboardwidgets gebruiken om de kwaliteit van de vereisten bij te houden die u wilt bijhouden, de kwaliteitsgegevens op te halen uit Build of Release.
Extern testen : tests distribueren op basis van het aantal machines
We hebben tests vanuit een assembly ingeschakeld om te worden gedistribueerd naar externe machines met behulp van de taak Functionele tests uitvoeren (afbeelding 96). In TFS 2015 kunt u alleen tests distribueren op assemblyniveau. Dit is ingeschakeld met behulp van het selectievakje in de taak, zoals hieronder.
Geautomatiseerd testen voor SCVMM en VMWare
Gebruikers kunnen testmachines dynamisch instellen in de cloud met Azure of on-premises met behulp van SCVMM of VMWare, en deze machines gebruiken om hun tests op een gedistribueerde manier uit te voeren. Gebruikers kunnen een van de inrichtingstaken voor machines gebruiken( Azure, SCVMM of VMWare), gevolgd door de taak Functionele tests uitvoeren om tests uit te voeren.
SonarQube-analyse in Maven- en Gradle-taken
U kunt nu een SonarQube-analyse activeren in de Maven- en Gradle-buildtaak door 'SonarQube-analyse uitvoeren' te controleren en het eindpunt, de naam van het SonarQube-project, de projectsleutel en de versie (afbeelding 97) op te geven.
U krijgt nu ook een koppeling naar het SonarQube-project (afbeelding 98). U kunt een volledige analyse aanvragen om de details van de kwaliteitseisen te bekijken en ervoor kiezen om de build te onderbreken als er niet aan wordt voldaan.
SonarQube Analyse 1 uitvoeren Zie De Gradle-buildtaak ondersteunt nu SonarQube-analyse voor meer informatie.
Marketplace-verbeteringen
Beheerders van projectverzamelingen kunnen nu vanaf een Team Foundation Server naar Visual Studio Marketplace bladeren en gratis extensies installeren in een teamprojectverzameling. De extensies worden automatisch gedownload vanuit Visual Studio Marketplace, geüpload naar de Team Foundation Server en geïnstalleerd in de geselecteerde teamprojectverzameling (afbeelding 99).
Betaalde extensies aanschaffen en installeren
Beheerders van projectverzamelingen kunnen nu vanaf een Team Foundation Server naar Visual Studio Marketplace bladeren, betaalde extensies kopen en installeren in een geselecteerde teamprojectverzameling (afbeelding 100). De beheerder kan betalen voor extensies met een Azure-abonnement en het aantal gebruikers selecteren om deze extensies toe te wijzen. Deze extensies worden automatisch gedownload vanuit Visual Studio Marketplace, geüpload naar de Team Foundation Server en geïnstalleerd in de geselecteerde teamprojectverzameling.
Zie Extensies voor Team Foundation Server-documentatie downloaden voor meer informatie.
Beheerverbeteringen
Windows-verificatie
In eerdere versies moest u beslissen tussen NTLM en Negotiate beveiligingsondersteuningsproviders voor Windows-verificatie bij het configureren van een TFS-implementatie die aan een domein is gekoppeld. In 2017 hebben we deze instelling verwijderd uit de configuratie-ervaring. Als u NTLM-verificatie in 2017 wilt blijven gebruiken, hoeft u geen actie te ondernemen. Als u Kerberos-verificatie hebt gebruikt en dit in 2017 wilt blijven doen, hoeft u geen actie te ondernemen. TFS 2017 configureert nu altijd zowel de negotiate- als NTLM-beveiligingsondersteuningsproviders in die volgorde. Met deze configuratie wordt Kerberos-verificatie waar mogelijk gebruikt, waardoor verbeterde beveiliging wordt geboden. Wanneer Kerberos niet kan worden gebruikt, wordt NTLM-verificatie gebruikt. We hebben uitgebreide tests uitgevoerd om ervoor te zorgen dat er geen invloed zou zijn op bestaande TFS-implementaties met behulp van NTLM-verificatie vanwege deze wijziging.
Een moderne navigatie-ervaring
In deze release schakelen we een nieuwe en verbeterde bovenste navigatiebalk in. Er zijn twee kerndoelen voor de nieuwe navigatie:
- Verhoog de navigatie-efficiëntie over productgebieden door snel toegang te krijgen tot een van de hubs met één klik.
- Breng een moderne visuele esthetica en gebruikerservaring naar het product.
Omdat dit een grote wijziging is voor onze gebruikers en de functie nog steeds wordt ge curseerd, hebben we besloten om de nieuwe navigatie-UX standaard uit te schakelen. Als u ermee wilt spelen, kunt u deze inschakelen door naar het configuratiescherm van Team Foundation Server te gaan en te kiezen voor 'Nieuwe navigatie inschakelen'. Houd er rekening mee dat het voor alle gebruikers op de server is ingeschakeld.
Machtiging voor het wijzigen van de naam van het teamproject
De machtiging die bepalen welke gebruikers de naam van een teamproject kunnen wijzigen, is gewijzigd. Voorheen konden gebruikers met de machtiging Gegevens op projectniveau bewerken voor een teamproject de naam ervan wijzigen. Gebruikers kunnen nu de rechten krijgen of worden onthouden om de naam van een teamproject te wijzigen via de nieuwe machtiging 'Teamproject hernoemen'.
Beheerinstellingen Work Hub
We hebben een nieuwe hub 'Werk' geïntroduceerd op de pagina Beheerinstellingen waarin algemene instellingen (afbeelding 101), iteraties en gebieden op één tabblad worden gecombineerd. Met deze wijziging zien gebruikers duidelijke verschillen tussen instellingen op projectniveau en teaminstellingen. Voor teaminstellingen zien gebruikers alleen gebieden en iteraties die relevant zijn voor hun team. Op projectniveau kunnen beheerders met de instellingenpagina gebieden en iteraties voor het hele project beheren. Daarnaast is voor projectgebiedpaden een nieuwe kolom met de naam Teams toegevoegd, zodat beheerders snel en eenvoudig kunnen zien welke teams een specifiek gebiedspad hebben geselecteerd.
REST API's voor procesconfiguratie
Met deze openbare API kunnen gebruikers de procesconfiguratie van een bepaald project ophalen. De procesconfiguratie bevat de volgende instellingen:
- TypeFields: abstracties van aanpasbare velden die worden gebruikt in de agile-tooling. Het type van het veld Verhaalpunten is bijvoorbeeld 'Inspanning'.
- Backlogdefinities: definieer welke typen werkitems zich op elk van de achterstanden bevinden. Dit is een vaak aangevraagde API van klanten die extensies bouwen. Met deze gegevens kan een extensie weten hoe u processpecifieke velden kunt gebruiken om algemene scenario's mogelijk te maken in de agile-hulpprogramma's (zoals het wijzigen van de activiteit of de inspanning van een werkitem, weten welke werkitems op een bepaald achterstandsniveau zijn opgenomen of om te bepalen of teams worden geïdentificeerd door gebiedspad of een aangepast veld). Raadpleeg Het werkoverzicht voor meer informatie.
Nieuwe beheerderservaring met ad-zoekopdracht op basis van voorvoegsel
Team Foundation Server 2017 introduceert een nieuwe ervaring voor het beheren van groepen en groepslidmaatschap. U kunt zoeken in Active Directory of gebruikers/groepen van lokale machines met behulp van zoekcriteria op basis van voorvoegsel op gebruikers-/groepsnamen. Bijvoorbeeld 'John D' en samaccountname (bijvoorbeeld 'businessdomain\johbdnd') en het visitekaartje van een gebruiker/groep bekijken.
Beveiligingsinstellingen voor gebruikers
U kunt uw persoonlijke toegangstokens en SSH beheren in de nieuwe 'Mijn beveiliging'-ervaring (afbeelding 102). Gebruikers die 'Mijn profiel' gebruikten om SSH te beheren, moeten nu hun openbare SSH-sleutels beheren in de beveiligingsinstellingen van de gebruiker (afbeelding 103).
Geünificeerde configuratiewizard
In eerdere versies kiest u een van meerdere configuratiewizards voor uw TFS-implementatie, afhankelijk van wat u probeerde te doen. De wizards Basis en Volledig kunnen worden gebruikt om een nieuwe implementatie te configureren; de wizard Upgrade kan worden gebruikt voor productie- en preproductie-upgrades; en de wizard Application-Tier Alleen kan worden gebruikt voor verschillende scenario's, waaronder het uitschalen van een bestaande implementatie, het vervangen van een toepassingslaag door nieuwe hardware, enzovoort. In TFS 2017 zijn al deze scenario's geïntegreerd in één wizard Serverconfiguratie, die u begeleidt bij en vervolgens door elk van deze scenario's door u te vragen om eenvoudige keuzes te maken. Daarnaast automatiseren geavanceerde configuraties, zoals preproductie-upgrades en het klonen van bestaande implementaties, nu acties die worden uitgevoerd via tfsconfig.exe, waaronder het wijzigen van server-id's, het opnieuw toepassen van databaseverbindingstekenreeksen en het verwijderen van verwijzingen naar externe afhankelijkheden (die vroeger met tfsconfig.exe PrepareClone waren uitgevoerd).
Nieuw toegangsniveau
Nu de nieuwe Visual Studio Enterprise-groep is toegevoegd aan de beheerportal op toegangsniveau in Team Foundation Servers, kunt u nu snel bepalen wie een Visual Studio Enterprise-abonnement heeft. Zodra deze gebruikers zijn geïdentificeerd, krijgen deze gebruikers zonder extra kosten volledige toegang tot alle TFS-extensies van de eerste partij die zijn geïnstalleerd vanuit Visual Studio Marketplace.
Persoonlijke toegangstokens
U kunt nu verbinding maken met elke Team Foundation-server met behulp van een persoonlijk toegangstoken naast SSH. Dit is handig als u op Linux of Mac ontwikkelt en wilt gebruiken in automatiseringshulpprogramma's en GIT. U kunt uw persoonlijke toegangstokens beheren vanaf de pagina met gebruikersbeveiligingsinstellingen.
Bekende problemen
Dit is een volledige lijst met bekende problemen in deze release.
Er zijn geen Power Tools voor Team Foundation Server 2017
Probleem
Er zijn geen Power Tools uitgebracht voor TFS 2017.
Tijdelijke oplossing:
We zijn verheugd u te laten weten dat de meeste van de vorige Power Tools zijn geïntegreerd in TFS 2017. Helaas is de processjablooneditor niet geïntegreerd, maar u kunt deze downloaden in Visual Studio Marketplace.
Aangepaste besturingselementextensies bijwerken
Probleem
Het schema voor velden in het werkitemformulier is gewijzigd. De documentatie voor aangepaste besturingsextensies is ook gewijzigd.
Tijdelijke oplossing:
Zie de nieuwe documentatie: Een aangepast besturingselement toevoegen aan het werkitemformulier.
Fout bij het importeren van de definitie van het type werkitem
Probleem
Klanten waarop een pagina-extensie voor werkitems is geïnstalleerd, die een definitie van het type werkitem exporteren en die definitie importeren, krijgen de volgende fout: 'Het kenmerk LayoutMode is niet gedeclareerd'.
Tijdelijke oplossing:
Er is een extra LayoutMode-kenmerk op het Element PageContribution telkens wanneer u een definitie van een werkitemtype exporteert. Voordat u de definitie importeert, zoekt u naar de PageContribution-modus en verwijdert u het kenmerk LayoutMode. Verwijder bijvoorbeeld LayoutMode="FirstColumnWide".
Klanten moeten bijwerken naar Git LFS versie 1.3.1 of hoger
Probleem
Git LFS-versies vóór 1.3.1 worden niet ondersteund in toekomstige versies.
Tijdelijke oplossing:
Klanten die Git LFS gebruiken, worden sterk aangeraden om bij te werken naar Git LFS versie 1.3.1 of hoger. Oudere versies van de LFS-client zijn niet compatibel met verificatiewijzigingen in deze versie van TFS. Om klanten tijd te geven om te migreren, hebben we een tijdelijke oplossing voor de korte termijn geïmplementeerd voor RTW. De tijdelijke oplossing wordt verwijderd in Update 1, waarna Git LFS-clients onder 1.3.1 niet meer werken.
NuGet Restore vindt geen pakketten die aanwezig zijn in nuget.org
Probleem
Wanneer u NuGet 3.4.3 of hoger gebruikt, herstelt de NuGet-taak geen pakketten van NuGet.org, tenzij het een expliciete bron is in de NuGet.Config.
Tijdelijke oplossing:
Zorg ervoor dat NuGet.org zich in NuGet.Config bevindt.
<packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
</packageSources>
NuGet-build- en releasetaken worden niet geverifieerd
Probleem
Wanneer u Team Foundation Server/Package Management gebruikt, worden build- en releasetaken van NuGet niet geverifieerd bij feeds als de agent wordt uitgevoerd als een NETWORK SERVICE-gebruiker. Dit is de standaardinstelling wanneer de buildagent wordt uitgevoerd als een service. Dit gebeurt omdat versies van NuGet vóór 3.5 de referenties van het gebruikersaccount gebruiken waarop de buildagent wordt uitgevoerd, niet de referenties die zijn opgegeven door de build-taak.
Tijdelijke oplossing:
Als u NuGet-build-/releasetaken wilt gebruiken met TFS-feeds met behulp van een agent die als netwerkservice wordt uitgevoerd, moet u NuGet 3.5 of hoger gebruiken.
NuGet-build- en releasetaken maken gebruik van de referenties van de agent
Probleem
Versies van NuGet vóór 3.5 gebruiken de referenties van het gebruikersaccount waarop de buildagent wordt uitgevoerd, niet de referenties die zijn opgegeven door de build-taak. Dit kan leiden tot onverwachte toegang of gebrek aan toegang tot feeds.
Tijdelijke oplossing:
Gebruik NuGet 3.5 of hoger op TFS-buildagents.
Externe extensies worden niet automatisch bijgewerkt bij het upgraden van TFS
Probleem
Als u een extensie hebt gedownload van Visual Studio Marketplace, hebt u deze gepubliceerd naar uw TFS 2015-installatie en vervolgens bijgewerkt naar TFS 2017, wordt de extensie niet automatisch bijgewerkt wanneer nieuwe versies van de extensie worden gepubliceerd naar Marketplace.
Tijdelijke oplossing:
Nadat u een upgrade naar TFS 2017 hebt uitgevoerd, verwijdert u de extensies die u in TFS 2015 hebt geïnstalleerd. Installeer vervolgens de nieuwste extensies opnieuw. In TFS 2017 hebben we een functie toegevoegd om automatisch één keer per dag te controleren op bijgewerkte externe extensies en deze te upgraden.
De taak jenkinswachtrijtaak kan niet worden uitgevoerd in releasedefinities
Probleem
Bij het uitvoeren van de Jenkins-wachtrijtaak in een releasedefinitie krijgen klanten een 500 serverfout.
Tijdelijke oplossing:
Momenteel kan de Jenkins Queue Job-taak worden uitgevoerd als onderdeel van TFS-builddefinities, maar niet als onderdeel van release-definities. Deze mogelijkheid wordt toegevoegd in een toekomstige release.
Aangepaste TFS-serverinvoegtoepassingen moeten opnieuw worden opgebouwd op basis van TFS 2017-DLL's
Probleem
Aangepaste TFS-serverinvoegtoepassingen werken niet na een upgrade naar TFS 2017.
Tijdelijke oplossing:
Bouw uw aangepaste serverinvoegtoepassingen opnieuw op voor de TFS 2017-assemblies.
Het serverobjectmodel voor aangepaste TFS-serverinvoegtoepassingen is gewijzigd sinds TFS 2015 RTM
Probleem
Aangepaste TFS-serverinvoegtoepassingen worden niet gecompileerd.
Tijdelijke oplossing:
Herstel de broncode zoals beschreven in dit blogbericht.
Wanneer u beheerdersacties gebruikt, wordt er een uitzondering gegenereerd
Probleem
Wanneer teambeheerders op de pagina Waarschuwingenbeheer de zoekwaarschuwingen voor een specifieke gebruiker gebruiken om abonnementen voor een team te zoeken, krijgen ze mogelijk een uitzondering.
Tijdelijke oplossing:
Optie 1: Klik op het knooppunt Alle waarschuwingen en stel het filter Alle teams-waarschuwingen in om weer te geven. Hiermee worden alle waarschuwingen weergegeven voor alle groepen waartoe de gebruiker toegang heeft.
Optie 2: Als de groep een team is, in plaats van op teamnaam te zoeken, gaat u naar de pagina Waarschuwingenbeheer van dit team om abonnementen te beheren.
Probleem met het gebruik van taken voor het uitvoeren van functionele tests in Team Build/Release Management
Probleem
Het uitvoeren van functionele tests in Team Build/Release Management met behulp van de taken 'Implementatie van Visual Studio Test Agent' en 'Functionele tests uitvoeren' uit de taakcatalogus maakt momenteel gebruik van Agents voor Visual Studio 2015 Update 3 en kan alleen worden gebruikt om tests uit te voeren die zijn gebouwd met Visual Studio 2013 en Visual Studio 2015. Deze taken kunnen niet worden gebruikt voor het uitvoeren van tests die zijn gebouwd met Visual Studio 2017 RC. Raadpleeg dit blogbericht voor meer informatie.
Tijdelijke oplossing:
Er is geen tijdelijke oplossing. Ondersteuning voor het gebruik van Test Agent 2017 en het uitvoeren van tests die zijn gebouwd met Visual Studio 2017, wordt toegevoegd in het tijdsbestek van TFS 2017 Update 1.
Extensies worden niet automatisch bijgewerkt
Probleem
Als u een upgrade uitvoert van een eerdere versie van TFS om TFS 2017 te bereiken en TFS 2017 uitvoert in de verbonden modus, worden uw extensies niet automatisch bijgewerkt zoals ze moeten zijn.
Tijdelijke oplossing:
Er is op dit moment geen tijdelijke oplossing. We hebben het probleem opgelost en het automatische updategedrag wordt opgenomen in TFS 2017 Update 2. Als u om welke reden dan ook niet kunt wachten op Update 2, bereikt u ons via het ondersteuningskanaal en delen we de oplossing eerder.
Als u problemen ondervindt die verhinderen dat u in een productieomgeving (Go-Live) implementeert, neemt u contact op met de productondersteuning van Microsoft. (Alleen Engels) Amerikaanse kantooruren (alleen M-F 6a-6p PST), 1 werkdagantwoord.
Zie door de klant gerapporteerde problemen voor Team Foundation Server 2017.
Suggesties en feedback
We horen graag van u! U kunt een functie voorstellen, een probleem melden en bijhouden via de ontwikkelaarscommunity en advies krijgen over Stack Overflow.