Alla professionella sajtbyggare versionshanterar sin kod. Det innebär att all kod finns lagrad i ett så kallat repository. Fördelarna är många. Exempelvis kan vi se historik på varje enskild fil och kodrad, vi kan se vem som har skrivit vad, när och hur. Vi kan bygga nya funktioner i separata instanser som sedan kan läggas in när de är klara. Det gör det också väldigt enkelt för oss att sätta upp sajten i olika miljöer, såväl staging/utvecklingsserver och på våra lokala maskiner.
Fördelar med att inte själv uppdatera sin sajt och eventuella tillägg:
- Vår versionshantering hamnar inte i osynk. Osynk gör att nästa insats från vår sida kommer att ta längre tid då vi behöver replikera de ändringar som gjorts, se till att allt fungerar och slå samman detta med repositoryt.
- Vi har möjlighet att testa uppdateringarna i flera miljöer som inte är live/”produktionssajt”. Det är nämligen inte ovanligt att saker kan gå sönder. Speciellt tillägg kan vara klurigt då dessa utvecklas helt separat och oftast av andra personer än de som utvecklar plattformen. Det kan även röra sig om att utfasning av vissa funktioner gjorts vilket gör att vi kan behöva koda om sättet något fungerar eller presenteras på.
- När vi säkerställt att sajten och alla funktioner fungerar kan vi enkelt bokföra ändringarna och skjuta upp uppdateringen live på bara några sekunder
Nackdelar med att själv uppdatera sin sajt och eventuella tillägg:
- Dyrare om vi behöver hjälpa till med något
- Sajten kan gå sönder i produktionsmiljö
För regelbundna uppdateringar föreslås ett samarbets-/förvaltningsavtal där man kan uppdatera vid givna tidpunkter/år. Exempelvis efter major release cycle på plattformen.
Fotnot: detta gäller även för nyinstallation av funktionalitet. I vissa fall med WordPress som plattform har vi varit med om installation av tillägg som man tror är bra och gör nytta med inte insett att tidigare tillägg har jobbat ihop med custom-kod för bättre nytta.
Exempel på projekt där saker gått sönder:
Sajt uppdaterades från 5.7 till 6.0 vilket innehöll en del breaking changes vilket gjorde att sajterna spottade ut felmeddelanden. Vilket krävdes att vi skrev om viss funktionalitet för att lösa problemet.
- Kund hade låtit bli att uppdatera/underhålla sajten under många år samt ignorerat mail från Loopia (som hostade sajten) om att kunderna måste uppgradera PHP-version, annars kommer de till slut tvingas upp.
- Loopia har som policy att bara stödja de tre senaste PHP-versionerna (major) då äldre versioner än så har nått EOL. Sajten var byggd långt innan och fungerade bara upp till PHP 7.4.
- Sajten innehöll bärande tillägg och tema (templates) som byggdes i en tid då det inte krävdes licens för uppdateringar. När detta sedan ändrades saknades så aktiv licens och tillägg/tema kunde därför inte heller hämta in information om att det fanns uppdateringar. Och detta upptäcktes inte under 5-7 års tid = otroligt många uppdateringar.
- När Loopia sedan tvingade upp lägsta PHP-versionen från 7.4 till 8.0 så var det så många saker som blivit föråldrade att sidan helt slutade att fungera (= helt vit sida utan innehåll).
- Lösningen tog extra lång tid eftersom vi fick ställa ner mjukvaruversioner i en testmiljö för att se vad som gått fel, därefter hitta på en rimlig lösning (vilket blev att ta bort tillägg och tema och bygga om sajten med nytt tema) och sedan uppgradera systemversioner successivt.
