Tool chain til webudvikling

toolchain

Så, nu blev det endelig tid til at skrive en rant omkring teknik og nørderi – bedre kendt som “rigtig arbejde”. Jeg håber at kunne få lidt feedback på min tool chain fra nogen der har erfaringer fra noget tilsvarende eller blot at give lidt inspiration til andre.

I min fritid er jeg web-ansvarlig for en række internationale community sites. Sitet startede oprindelig som en udelukkende dansk side, men har sidenhen vundet terræn i udlandet. Siden fungerer som kontakt- og mødeplatform for knap 10,000 brugere og både har en traditionel front-end samt en mobil webapp (mobile jquery).

Rent teknisk er sitet helt traditionelt bygget på en LAMP-konfiguration der er hosted i et virtuelt miljø.

Til at starte med var min tool chain mere eller mindre ikke eksisterende. Jeg skrev kode i Notepad++ og uploadede direkte på produktionsserveren via FTP. Denne praksis var yderst effektiv, specielt i den periode hvor sitet udelukkende fandtes på dansk. Senere kom flere lande på og det blev et helvede at vedligeholde.

Efter en række søgninger på nettt blev jeg enig med mig selv om at jeg burde finde et deploy system. Kravene til deploy systemet var ganske få (primært stabilitet og pris). Jeg endte med at falde pladask for Deploy HQ. En service der har fået gode anmeldelser og samtidig tilbyder gratis service til Open Source projekter. Koden til sitet var fra starten udtænkt som værende Open Source så alt var i den fineste orden.

Efterfølgende valgte jeg at publicere koden i GitHub (som integrerer med Deploy HQ). Den åbenlyse fordel ved GitHub (eller ja, ved versions-systemer) er at det er muligt at branche, merge, m.v. I det jeg i en periode havde håndholdt en mængde forskelligheder mellem de understøttede lande (primært Danmark og Norge) var merge funktionaliteten en kærkommen nyhed i min tool chain.

Jeg dumpede hele koden til det danske site ind i mit GitHub repository. Kopierede den norske version ind i mit lokale check out og påbegyndte en lang aften med at merge forskellighederne. I langt de fleste tilfælde var forskellene rent faktisk en fordel: F.eks. var der ændringer i den danske side som ikke var tilgængelig på den norske og vice versa – men i andre tilfælde var der tale om reelle forskelle der skulle håndteres via landespecifikke konfigurationsfiler. Disse konfigurationsfiler understøttes af Deploy HQ – så det er muligt at have f.eks. en version til hvert land og hvert miljø.

I takt med at antallet af lande og brugere steg blev det tydeligt at der måtte indføres et udviklingsmiljø og en mere professionel tilgang til nye funktioner og features. Rent praktisk blev der oprettet et udviklingsmiljø/testmiljø for hvert land. En process blev opfundet og sitet var rullende:

  1. Nye ændringer udvikles lokalt
  2. Checkes ind i GitHub
  3. Deployes globalt i udviklingsmiljøet
  4. Basis funktionalitet afprøves
  5. Deployes globalt i produktionsmiljøet

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *