Posted by ChristianP on August 19, 2010 at 8:54am
Hej, alla har väl uppgraderat Drupal-kärnan och dess moduler någon gång. Men finns det verkligen inget smidigare och bättre sätt?
Säg att man är ett företag som har runt 15-20 kunder och alla använder Drupal. Hur ska man bära sig åt för att uppgradera kärnan åt alla dessa kunder, så att det inte tar typ 3 dagar? Kan man inte fixa någon sorts automatisering som själv tar backup på databasen, backup på sites-mappen, sätter sidan i offline-mode, stänger av temat och dess contrib-moduler. Fast hur ska man kunna låta en dator ta bort förra drupal från ftp-roten och lägga till nya, samt lägga över sites-mappen? :S
Visst, man kan väl låta flera anställda på företaget hjälpa till, men det är inte alltid man har så många anställda.
Comments
Börja använda
Börja använda versionhantering (Bazaar eller Git är mitt tips) samt Drush, http://drupal.org/project/drush. Utan detta är det inte möjligt att arbeta effektivt.
Jag har en drupal-6-core branch som jag håller uppdaterad med senaste Drupal-version. Från denna kör jag sedan "merge" till var och en av de webb-platser jag ansvarar för. Drupal behöver därmed bara uppdateras en enda gång och sedan åker den smidigt ut till alla webb-platser.
Drush 3 har jag för mig kan uppdatera Drupal core såväl som moduler och teman så det kan vara en annan lösning.
När jag testat lokalt att allt fungerar som de ska med den nya Drupal-versionen så trycker jag ut dem i produktion.
När t ex Drupal 6.19 kom uppdaterade jag 6-7 mindre webb-platser innan frukost. Större webb-platser kräver förstås mer testning och normalt godkännande från ansvarig person hos kund.
Kör du egen server och planerar att hosta fler kunder i framtiden ska du kolla in Aegir, http://groups.drupal.org/aegir-hosting-system. En del jobb att sätta upp men det låter dig smidigt hantera hundratals/tusentals Drupal-installationer.
Men blir det aldrig några
Men blir det aldrig några error på det viset då? Tänkte för att det rekommenderas ju enligt manualen att man ska ta backup på bl.a sites-mappen och det. Så att det inte blir någon förlorad information. Klart, om den tar backup innan den uppdaterar och nåt skulle hända så kan man ju gå tillbaka. Jag tror dock det är mycket (många steg) man kan skita i när man uppdaterar. Men jag ska kolla upp det där Drush, har hört talas om det men inte riktigt förstått det, men jag får väl läsa på lite.
De instruktionerna är tänkte
De instruktionerna är tänkte för oerfarna användare som kopierar filer till servern manuellt med FTP.
För Drupal-utvecklare behövs mer solida, effektiva och automatiserade system.
Okej, för att när vi gör
Okej, för att när vi gör hemsidor så bygger jag dem i Localhost med WAMP. När strukturen är klar och lite innehåll så trycker jag upp den på FTPn för att kunderna ska kunna se resultatet hittills. Är det fler ändringar som krävs så fortsätter jag i WAMP och trycker upp nya databasen och nya filerna när ändringar finns. Sen så låter jag den ligga kvar på internet, och om kunden vill ha fler uppdateringar så gör jag de direkt på webben, för att det är snabbast och smidigast, speciellt om kunden sitter i telefonen samtidigt och vill se ändringarna live. Därmed så blir hemsidan på localhost gammal och den på webben blir nyare såklart. Hur ska jag hantera detta med uppdateringar? Jag kan ju inte uppgradera sidan jag har på localhost för att testa för det är ju den gamla versionen av hemsidan. Detta kommer betyda att jag måste första tanka hem sidan från FTPn, sen uppdatera lokalt på den nya nedtankade - allt funkar. Efter det, uppdatera den publicerade hemsidan. Eller?
Jag kanske måste bygga om mitt tankesätt. Har du några tips, eller hur bygger ni hemsidan från kundmöte, till publicering?
Med rätt verktyg blir arbetet
Med rätt verktyg blir arbetet som Drupal-utvecklare mycket mindre stressig, du gör färre dumma misstag, de misstag man gör är lätta att hitta och återställa etc. Det kommer att ta dig tid att sätta dig in i allt men det är värt det många gånger om.
Steg 1 är att börja använda versionhantering. Efter att du använt det i ett par månader kommer du inte att förstås hur du kunde arbeta tidigare. På http://vimeo.com/8554385 kan du se min föreläsning om versionhantering på senaste DrupalCamp i Stockholm.
Mitt normala arbetsflöde är:
Ny webb-plats:
Uppdatera webb-plats:
Att "trycka ut" kod är bokstavligen ett enda kommando. Versionhanteringen tar hand om allt det jobbiga med att hålla rätt på vilka filer som ändrats etc.
Tack vare versionshanteringen har jag hundra koll på exakt vilka versioner som ligger i vilka miljöer. Är vi flera som arbetar på webb-platsen vet vi också exakt vilken person som skrivet vilken rad kod och när det gjordes.
Tack vara moduler som Context, Features och Strongarm kan i stort sett allt utom själva innehållet ligga i kod.
Vid behov uppdateras lokal- och test-databaser från produktion, samma sak gäller innehållet i mappen "/files". Med hjälp av Drush är detta enkelt, efter att man satt upp sina site aliases kör man bara:
% drush rsync @kund_1.prod:%files @kund_1.dev:%files
% drush sql-sync @kund_1.prod @kund_1.dev
Tackar! Låter väldigt
Tackar! Låter väldigt intressant, ska kolla igenom din föreläsning! Jag har hållt på med Drupal ett år snart och det är väl mest den start-biten som är lite jobbig. Jag har dock gjort en färdig databas med standardmoduler konfigurerade, typ imagecache-bild, Bildspel med views etc som jag bara klonar när en ny kundsida ska byggas. :) Ska bli ändring på detta så man kan jobba ännu mer effektivt = roligare.