Varför det är bra med rätt uppsättning för stage-sajt, live-sajt, versionshantering och deployflöde
Man kan absolut ha en sajt på en webbserver och jobba direkt mot den. Men vi rekommenderar starkt att ha saker och ting rätt uppsatta, särskilt om det är en större och viktig sajt som kommer att uppdateras och utvecklas kontinuerligt.
Låt oss berätta hur vi föredrar att ha det uppsatt och kanske framförallt varför. Vi ska försöka hålla det hela på en förståelig och inte alltför teknisk eller komplicerad nivå.
Vad är en stage-sajt och varför behövs det?
När man ska utveckla en helt ny sajt (som antingen är helt ny eller ska ersätta en befintlig) gör man detta på en utvecklingssajt, eller stage-sajt som vi brukar säga (det kan också kallas test eller testmiljö). Det ska vara samma tekniska miljö och konfiguration som sedan ska gälla när sajten går live - och det bästa är att sätta upp det på samma server redan från början. En stage-sajt bör vara lösenskyddad för att inte indexeras av sökmotorer, och för att ingen obehörig ska råka komma åt den.
När den färdiga sajten ska läggas live installeras en kopia av stagesajten och domänen pekas om - och vips! så är sajten live och det finns två versioner av den, en stage sajt och en live sajt.
Nu kanske någon läsare tänker att det verkar onödigt med två versioner av sajten installerade på samma webbserver- men det är faktiskt väldigt effektivt om sajten ska leva länge, hållas uppdaterad och vidareutvecklas. Uppdateringar av bakomliggande CMS, plugins och moduler eller av kopplingar till externa system kan göras och testas på stagesajten utan att störa eller påverka livesajten - och när allt ser bra ut pushas ändringarna helt enkelt till livesajten. Det innebär att varken administratörer eller besökare märker av det hela - det blir inga avbrott eller nedtider som ställer till det.
Repot håller koll
Repot, eller repository som det egentligen heter, är den huvudsakliga komponenten som spårar ändringar i ett webbprojekt. Detta är ett system för att hålla koll på vad som ändrats, när och av vem och gör det möjligt för flera webbutvecklare att jobba med samma kod.
Det gör det till lättare att lösa fel och åtgärda andra misstag som kan uppstå under utveckling, alla teammedlemmar kan hålla sig uppdaterade om vad som är klart och vad som fortfarande behöver göras, och man kan enkelt återgå till en tidigare fas om något behöver återställas.
GitLab - vår bästa vän
Det finns såklart olika versionskontrollsystem (VCS) och vi brukar jobba med Git hostat på GitLab. GitLab är väldigt likt GitHub, något ni antagligen hört talas om.
Här är det viktigt att skilja på GitLab/GitHub, och Git. Git är en lokal programvara som gör det möjligt för utvecklare att spara ögonblicksbilder av sina projekt över tid. GitHub och GitLab är webbaserade plattformar som kan hålla arkiv av kod i molnbaserad lagring så att flera utvecklare kan arbeta på ett samma projekt och se varandras redigeringar i realtid. Vilket man väljer är en smaksak, GitLab är mer open source och GitHub drivs numera av Microsoft.
Här ska använda commits på rätt sätt - och segmentera förändringar i mindre delar när man väsentligt förändrar koden och är klar med något som fungerar. Då kan man återgå och titta på förändringarna över tid om något går fel eller om det inte fungerar lika bra som förut. Om man gör flera olika förändringar bör de separeras till olika commits.
Git använder sig av något som kallas branches (eller grenar) för att spåra förändringar. Huvudbranchen brukar kallas för main och det är det huvudsakliga projektet. Alla andra branches deriverar sin sanning från main. Säg att du behöver lägga till en funktion (eller feature) till din kod. Istället för att börja ändra i main-branchen skapar du en ny branch från main för att bevara mains integritet. På den nya branchen kan du commita dina förändringar, utan att påverka main direkt. När du är nöjd och allt fungerar slår du ihop dem (merge) och låter main ta in den nya branchen. Och allt är bra. Så i princip så praktiserar vi vad som kallas Git Flow.
Deployflöde är kittet mellan stage och live
För att kunna göra detta smidigt behövs ett bra deployflöde. Deploy betyder driftsätta - och driftsätta i vår webbvärld betyder att lägga saker live på internet. Stagesajten och live-sajten ska ha samma kodbas - och när man gjort uppdateringar och förändringar på stagesajten kan de med ett bra deployflöde enkelt pushas ut på livesajten. Projektledare brukar lite förenklat säga att det bara är att "trycka på knappen", men det stämmer delvis.
Men vad gör deployflödet?
Kortfattat fungerar det som så att när deployflödet kör så hämtar det hem den senaste versionen av koden från en branch i projektets repo på GitLab. Vi har olika branches beroende på om koden skall till stage (develop) eller live (main). Vid behov så kommer deployflödet att gå genom olika faser där det installerar koden och bygger upp alla filer som behövs för temat. När allt detta är klart så synkas resultatet med de filerna som ligger på servern. Efter detta kan man köra lite after care på servern som att tömma cachen och uppdatera databasen.
OK, men varför behövs det?
De som var med i begynnelsen kommer kanske ihåg hur man skickade upp filer med FTP när man uppdaterade koden till sin hemsida. Här kunde alla möjliga problem uppstå som att man missade att få med viktiga filer (för det fick man komma ihåg manuellt), eller så hamnade filerna på fel ställe eller skrev över nåt de inte skulle. Det var lätt att det blev kaos och dessutom tog det lång tid och FTP kom med säkerhetsrisker.
Med ett deployflöde så kommer filerna alltid att hamna på rätt plats på ett säkert och snabbt sätt. Plus att man kan utföra arbeten utöver att flytta filerna och de kommer alltid att köras. Inget behöver hållas i en utvecklares huvud eller på någon post-it-lapp.
Juste - kan jag också få ett deployflöde uppsatt?
I regel ja! De flesta webbhotell erbjuder de funktioner som krävs. Viktigast är så kallad SSH-access och möjlighet att sätta upp egna webbsajter, domäner och databaser på hotellet.
Behöver vi allt det här?
Det enkla svaret är att man ganska snabbt tjänar in tiden det tar att sätta upp en bra utvecklingsmiljö och arbetsflöden - både vid uppdateringar, eventuella felsökningar och framförallt vid vidareutvecklingar eller ändringar.
Lite beroende på typ av webbsajt, webbhotell och andra faktorer kan det ta mellan 4-8 h att få allt på plats - men det sparar man snabbt in. Sajten blir enklare att jobba med, flera utvecklare kan jobba på samma projekt och allt blir tryggt och säkert.
© 040 2024