[brasimon]

Det finns många olika sätt att lansera en webbplats. Nu tänker jag endast på det faktum att lansera ny kod och databasstruktur etc.
Vissa kanske t ex bara kör en update från svn-repot på live, och därefter uppdaterar databasen manuellt. Andra kanske bygger rpm-paket och uppdaterar en webbfront i taget osv.

Jag skulle vilja veta hur ni lanserar era webbsiter som är up-and-running, främst de större projekten.
Även böcker inom detta ämne vore grymt intressant.

[StefanBergfeldt]

Gör en ny sajt på en subdomän, kör vissa delar mot samma databas. Sen bara pekar om domänen

[abergman]

Ursprungligen postat av brasimon

Det finns många olika sätt att lansera en webbplats. Nu tänker jag endast på det faktum att lansera ny kod och databasstruktur etc.
Vissa kanske t ex bara kör en update från svn-repot på live, och därefter uppdaterar databasen manuellt. Andra kanske bygger rpm-paket och uppdaterar en webbfront i taget osv.

Jag skulle vilja veta hur ni lanserar era webbsiter som är up-and-running, främst de större projekten.
Även böcker inom detta ämne vore grymt intressant.

Delvis samma som stefan ovan, annars tar jag en webbfront i taget.

Den stenhårda "under underhåll" och sen trycka ut uppdateringen och sen slå om servern funkar också, men det är inte riktigt lika roligt.

[dotvoid]

Att bygga rpm:er eller liknande är bra och jag känner till en del stora svenska webbplatser som gör så. Det är en bra metod och i byggskript som skapar rpm:er kan man ju ta med ihopslagning av css-filer, js-filer och andra åtgärder. Kanske t o m enhetstester och generering av dokumentation via phpdocumentor (eller motsvarande) går via den här vägen. Man kan använda rena bashscript, make eller andra produkter för detta. Fördelen är att man kan uppnå en bättre abstraktion mellan utveckling, test och produktion. Nackdelen är väl kanske att allt jobb med att sätta upp en sån här miljö, och att man ofta måste köra byggscript även i utvecklingsmiljöer för att se ändringar man håller på med, inte alltid är befogat för mindre projekt. För kompilerade språk är ju en del av det här dock nödvändigt. För stora projekt/projektgrupper är det ju också super att kunna skicka iväg installationsfiler till den som jobbar med servermiljön.

För riktigt stora projekt där man har bra enhetstester (och/eller automatiserade gui-tester) kan man ju köra byggscripten och testerna på natten för att på morgonen få bra rapporter över hela projektets status. Det finns ju faktiskt de som har automatisk release om inga fel eller varningar upptäcks. Det är ganska häftigt och ställer krav på bra heltäckande tester.

För många räcker det ju med att köra en export från ett lösenordsskyddat repository. Jag tycker definitivt inte att det är en bra idé att ha ett levande cvs/svn/etc-träd som kan uppdateras i produktion. Det skapas ju ofta diverse filer som inte bör finnas på en publik webbserver. Man bör ju skapa en branch/tag/edy för varje release om det man håller på med kan påverka kunder etc.

För databasen finns ju flera sätt att hålla reda på vad man gjort för ändringar. Den vanligaste är väl manuella metoden(!). Ofta även när man är så avancerad som ovan. Men det finns ju bra verktyg. T ex finns ju MySQL Workbench gratis för MySQL-användare. Den kan användas för att ta fram diffar och även propagera ändringar i databasmodeller mellan olika servrar eller till/från en ER-modell.

Sedan kan det ju också finnas tillfällen när man måste köra konverteringar. Man kanske ändrar i indexeringen av dokument, storlek på uppladdade bilder eller vilken data som ska lagras duplicerat i en databas för att förbättra prestanda osv. Då måste man ju ofta skapa speciella releasescript enkom för det oavsett ovan metoder.

Jag har varit med i projekt där alla ovan metoder används.

(Och ja - jag har även varit med i projekt där man ändrar, skjuter upp via ftp direkt till produktion och laddar om sidor och hoppas på det bästa...)

[Weaver]

Beror lite på projektet och kraven som finns. Oftast så skapar jag en så kallad stageing miljö på servern som ligger under sin egen subdomän. Denna miljön delar inte filer eller databas med produktionssajten men i övrigt är allt samma.

Under utveckligen av den "nya koden" så har jag sett till att spara alla strukturella ändringar av databasen i en sql-fil så att de kan appliceras på stageing servern. När det är dags för driftsättning så laddar jag upp det nya till stageing miljön och kör sql-filen som ändrar strukturen på databasen (om nu något ändrat sig i databasen).

Om allt lirar i stageing miljön så stoppar jag apache. Kör sql ändringarna på produktion och sedan rsyncar filerna från stageing till produktion. Sedan igång med apache igen.

Naturligtvis skall backup göras mellan stegen så att en rollback kan göras vid behov.

[dAEk]

Intressant tråd!

Tyvärr brukar jag göra det manuellt vilket är en PITA och kräver koncentration för att inget ska gå fel. Som alltid när det gäller manuellt arbete på det här sättet finns det onödiga och stora risker; ibland går det snett.

En del projekt deployas genom TeamCity och det verkar vara sjukt, sjukt, sjukt smidigt!

Databassynkningar görs med RedGates SqlCompare vilket är ett himla smidigt verktyg.

Egentligen skulle man vilja generera ett skript som gör allt åt en så att det bara är att köra igång det och eventuellt kanske fylla i nån uppgift eller två under procedurens gång.

Om ni har några länkar som tar upp ämnet är jag intresserad. Det spelar ingen roll om det är för Linux eller Windows.

[nosnaj]

Kör över allt nytt i mapp, peka om webroten till nya mappen och klart :-)
Fungerar när databas inte ändras, annars är nog enklast ha uppdateringsscript för databas och stänga ned sidan en kortis medans allt tuggar.

[pelmered]

Underslutskedet av utvecklingen och testningen lägger jag upp allt i en egen webroot med en egen databas och pekar en subdomän dit.
När man ska slå över till den nya ändrar man vhosten så att den pekar på den nya mappen och kopierar över databasen(om det är liten databas utan omfattande ändringar) alternativt stänger ner sidan och byter vilken databas som sidan ska ansluta till i en configfil.
Detta är enkelt och brukar sällan resultera i nertid på mer än en minut och det känns okej för alla sidor jag administrerar.

[akelagercrantz]

capistrano

[brasimon]

Grymma svar! Många olika intressanta förslag.

Mest intressant tycker jag ändå är när databasen ändras och man måste lägga in ett gäng ALTER TABLE-kommandon. Tidigare har jag sparat ner dessa i en sql-fil med namnet på kommande release och checkat in dessa till kodträdet. Men ska kolla in de sql-program som föreslagits i tråden.