Efter ha kommit igång med Drupal kommer jag inte ifrån problematiken med att sitta och utveckla i produktionsmiljö, dvs tillägg av nya moduler och medföljande ändringar i script medför åtminstone för mig ofta att jag behöver fixa och trixa innan det fungerar tillfredsställande. Det har hänt att siten varit helt okontaktbar stundtals.
Så undrar därför hur ni andra hanterar er utveckling?
Har en ”alternativ adress” hos mitt webhotell som enl. dem skall kunna fungera som en testmiljö om jag så önskar, men är lite osäker på vad som händer om jag har samma sajt online på två ställen? Samt hur jag i så fall praktiskt går tillväga för att kopiera sajten dit. Har sett att det finns en ypperlig guide hur man flyttar mellan webhotell http://groups.drupal.org/node/23096 och guiden torde även passa för att kopiera en site, men som sagt, finns det något smidigare och enklare sätt att skapa sig en testmiljö och hur lyfter man i så fall koden på lämpligt sätt till produktionsmiljön?
Eller väljer ni att jobba i lokal miljö för test, i så fall riskerar man att gå miste om test möjlighter om man endast kör lokalt?
Hälsn
Nicklas
Comments
Samma fråga
Svaret på den här frågeställningen är jag också nyfiken på.
Sedan undrar jag vilket webbhotell som har en "alternativ adress" och hur det skulle fungera?
En alternativ adress hos ett
En alternativ adress hos ett webbhotell är väl vanligen en subdomän, om din sajt är www.example.com så kan du lägga din utvecklingssajt på dev.example.com (eller vad du nu väljer att döpa subdomänen till). De flesta vettiga webbhotell erbjuder obegränsat med subdomäner.
Klipp och klistra?
Ok, tack för svaret. Subdomäner som sådant har jag väl koll på, men hur en "alternativ adress skulle kunna fungera som testmiljö" undrar jag. Det är väl inte så enkelt om man bara har begränsade kunskap om databaser? (Webbhotellet är Oderland, om det gör någon skillnad.)
När jag jobbade med CMS:et Plone för 100 år sedan kunde man kopiera instansen till ett annat ställe på webbservern och utveckla där och sedan kopiera tillbaka. Inga databaser eller annat som pekade fel eller strulade på annat sätt.
Jag skulle väldigt gärna vilja lära mig hur man skapar en utvecklingsinstans - gärna som ligger ute på samma webbhotell. I svaren på ursprungsfrågan finns en guldgruva att gräva ur märker jag, men tyvärr går mer än hälften över mitt huvud. Att det inte är så enkelt som att "klippa och klistra" instanser hit och dit med Drupal fattar jag.
-- Kan man gå en kurs?
Det beror lite på vad siten
Det beror lite på vad siten har för status eller användningsområde.
Om det är en "oviktig" site, som min privata, gör jag alla ändringar direkt på siten, efter att ha gjort en backup så klart.
Vad det gäller produktionssiterna så har jag dessa speglade på en lokal maskin. Problemet med många web-hotell som jag ser det är att man bara får en (My)SQL-databas och ibland även begränsat utrymme. Skall man då ha två siter måste man dela databasen. Detta har jag bedömt som "farligt". Det enklaste sättet att komma runt det som jag kommit på är att spegla siten lokalt.
Det enda jag gör direkt på produktionssiterna är att installera säkerhetspatchar / uppdateringar. Vad det gäller vanliga uppdateringar som inte är säkerhetsrelaterade så väntar jag någon dag för att se om någon får problem med dem, hehe, innan jag själv uppdaterar.
Att kopiera en site mellan olika ställen är inget större problem, ta i trä. Det enda som ställt till det för mig har varit att jag fått fel teckenuppsättning men det lär man sig att lösa ("set names utf8" eller så). Man får även hålla koll på vad de olika databaserna heter precis som Johan beskrivit på sidan ovan.
Så mitt förslag är att ha en lokal test-site.
(Såvida du inte har obegränsade resurser på servern samt har möjlighet att skapa dns-records :-) )
/Thomas
Intressant fråga med många olika svar beroende på krav
Enklaste lösningen (som bara funkar om du inte har användargenererat innehåll, som t ex kommentarer):
Du har en lokal utvecklingsmiljö, som kan t.ex vara din egen dator. Du gör all utveckling där, installerar moduler, lägger till innehåll etc. När du vill flytta ut innehållet till din produktionsmiljö så kan du använda ftp, men rsync är bättre, men det kräver att du har ssh access till produktionsmiljön. För att databasen ska "hänga med" så får du göra en mysql dump i utvecklingsmiljön och sen läsa in dumpen i produktionsmiljöns databas. Jag brukar använda modulen backup and migrate för det, då blir det busenkelt.
Om du har dessutom ska generera inehåll i produktionsmiljön så blir det betydligt svårare. Thomas Barregren har skrivit utförligt om det här. Det känns inte som drupal har någon bra lösning på det här ännu, eller så har jag inte lärt mig det ännu. Nyckeln går ut på att få ut konfigurationsdata ur databasen och ner i filer, som sen kan versionshanteras och flyttas runt. Jag har läst att features ska vara en bra modul i ett sånt här sammanhang.
matti
Thanx...
Tack för engagemanget, flera bra tips, anledningen till att jag tog upp alternativa adresser var att jag kom att tänka på att det eventuellt skulle gå att använda den alternativa adressen som min host leverantör Binero tillhandahåller, kollade även det med dem direkt och de var positiva till att jag kunde använda den som testmiljö...
http://wiki.binero.se/index.php?title=Kom_ig%C3%A5ng/Allm%C3%A4n_informa...
Yes tanken är att sajten skall innehålla material skapat av användarna dvs användargenererat innehåll så det blir därmed knepigt att jobba i lokal utvecklingsmiljö om jag tolkar Matti korrekt?
Jag har användargenererat
Jag har användargenererat material på mina produktionssiter så det är inget problem. Man får jobba så här i stora drag:
Jag gör enligt ovan varje gång det släppts en ny huvudrelease av Drupal (4.5, 4.6, 4.7, 5, 6 osv). Eftersom jag har några egenskrivna moduler behöver de uppdateras och testas enligt de instruktioner som publiceras. Det brukar ta lite tid och är inget man gör on-line... :)
Efter ett tag lär man sig även vilka modulers underhållsreleaser som strular respektive vilka som bara flyter på. Det kan vara bra att känna till...
Säkerhetsuppdateringar kan man alltid patcha in om man av någon anledning vill avvakta innan man uppgraderar riktigt.
Det brukar påpekas ofta men inte tillräckligt ofta :)
Se till att ha en fungerandes färsk backup!!!
Genom att flytta allt från din produktionssite till en lokal site får du ett utmärkt test på att din backup funkar!!! :)
/Thomas
Thomas checklista funkar bra för mindre/medelstora sajter
Problemet är
Uppdatera produktionssiten exakt enligt körschemat
Jag utgår ifrån att Thomas menar att det här görs manuellt. Det håller inte i längden för större sajter, med uptime-krav. Då måste man ha en automatiserad lösning, och det är såna jag främst är intresserad av. Själva koden går ju snabbt att att byta ut (och kan automatiseras), det är konfigurationsändringar som är det svåra.
Tyvärr
Du råkar ut för samma problem om du kör staging miljön på en alternativ adress som du har fått av din webbleverantör. Var du utvecklar / stagear spelar mindre roll, kruxet är hur du flyttar över konfigurationsändringar till produktionsmiljön på ett bra sätt.
Jag är inte där ännu själv,
Jag är inte där ännu själv, men det känns som att framtiden är att placera all Drupal-kod i ett versionshanteringssystem och försöka placera så mycket som möjligt av konfigureringen av Drupal i kod med installationsprofiler och features (eller liknande lösningar).
Projekt som Drush och Ægir känns också som en del av en bättre helheltslösning för Drupalsajter. Men än så länge är det ingen barnlek och Thomas Barregrens artikel som mkotsalainen länkade ovan är ett tydlig exempel på detta.
Hur vi arbetar
Med kod och teman
För varje nytt projekt skapar vi ett svn "snart git" repository där vi checkar in "sites"
Den versionshanterade koden är alltid testad så att den fungerar tillsammans med resten av siten i en utvecklingsmiljö.
Miljöer
Vi arbetar med 3 stycken installationer per projekt i dagsläget.
Lab
Testa egna moduler, testa nya moduler, testa tema ändringar
Dev
Bygga ihop funktionallitet ifrån lab med resten av siten, testa så att allting fungerar
Deploy - "koden för moduler och teman är utcheckat ifrån repository"
Den här installationen är den vi sedan kan under processens gång visa upp för kund. :]
Eftersom att den här siten endast innehåller kod och tema som är taget ifrån ett versionshanterat repository kan man göra sig säker på att det inte sker några konflikter här som gör att siten kraschar när den demas, eller arbetas med av kund.
Lab och Dev ersätts vid jämna mellanrum med det som finns färdigutvecklat och "levererat" i deploy
"ps, det här är vårat nuvarande ideal, inte alltid man klarar av att hålla sig inom ramarna" ;)
Databas / konfiguration
Här behöver vi goda råd och tips! "Gör inte alla?"
Förtillfället arbetar vi med databas migrering, vilket inte är HELT enkelt.
Vi håller på och arbetar fram en metod som går ut på att man packar funktionallitet med hjälp av features.
Samt att vi labbar endel med "aegir" och konceptet installationsprofiler för att ytterligare packa funktionalitet, och smidigt kunna skicka ut ändringar i funktioner till andra siter.
Ifall det kommer upp en bra metod för att exportera och importera funktionallitet utan att skriva över innehåll så vill vi jätte gärna ta del av metoden :D
Lokal utvecklingsmiljö + versionshantering + Drush
En lokal utvecklingsmiljö är i mitt tycke en grundförutsättning för att kunna arbeta på något vettigt sätt. Ditto versionshantering och Drush. Man behöver lägga lite tid och kraft på att sätta upp det hela men det återbetalas mångfallt.
Jag gör all utveckling i min lokala miljö, oavsett om det handlar om min privata blog eller om stora kunders system.
För små webb-platser som jag arbetar ensam på används den lokala miljön för både utveckling och test.
För större webb-platser där vi är flera som utvecklar har alla egna lokala miljöer och sedan en eller två miljöer på en server för utveckling och test.
Views och innehållstyper etc. går att exportera till kod. Med hjälp av Features modulen är det riktigt smidigt. På de små webb-platserna gör jag fortfarande inställningar manuellt direkt i produktion. På stora webb-platser fungerar det att lägga dem i hook_update funktioner och köra dem med drush/update.php.
All kod ligger i system för versionshantering, i mitt fall Bazaar. Sedan jag väl tog steget till att börja använda versionshantering kan jag inte förstå hur jag arbetade tidigare. Det gör allt så mycket smidigare, snabbare och tryggare.
Har funderat en del kring det
Har funderat en del kring det här när det gäller drupalsverige.se. Känns som det är en tröskel vi behöver ta oss över för att komma igång med sajten. Hoppas någon med erfarenhet av större sajter kan hjälpa till med det.
Problemet och en del av lösningen beskrivs bra på http://developmentseed.org/blog/2009/jul/09/development-staging-producti....
/Adam
Har byggt/använt en hel del
Har byggt/använt en hel del olika former av dev/qa/live (eller bara live ;) beroende på omständigheterna, och antalet medverkande.
Det senaste byggde vi med git som versionshanteringssystem, med separata branches som mappade till dev/qa/live -miljöerna. Alla miljöer uppdaterades automatiskt när man commitade till mostvarande branch, och dev-miljön installerades dessutom om från scratch (vi hade en installationsprofil för vårt bygge) varje natt.
Problemet är ju att det sällan finns en lösning som funkar för alla team/projekt.
Minsta gemensamma nämnare, och det som har funkast "bäst" överlag i projekten jag varit involverad i har varit;
En intressant föreläsning
Jag hittade en intressant föreleläsning om det här - Staging and Deployment. Väl värd att se om man är intresserad av såna här frågor. Han kör en demo på Deployment modulen som de har utvecklat för att kuna migrera innehåll från en stagingmiljö till produktion. Den kan säkert vara användbar i stora projekt.
Drush 3 ser ju ut att kunna bli en riktigt hit - det är otroligt kraftfullt att kunna administrera olika miljöer över ssh.
Hehe! Kul att se att det är
Hehe! Kul att se att det är Greg som håller föreläsningen du tipsar om. Om du är sugen på att träffa "Deploymannen" i videon irl så kommer han på D7-releasefesten den 7 jan. Han jobbar bredvid mig just nu :)
/Fabian på NodeOne
Jag är utomlands då
men min kollega Daniel kommer nog på releasefesten. Roligt att höra att ni jobbar med Greg, han verkar jätteduktig!
matti
Jepp, det är fantastiskt kul
Jepp, det är fantastiskt kul att Greg valde att flytta från Seattle till Stockholm för att börja jobba hos oss. Men han är inte bara en väldigt duktig utvecklare utan också en klippa i Drupalgemenskapen, och det är den han brinner mest för.
Jakob Persson – Leancept – Results-only digital and marketing consultants – Personal blog
Newer screencast
Hej! Sorry I am still learning Swedish so I have to post this in English. That presentation is a couple years old, you can see a newer demo here
http://drupaldojo.com/session/deploy-module-and-future-staging-and-deplo...
It is more about Deploy module and less about the other solutions, but it also looks forward to Drupal 8 where we will hopefully be able to solve some of these problems.
Look forward to meeting everyone at the release party or at Drupal Dev Days in February!
Rekommenderad för guide!
Den här diskussionstråden innehåller så mycket bra information att den har taggats som en blivande guidesida. Om du vill skriva en guide på svenska Drupalforumet kan detta alltså vara ett bra val!
//Johan Falk, forumadministratör
Förhoppningsvis kommer
Förhoppningsvis kommer framtida versioner av Drupal håll konfigurationer lagrade i filer istället för i databasen, men tills dess är det features + strongarm + aegir + drush som gäller ett bra tag framöver. Deploy-modulen är också intressant, men jag tror inte att den kommer ta sig lika bra.
/Odd Hill