WordPress udvikling med Vagrant og Ansible

Blandt de mange gode indlæg på WordCamp Danmark 2014 blev vi inspireret af Andreas Eks indlæg om "Next Generation" WordPress udvikling med Vagrant og Ansible. Vi har kigget nærmere på vores udviklingsmetoder, og vi har fået nogle nye redskaber i værktøjskassen som vi er blevet rigtig glade for, og som helt sikkert kommer til at spare os tid fremover.

Siden vi begyndte med at lave hjemmesider i WordPress tilbage i 2006 har vores værktøjer og metoder udviklet sig over en række trin som mange nok kan nikke genkendende til. En (noget forsimplet) beskrivelse af de måder vi har arbejdet på i tidens løb ser således ud:

1. Udvikling direkte på kundens webhotel med WordPress editor og/eller lokal filredigering over FTP

Til at begynde med foregik det meste af vores arbejde via WordPress' admin-interface og med brug af den indbyggede editor direkte på kundens webhotel. Efterhånden skiftede vi så over til at arbejde lokalt med koden i en bedre editor på vores egne PC'er, og efter hver rettelse uploadede vi den til serveren via FTP for at se resultatet af vores arbejde.

Dette er en super simpel måde at arbejde på, og den har den store fordel at udviklingen foregår i præcis det samme miljø som den færdige WordPress installation skal køre på - hvis det virker mens man udvikler, så virker det også når det hjemmesiden sættes i drift. Det er også let at give kunden mulighed for at følge med i udviklingsforløbet, og kunden kan arbejde med hjemmesidens indhold samtidg med at vi arbejder med struktur og udseende. Der er dog også nogle store ulemper som vi i det lange løb ikke kunne leve med:

  • Det er svært at sikre at filer på serveren holdes i sync med lokale kopier, og hvis der er mere end én person der arbejder på det samme projekt samtidig kan det være svært at undgå at overskrive hinandens rettelser
  • Afhængig af det valgte webhotel kan det tage tid at uploade nye filer og genindlæse siden i browseren - især i perioder med høj belastning på et billigt webhotel
  • Banale kodefejl kan let resultere i at hjemmesiden ikke vil loade i browseren, hvilket selvfølgelig er uheldigt hvis andre samtidig arbejder med indholdet eller andre dele af koden
  • Udviklingsmiljøet (f.eks. PHP version eller PHP indstillinger) varierer fra webhotel til webhotel.

2. Udvikling i WAMP/LAMP

Nogle af de ovenstående problemer kan løses ved at udvikle lokalt på egen computer, og vi forsøgte os i en periode med udvikling på en WAMP-stak (Apache, MySQL og PHP installeret på en Windows PC). Det blev vi aldrig rigtig glade for, det var svært at vedligeholde WAMP og få det til at køre stabilt over en længere periode - specielt når vi i perioder havde flere samtidige projekter - og vi oplevede en del problemer når vi skulle flytte tingene fra PC'erne til kundens webhotel fordi der ofte var stor forskel på vores udviklingsmiljø og serveropsætningen.

Vi forsøgte os også med dual-boot Windows/Linux maskiner, men vi oplevede at vi manglede en række værktøjer i Linux som vi var vant til fra Windows, så det var heller ikke nogen success.

3. Egen udviklingsserver, PHPStorm og Git

Efterfølgende valgte vi i stedet at etablere vores egen udviklingsserver (en VPS), og nogenlunde samtidig begyndte vi at bruge Git til versionsstyring og PHPStorm som vores primære udviklingsværktøj. Dette minder meget om den første model ovenfor - vi udvikler direkte på en server - med den store forskel at vi selv har kontrol over serveren og derfor har adgang til at gøre ting som normalt ikke er muligt på et webhotel (f.eks. adgang til kommandolinjen via SSH og fuld kontrol over opsætningen af Apache, MySQL og PHP).

Denne model har tjent os godt i en lang periode - kunden har mulighed for at deltage i arbejdet, og det er meget lettere at arbejde direkte på en server når man har kontrol over alle dele af udviklingsmiljøet og derfor kan bruge bedre værktøjer. Der er dog stadig nogle begrænsninger med denne model:

  • Når vi arbejder samtidig på et projekt skal vi hele tiden koordinere med hinanden så vores uploads ikke kommer i konflikt med hinanden. (Git kan godt håndtere at vi begge retter i f.eks. functions.php, men hvis vi ikke husker at merge vore rettelser først vil de stadig overskrive hinanden på serveren)
  • En kodefejl kan stadig genere andre der arbejder med andre dele af hjemmesiden
  • Som tiden går bliver det vanskeligere at vende tilbage til gamle projekter fordi serveropsætningen ændrer sig (opdateringer af Apache, MySQL, PHP mm). Hvis et gammelt projekt skal startes op igen kan der gå noget tid med at få alting til at køre som det skal med den aktuelle opsætning, inden man kan påbegynde det egentlige arbejde

Denne måde at arbejde på kræver selvfølgelig også at man har internetadgang for at kunne arbejde, men i praksis har det ikke været et problem for os - hvis vi ikke er på nettet har vi alligevel ikke adgang til codex, google og alle de andre netbaserede ressourcer vi hele tiden benytter os af mens vi arbejder.

Vagrant og Ansible

Vagrant og Ansible gør det simpelt at starte en udviklingsserver på sin egen computer og arbejde på den. Det minder lidt om WAMP/MAMP opsætningen, med den store forskel at den server man kører lokalt er en "rigtig" server der kører Linux (vi bruger Ubuntu). Hvert projekt har sin egen server, så man behøver ikke tage hensyn til andre projekters behov når man konfigurerer den, og hele opsætningen gemmes i konfigurationsfiler der er lette at arkivere eller gemme i Git. Når man så efter et år eller to har behov for at arbejde med et gammelt projekt kan man vende tilbage til præcis den serverkonfiguration og den WordPress version som man sidst arbejdede med.

Den underliggende teknologi er virtualisering der tillader at man starter en virtuel maskine med et andet operativsystem end det som "host"-computeren anvender. F.eks. kører vi ofte Windows 8 i en virtuel maskine på en Macbook når vi skal bruge vores gamle Windows-baserede regnskabsprogram. Windows kører samtidig med OSX, og vi kan skifte mellem de to uden at genstarte computeren. Der findes flere forskellige leverandører af virtualiseringssoftware, men når man bruger Vagrant anvender man normalt VirtualBox.

VirtualBox har været open source siden 2007, så det er ikke noget nyt i at man kan bruge det til at køre en Linux-baseret udviklingsserver under Windows eller OSX. Stand-alone er det imidlertid en forholdsvis besværlig proces at få Linux op at køre i VirtualBox fordi man først skal igennem en manuel installation af Linux og derefter en manuel konfigurationsproces. Det er her Vagrant og Ansible kommer ind:

  • Vagrant gør det muligt at downloade og starte en færdig Linux box i VirtualBox. Man kan lave sin egen hvis man vil, men typisk vil man vælge en grundinstallation som andre allerede har pakket med det ønskede operativsystem (man kan f.eks. finde en her: www.vagrantbox.es)
  • Ansible automatiserer processen med at færdiggøre opsætningen, f.eks. installation af WordPress med de ønskede temaer og plugins.

For at komme i gang skal man installere den nødvendige software på computeren, VirtualBox, Vagrant og Ansible som minimum. Dernæst skal man bruge en grundkonfiguration. Man kan lave den fra bunden selv, eller man kan downloade en færdig pakke der er klar til brug. Det sidste kan man f.eks. gøre ved hjælp af en wizard som Andreas Ek fra Flowcom har lavet: http://www.wpstarter.io/. Denne wizard giver brugeren mulighed for at generere og downloade en pakke med alle nødvendige filer til at starte en virtuel udviklingsserver med Ubuntu og Nginx.

Vi valgte at lave vores egen opsætning for at få bedre kontrol over udviklingsmiljøet. Det tog 3-4 dage at få det hele til at virke til vores tilfredshed, med udgangspunkt i et grundlæggende kendskab til Linux men uden at vide noget om Vagrant og Ansible på forhånd. Vi fandt nogle gode eksempler her: 13 Vagrant Resources for WordPress Development.

Med den nødvendige software installeret og det grundlæggende konfigurationsarbejde på plads (som man kan springe over hvis man bruger ovennævnte wizard) tager de kun nogle få minutter at få den lokale udviklingsserver op at køre. Vagrant startes med kommandoen "vagrant up", og Vagrant tager sig herefter af resten. Hvis den virtuelle server findes i forvejen behøver Vagrant blot at starte den. Hvis den ikke findes - hvis der er tale om et ny server til et nyt projekt, eller hvis den er blevet arkiveret og slettet, så tager Vagrant sig af at oprette den igen og kalder Ansible så den bliver korrekt konfigureret. Vagrant tager sig også af at indsætte de nødvendige linjer i hosts-filen så vi kan bruge de korrekte URL'er i browseren (og slette dem igen når vi er færdige med at arbejde på projektet).

Ud over Vagrant og Ansible bruger vi også WP-cli, et kommando-linje interface til WordPress der blandt andet gør det let at eksportere og importere WordPress databasen. WP-cli kan også kaldes af Ansible, så når vi skal arbejde på et eksisterende projekt som ikke allerede er installeret lokalt behøver vi blot gøre to ting:

  • Clone projektet fra Github eller Bitbucket
  • Skrive "vagrant up" på kommandolinjen

Et par minutter senere har vi en lokalt installeret version af projektet som vi kan arbejde med, med præcis den samme opsætning som da vi sidst forlod det. Vi kan arbejde i et miljø som svarer til vores udviklingsserver, men uden at vi risikerer at træde hinanden over tæerne med kodefejl og rettelser der konflikter med hinanden.

Vores udviklingsserver er ikke blevet overflødig, men dens hovedrolle er nu at fungere som det sted hvor kunden kan følge med i udviklingsforløbet og arbejde med indholdet. I øjeblikket holder vi udviklingsserveren i overensstemmelse med vores lokale kopier ved hjælp af rsync - den proces bliver det næste vi skal have kigget på.