Lanseringsprocessen
Av murtlest den 3 June 2009
För några veckor sedan berättade vi lite om hur Pusha är uppbyggt under ytan. I det här nya inlägget förklarar vi hur processen ser ut från det att vi skriver ny kod tills dess att de nya funktionerna lanseras på sajten.
Eftersom vi är flera personer som arbetar med Pushas kod och för att inte riskera att förstöra koden så använder vi ett versionshanteringssystem som heter Subversion. Det fungerar så att koden lagras på en central server i ett s.k. “repository”, så att vi utvecklare kan ladda ned koden var vi än befinner oss. Innan man börjar arbeta så hämtar man hem de senaste ändringarna och när man skrivit klart en bit kod så “checkar” man in den så att resten av utvecklingsteamet kan ta del av förändringarna. Subversion kontrollerar även att det inte blir någon konflikt om flera personer arbetar med exakt samma bit kod samtidigt.
För att minska risken att det kommer ut buggar på den officiella versionen testar vi koden i tre olika instanser innan vi lanserar den. Först lokalt på varje utvecklares dator, sedan i en alpha-version på en testserver och avslutningsvis på en beta-version, som även ni användare har tillgång till.
För att slippa att manuellt knappa in obskyra linux-kommandon varje gång vi vill testa något nytt eller lansera ny kod har vi automatiserat så mycket av den här lanseringsprocessen som möjligt.
Till att börja med så har vi med hjälp av subversion-hooks gjort så att alpha-versionen automatiskt checkas ut varje gång vi checkar in ny kod. Det innebär att om vi har testat kod lokalt och sedan checkar in den, så kan vi direkt provköra det på testservern utan att behöva göra någonting extra.
När vi känner oss nöjda med alpha-versionen och vill ta steget till beta så har vi skapat ett webbaserat gränssnitt där vi helt enkelt bara behöver trycka på en knapp så synkas allt som finns i alpha-versionen över till beta-versionen, som ligger på vår riktiga server.
När vi funderade över hur vi skulle lansera nya versioner av Pusha kom vi fram till två krav på lanseringsprocessen; dels ska det gå fort, vi vill inte att webbsidan ligger nere i onödan, och dels ska det gå att ångra sig, trots många tester så händer det såklart att det finns buggar som råkar komma ut och då vill man snabbt kunna backa.
Båda dessa krav har vi lyckats lösa. Vi kan enkelt lansera nya versioner utan en enda millisekunds nedtid genom vårt webbinterface och backa till varfri version med ett enkelt knapptryck. Tekniskt sett så löste vi detta genom att låta webbservern peka på en symlänk (eller “genväg” för Windows-användare). Denna symlänk pekar i sin tur på en versionskatalog som är döpt efter versionsnummret. När vi lanserar en ny version så kopieras allt som finns i beta-katalogen till en ny versionskatalog (med ett högre nummer). Sedan pekas symlänken om till den nya katalogen (egentligen skapas en temporär symlänk som flyttas till den gamla för att slippa en millisekunds nedtid, mer om det här).
Ett problem som uppstår när man har flera instanser av testning är att vissa saker i koden måste vara olika för de olika instanserna. T.ex. vilken katalog användarnas bilder ska laddas upp i, vilken databas som ska användas o.s.v. Detta gör att vi inte kan hårdkoda in sådana värden i koden. Istället använder vi oss av en .ini-fil för varje instans som innehåller de olika variablerna. Sedan har vi skapat en Config-klass i php som vi använder för att kunna hämta variablerna:
Config::getValue("image.upload.path");
Denna klass ser förstås till att lagra alla variabler i minnet när den hämtat in dem så att vi slipper läsa från filen varje gång. Ett ännu mer optimerat sätt vore att under lanseringen läsa in alla variabler och sedan ersätta dem med dess värde i php-filerna, men man ska inte optimera för tidigt.
Hoppas ni tyckte denna lilla inblick i vår lanseringsprocess var intressant. Ställ gärna frågor, kommentera och föreslå förbättringar i kommentarerna på Pusha.
3 Jun
