Övning – Skicka en ändring genom pipelinen
I den här delen ser du att distributionsplatserna fungerar. På webbplatsens startsida ändrar du bakgrundsfärgen och texten på hero-banderollen. Sedan push-överför du ändringarna till GitHub, tittar på pipelinekörningen och verifierar ändringarna.
Om du vill öva vidare på processen återställer du sedan ändringarna och ser pipelinekörningen som ett sätt att rulla framåt.
Ändra texten på hero-banderollen
Här ändrar du texten på hero-banderollen. Senare visas ändringen när du distribuerar till App Service.
Öppna Index.cshtml i katalogen Tailspin.SpaceGame.Web/Views/Home i Visual Studio Code.
Leta efter den här texten längst upp på sidan:
<p>An example site for learning</p>
Dricks
Visual Studio Code är ett sätt att söka efter text i filer. Om du vill komma åt sökfönstret väljer du förstoringsglasikonen i sidofönstret.
Ersätt exempeltexten med följande text och spara sedan filen.
<p>Welcome to the official Space Game site!</p>
Ändra bakgrundsfärgen
Här ändrar du bakgrundsfärgen för hero-banderollen från grå till grön.
Öppna site.scss i katalogen Tailspin.SpaceGame.Web/wwwroot/css i Visual Studio Code.
Viktigt!
Öppna site.scss, inte site.css. Byggfasen körs
node-sass
för att konvertera site.scss (en Sass-fil) till site.css (en STANDARD CSS-fil).Leta upp följande kod längst upp i filen:
.intro { height: 350px; background-color: #666; background-image: url('/images/space-background.svg'); background-size: 1440px; background-position: center top; background-repeat: no-repeat; background-attachment: fixed;
I koden ersätter du den markerade texten enligt följande exempel. Spara sedan filen.
.intro { height: 350px; background-color: green; background-image: url('/images/space-background.svg'); background-size: 1440px; background-position: center top; background-repeat: no-repeat; background-attachment: fixed;
Skicka ändringen via pipelinen
Normalt skulle du skapa och köra webbplatsen lokalt för att verifiera ändringen. Du kan också köra eventuella associerade enhetstester för att kontrollera att ändringen inte bryter mot befintliga funktioner.
I korthet checkar du in ändringarna i din gren, push-överför grenen till GitHub och tittar på pipelinekörningen.
Lägg till Index.cshtml och site.scss i indexet, checka in ändringarna och push-överför sedan ändringarna till GitHub.
git add Tailspin.SpaceGame.Web/Views/Home/Index.cshtml Tailspin.SpaceGame.Web/wwwroot/css/site.scss git commit -m "Change text and colors on the home page" git push origin blue-green
I Azure Pipelines spårar du bygget genom varje steg.
Gå till den URL som motsvarar produktionsplatsen för mellanlagringsmiljön. Det här facket är standardplatsen som du konfigurerade när du konfigurerade pipelinen tidigare.
Du ser att den distribuerade webbplatsen visar färg- och textändringarna.
Gå till den URL som motsvarar växlingsplatsen för mellanlagringsmiljön. URL:en innehåller "-swap.azurewebsites.net" i namnet.
Du ser den tidigare versionen av webbplatsen, utan färg- och textändringar.
Du ser inga ändringar eftersom du har växlat produktionsplatsen och växlingsfacket. Här distribuerar du med andra ord alltid till växlingsfacket och sedan byter du ut produktionsplatsen och växlingsplatsen. Växlingsprocessen säkerställer att produktionsplatsen pekar på den nyare distributionen.
Återställa ändringen
Anta att du har distribuerat en ändring som du vill återställa. Nu kan du återställa ändringen genom att byta ut produktionsplatsen och byta plats igen. Du kan till exempel växla facken manuellt via Azure-portalen. I stället för att återställa ändringarna kan du rulla framåt genom att push-överföra en annan ändring via pipelinen.
Det är vad du gör här. Du återställer de senaste kodändringarna och skickar en ny ändring via pipelinen. Du gör det här med kommandot git revert
.
I Git tar du sällan bort incheckningar från en fils historik. Till skillnad från åtgärden "ångra" i en textredigerare git revert
skapar kommandot en ny incheckning som i princip är motsatsen till den angivna uppsättningen incheckningar. Om du vill se incheckningarna kör git log
du först kommandot för att spåra din incheckningshistorik under återställningsprocessen.
I terminalen kör du följande
git log
kommando för att visa din incheckningshistorik.git --no-pager log --oneline
Dina utdata liknar följande kodexempel. I dina utdata visas ytterligare incheckningar och olika inchecknings-ID:t.
d6130b0 (HEAD -> blue-green, origin/blue-green) Change text and colors on the home page ce56955 Swap deployment slots 0d6a123 Trigger the pipeline
I utdata spårar du incheckningshistoriken. Den senaste incheckningen är överst.
Kör följande
git revert
kommando för att återställa med en incheckning.git revert --no-edit HEAD
Tänk på HEAD som det aktuella tillståndet för din gren. HEAD refererar till den senaste incheckningen. Det här kommandot anger att endast head- eller senaste incheckningen ska återställas.
Kör
git log
igen för att se din uppdaterade incheckningshistorik.git --no-pager log --oneline
Överst i dina utdata visas ytterligare en incheckning som återställer den tidigare incheckningen. Här är ett exempel:
e58896a (HEAD -> blue-green) Revert "Change text and colors on the home page" d6130b0 (origin/blue-green) Change text and colors on the home page ce56955 Swap deployment slots 0d6a123 Trigger the pipeline
Push-överför den återställda ändringen via pipelinen
Här push-överför du den återställda ändringen via pipelinen och ser resultatet.
Kör följande
git push
kommando för att ladda upp grenenblue-green
till din GitHub-lagringsplats.git push origin blue-green
I Azure Pipelines går du till versionen. Spåra bygget när det körs.
Gå till url:erna som motsvarar växlingsplatsen och produktionsplatsen för mellanlagringsmiljön.
Produktionsfacket pekar nu på den återställda ändringen, som är den ursprungliga webbplatsen.
Växlingsfacket pekar nu på den tidigare ändringen.
Bra jobbat! Teamet har nu ett sätt att automatisera versionerna. De kan få nya funktioner till sina användare utan att orsaka avbrott.
Teammöte
Teamet samlas för att demonstrera pipelinen. Den här gången driver Tim en förändring genom pipelinen medan alla tittar. Men alla är inte övertygade.
Andy: Det är bra att se distributionsfack på jobbet. Men jag fattar inte. Hur drar vi nytta av distributioner utan avbrott här? Mellanlagring är bara för vårt team och vår ledning.
Tim: Vi kommer faktiskt inte att se mycket nytta just nu. Tänk dig dock när vi tillämpar blågröna distributioner på en produktionsfas . Vi har fortfarande manuellt godkännande från hanteringen innan vi uppgraderar till Produktion. Men när vi släpper nya funktioner kommer växlingsprocessen att göra distributionen nästan omedelbar. Det blir sömlöst för våra användare.
Andy: OK, jag tror att jag förstår nu. Jag gillar den här förbättringen. Systemet med distributionsfack var enkelt att konfigurera och det kommer att gynna våra användare. Alla vinner.
Amita: På tal om förbättringar, varför går vi inte tillbaka till vår värdeströmsmappningsövning som vi gjorde för några veckor sedan? Jag slår vad om att vi kommer att se framsteg i hur snabbt vi kan släppa nya funktioner.
Mara: Bra, låt oss sätta det på dagordningen för vårt nästa teammöte.