TFS Tutorial: TFS för att automatisera bygga, testa och driftsättning för.NET-projekt

använda Microsoft TFS 2015 Update-3 för. NET (Bygg, testa och distribuera): TFS Tutorial

TFS används mer allmänt för. net utveckling med hjälp av Visual Studio. Net IDE. Med TFS 2015 Update 3 kan man ansluta till någon Team Foundation Server Git repo, med en SSH-nyckel.,

Team Foundation Server (TFS) är en ALM-produkt från Microsoft som ger kapacitet för en end-to-end utveckling och testning med Arbetsobjekthantering, projektplanering (vattenfall eller Scrum), versionskontroll, Bygg / släpp (distribuera) och testfunktioner.

OBS! Denna TFS-handledning har många bilder så att den kan laddas ordentligt.,

Läs också => TFS för JAVA-projekt med Eclipse i DevOps

introduktion

TFS är skräddarsydd för Microsoft Visual Studio och Eclipse på alla plattformar, men det kan också användas som en back-end till flera IDEs (integrerade utvecklingsmiljöer).

Vi kommer nu att ta en titt på hur Team Foundation Server (TFS) kommer att användas för att bygga, testa och distribuera.Net webbapplikationer som traditionellt är styrkan i verktyget.

förutsättning:

  • Microsoft TFS 2015 Update 3
  • Microsoft Visual Studio .,NET 2015 (30-dagars testversion)
  • SonarQube 6.4 eller högre
  • IIS webbserver aktiverad. Eftersom jag använder en Windows 7 box kan du kontrollera denna handledning om hur du aktiverar IIS 7. Så här installerar du Internet Information Services (IIS 7) på Windows 7 Ultimate
  • Det finns flera YouTube-videor om hur du aktiverar IIS på Windows 2008 / 2012 / 2016. – herr talman!,

vanligtvis för att utföra de steg som nämns i handledningen behöver du en Byggserver, där byggnader kommer att utföras, och Driftsättningsmaskiner eller miljöer där applikationer kommer att distribueras till IIS, med agenter installerade och körs. Se min tidigare handledning för att veta hur man installerar agenter.

konfigurera en C # – applikation

förutsatt att arbetsobjekt skapas i TFS och tilldelas utvecklarens att fungera på samma sätt. Jag har alltid märkt att spårbarhet är mycket viktigt när det gäller att spåra allt arbete över programvarans livscykel.,

innan du lägger till ett.NET-program i TFS source control repository, se till om det finns ett samlings-och teamprojekt eller inte.

en samling skapas av TFS-administratören. Den består av en grupp teamprojekt i någon serviceorganisation, där projekt för flera kunder utförs. Du kan skapa individuella samlingar för varje kundprojekt i TFS.

När en samling har skapats kan du skapa flera lagprojekt inom den. Ett enda lagprojekt består av alla arbetsobjekt, källkod, test artefakter, mätvärden för rapporter etc.,, Team project kan skapas med hjälp av olika inbyggda processmallar som Scrum, Agile, CMMI etc.

  • mer om att skapa samlingar kan hittas @ Manage team project collections in Team Foundation Server
  • här kommer jag att använda Standardsamlingen som skapas när TFS är installerat
  • för att skapa lagprojekt inom en samling, följ stegen som visas nedan.

Starta TFS webbgränssnitt med webbadressenhttp://<ServerName>:port/tfs och du kan se projektet som skapats.,

klicka på projektet och du kommer att gå vidare till Team Dashboard

(Obs: klicka på en bild för förstorad vy)

nu har vi en samling och ett lagprojekt skapat. Låt oss starta Visual Studio.NET och skapa en ny C # webbapplikation och dela projektet till TFS source control repository. Detta är det första steget mot att etablera kontinuerlig Integration (ci) praxis.

1) Starta Visual Studio.NET och ställ in TFS som standardkällkontrollförvaret. Go to Tools =>Options => källkontroll. Klicka sedan på OK.,

2) gå till View => Team Explorer och anslut till TFS server med ikonen

3) Skapa en C# ASP.NET Web project

4) Eftersom vi skapar en webbapplikation väljer du mallen webbformulär

klicka på OK för att skapa projektet.

5) det skapade projektet kan ses i Solution Explorer. .Net använder begreppet.sln fil eller lösning för att innehålla alla projekt. När du öppnar lösningen kommer alla tillhörande projekt också att öppnas. Vi måste lägga till lösningen till TFS source control repository

6)ändra filens standard.,aspx som visas, spara den och lägg sedan till hela lösningen i TFS source control repository

Välj designvyn och du kommer att kunna se hela sidan

7)Lägg till lösningen till TFS source control. Högerklicka på lösningen och välj ”Lägg till lösning till källkontroll”

8) Välj det lagprojekt som skapats tidigare och klicka sedan på OK

9) lösningen är ännu inte incheckad till TFS. I Team Explorer klickar du på source control explorer och du kan se lösningen som ska kontrolleras.

10) Incheckningsändringar., Gå till Team Explorer => väntande ändringar

Ange en kommentar och dra-släpp ett arbetsobjekt för att säkerställa spårbarhet. Klicka på Incheckningsknappen.

11) för att testa webbplatsen som körs lokalt, klicka på Firefox-ikonen i Visual Studio.NET. kom ihåg att den ännu inte är utplacerad till IIS på någon särskild miljö.

skapa Byggdefinition med kodanalys

en byggdefinition består av en serie uppgifter som utförs under en automatiserad byggprocess., Exempel på uppgifterna kan bestå av att köra en Visual Studio Build, MS Build, exekvera PowerShell eller Shell skript etc.

1) för att skapa en Byggdefinition, logga in på TFS webbgränssnitt och gå till fliken bygger. Klicka på + för att skapa en byggdefinition. Börja med Tom definition och klicka sedan på Nästa.,

Välj Teamprojektet och klicka på Skapa

klicka på Redigera, som finns bredvid den tomma definitionen

spara byggdefinitionen som något som ”huvudbyggnad”

eftersom Sonarqube kommer att användas för kodanalys, lägg därför till 2 Sonarstegen ”SonarQube-skanner för MSBuild-Begin Analysis” och ”SonarQube – skannern för MSBuild-End Analysis” – uppgifter.

Lägg till begin Analysis step innan någon MS Build eller Visual Studio Build. Detta steg Hämtar detaljer från Sonarqube-servern för att konfigurera analysen.

Lägg till Slutanalyssteg senare.,

de steg som läggs till kommer att se ut som följande med MS Build steg däremellan.

börja definiera detaljerna för Sonarqube-servern. Definiera Endpoint där Sonarqube-servern och autentiseringsinformationen läggs till. Klicka på ”Hantera” för att lägga till Sonarqube server detaljer.

klicka på’New Service Endpoint => Generic ’

gå nu tillbaka till Huvudbyggdefinitionsskärmen och välj slutpunkten som just skapades.

slutförd konfiguration för Begin analysis, ser ut som visas nedan

Välj lösningen., I Advanced => anger ytterligare inställningar följande och sparar Byggdefinitionen

/d:ekolod.scm.aktiverad=true / d: ekolod.scm.provider=tfvc / d: ekolod.tfvc.användarnamn=niranjan / d: ekolod.tfvc.lösenord.secured = <lösenord>

SonarQube – End analys. Avsluta analysen och ladda sedan upp resultaten till SonarQube-projektet.

Lägg till ett steg för att publicera artefakter på servern. Artefakterna lagras i en droppmapp i servern och kommer att användas under driftsättningen.,

2) Installera agenten på Bygg-och Driftsättningsmaskinen. Du kan hänvisa till min tidigare handledning för att veta hur man installerar agenten. Nu förutsatt att agenten är installerad, se om agenten körs eller inte.

3) Se till att SonarQube SCM TFVC plugin hämtas härifrån. och kopieras till katalogen SonarQube installation \ extensions \ plugins. Denna plugin säkerställer att källkoden tas från TFS source control repository och görs tillgänglig för SonarQube för kodanalys.,

4) När insticksprogrammet har hämtats och kopierats startar du sonarservern

5) Starta en byggnad för att kontrollera om stegen fungerar bra. Öppna Byggdefinitionen och klicka på ”kö Build”

Bygg framgångsrikt. Alla steg gick bra.

klicka på Build-numret, i det här fallet är det Build 217 och gå till Artifacts-fliken för att titta på drop-mappen som skapats på servernivå.

Obs! i nästa avsnitt visar utgivningsprocessen hur någon av ändringarna kan återspeglas under distributionsprocessen., För detta se till att projektet artefakter kopieras genom KOPIERINGSSTEGET i byggdefinitionen efter kompileringssteget eller manuellt kopiera katalogen Project artifact till C:\inetpub\wwwroot katalog. Detta måste bara göras en gång.

skapa Release för distribution

i föregående avsnitt såg vi om Build, följt av kodanalys med SonarQube. Vi kommer nu att skapa en Release för att distribuera artefakterna från mappen ”drop” till IIS.

med skapandet av Release är hela kontinuerlig Integration och kontinuerlig leverans automatiserad utan manuell ingrepp.,

gå till Release hub och skapa en Release Definition.

börja med Tom definition och klicka på OK.

spara Utgivningsdefinitionen och byt namn på Standardmiljön till QA. Baserat på projekten, ytterligare miljöer som Staging Pre-Prod etc. kan också läggas till och distribution skulle automatiseras till hela miljöer en efter den andra.

länka Byggdefinitionen till att släppa definitionen så som distributionen är automatiserad. Klicka på ”länk till en byggdefinition”. Välj den byggdefinition som skapats tidigare.,

klicka på länk

Aktivera Driftsättningsförhållandet för att initiera driftsättningen omedelbart efter lanseringen

Aktivera också utlösaren för driftsättning efter att byggnaden har lyckats. I Utgivningsdefinitionen, gå till fliken Trigger och aktivera ”kontinuerlig distribution”, välj byggdefinitionen.

Spara senare Utgivningsdefinitionen.

tillbaka i miljöer fliken release definition lägga till uppgifter för att distribuera artefakter till IIS-servern.

Lägg till en uppgift att kopiera filer från mappen ”drop” som skapades under byggprocessen till IIS wwwrootdirectory.,

källmapp-bläddra och välj webapplication1-projektet i rullgardinsmappen

målmappen ska vara Inetpub \ wwwroot-katalogen – C:\inetpub\wwwroot\WebApplication1

kör Release for Deployment

I release hub skapar du en release för att starta distributionen

välj den senaste stabila utgåvan och klicka på Create för att starta distributionen.

distributionen är framgångsrik för QA-miljö

kör inetmgr som är IIS-hanteraren, där du kan hantera alla webbplatser / program som är installerade på iis. Bläddra till webbapplikationen distribuerad.,

för att avsluta när du påbörjar bygget kommer distributionen också att slutföras till alla definierade miljöer, eftersom utgåvan är kopplad till byggdefinitionen.

slutsats

i den här TFS-handledningen har vi nu sett hur Microsoft Alm-plattformen kan användas för att automatisera Build, Test och Deployment för.NET-applikationer. TFS spelar en viktig roll här.

i dagens värld är automatisering nyckeln till framgångsrik och snabbare leverans för att ligga steget före.

Senast uppdaterad: 18 januari 2021 6: 33 am

Share

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *