Del 1: GIT på Bravomedia – vår utvecklingsmiljö

Vi på Bravomedia har valt att använda oss av GIT för vår källkodshantering i alla de webbprojekt vi jobbar med. GIT är ett distribuerat versionskontroll – system. Det innebär att det skiljer sig åt en aning från Subversion, Visual Sourcesafe och liknande system som är uppbyggda runt ett centralt s.k. repository som alla jobbar mot.

Fördelarna för oss som arbetar är framförallt möjligheten att samarbeta i projekt utan att riskera att skriva över varandras arbete. Dessutom innebär det ett tryggt och säkert sätt att undersöka och testa ny funktionalitet och lansera färdig funktioner och lösningar på ett sätt som garanterar att det som lanseras är kvalitetssäkrat. Att lanseringarna kan göras med automatik på ett tryggt sätt, utan några större förkunskaper medför att inget kan missas och att inga ändringar behöver göras i kundernas produktionsmiljö eftersom det är ”mest effektivt”.

 

Så använder vi på Bravomedia GIT

Så här använder vi på Bravomedia oss av GIT i vår webbutveckling. Vi har lånat mycket av våra idéer från den utmärkta blogg-posten av Joe Maller: A web-focused Git workflow

Våra förutsättningar på Bravomedia är att vi består att ett gäng utvecklare och designers. Vi är totalt fem stycken. Vi utvecklar egen webbaserad programvara och webbplatser / onlinetjänster för kunder.

Förutom det uppenbara med att kunna jobba tillsammans i projekt utan att behöva fråga varandra om det är ok att öppna och ändra en fil just nu, så är en av de stora fördelarna för oss att kunna skapa branches för att testa olika nyheter och sidospår i vår ptoduktutveckling utan att det påverkar andras utveckling under tiden. Att vi dessutom i förlängningen kommer att kunna ge våra kunder och partners möjlighet att delta i utvecklingen är en framtida möjliggörare.

 

Fungerande utvecklingsversion

Viktigt för oss är att det alltid finns en fungerande utvecklingsversion tillgänglig av våra produkter och webbplatser – där kunden kan följa utvecklingen. I denna ”utvecklingsversion” ska alltså ingen utveckling ske – den ska bara innehålla den fräschaste fungerande versionen.

Lösningen är ett centralt bare repository med ett tillhörande konventionellt repository. Ett bare repository innehåller inte någon fungerande kod utan används endast för ren källkodskontroll. Det konventionella repositoryt innehåller den fungerande versionen av webbplatsen / produkten. Med hjälp av så kallade hooks håller vi det konventionella repositoryt i synk med det bare repository som alla projektdeltagare kommer att jobba mot.

Alla deltagande utvecklare kan skapa egna kloner av repositoryt och utveckla sidan vidare på sin egen maskin eller på ett eget område på samma server. Eftersom vi använder oss av diverse server-komponenter för minnescache, logganalys etc så har vi valt att våra egna utvecklare jobbar i sina egna hemkataloger på servern. Via dynamiska virtuella host-inställningar i Apache kan vi enkelt skapa fungerande subdomäner under dev.bravomedia.se för att komma åt respektive utvecklares version av sidorna och för att komma åt den utvecklingsversion som man vill visa upp för slutkunden.

Vi vill även att man ska ha möjligheten att göra mindre ändringar på den utvecklingssidan som slutkunden ser utan att det finns risk att förstöra något. Designers eller projektledare som lägger till enstaka bilder eller liknande ska kunna göra detta utan att behöva klona en hel webbplats och sätta sig in i en rad Git – kommandon.

 

Strukturen

Vi har valt att hålla alla repositories i två separata kataloger och varje utvecklare får en egen www-katalog i sin hemkatalog dit aktuella projekt klonas

/var/www/git/hub       <-- för bare repositories
/var/www/git/prime     <-- för konventionella repositories
/home/developer1/www   <-- för klonade repositories under utveckling

 

Att påbörja ett projekt

För att starta ett nytt projekt eller göra ett existerande projekt tillgängligt via Git ska ett konventionellt repository kopieras eller skapas en mapp och filer till prime-katalogen på servern. Därefter loggar man in via terminal / ssh och initierar Git för projektet.

$ cd /var/www/git/prime/projekt1/
$ git init
Initialized empty Git repository in /var/www/git/prime/projekt1/.git/
$ touch index.php
$ git add .
$ git commit -m"import av existerande kataloger och filer"
[master (root-commit) 42137e1] import av existerande kataloger och filer
1 files changed, 7 insertions(+), 0 deletions(-)
create mode 100644 index.php

Nu har vi en fungerande webbplats (aka prime) i Git. Dags att skapa ett bare repository som håller koll på alla förändringar. Detta repository kallar vi för projektets hub.

$ cd /var/www/git/hub/
$ mkdir projekt1.git
$ cd projekt1.git
$ git --bare init
Initialized empty Git repository in /var/www/git/hub/projekt1.git/

I det här läget finns det dock ingen koppling mellan våran prime och vår hub. Detta åstadkommer vi genom att gå in i prime-katalogen och lägga till hub som en s.k. remote. Vi skickar därefter dit vår master branch som innehåller projektets huvud-applikation.

$ cd /var/www/git/prime/projekt1/
$ git remote add hub ../../hub/projekt1.git
$ git remote show hub
* remote hub
Fetch URL: ../../hub/projekt1.git
Push  URL: ../../hub/projekt1.git
HEAD branch: (unknown)
$ git push hub master
Counting objects: 3, done. Writing objects: 100% (3/3), 272 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To ../../hub/projekt1.git * [new branch]      master -> master

 

Hooks

Git har stöd för s.k. hooks – kod som exekveras i samband med Git-relaterade operationer.

Eftersom alla utvecklare kommer att jobba mot vår hub – ett bare repository så behöver vi använda oss av hooks för att vår prime som kunden kommer att kolla på ska uppdateras automatiskt efterhand som ändringar committas av våra utvecklare och designers.

Två hooks behövs. En som ser till att vår prime automatiskt uppdateras när vår hub uppdaterats från en av våra utvecklare. Dessutom behövs en hook som uppdaterar vår hub om någon skulle ha ändrat / lagt till något direkt i vår prime. Detta ska normalt inte ske, men bör vara tillåtet för att man ska kunna göra små bidrag till projektet utan att behöva gå igenom stegen som krävs för att klona projektet, ändra och synka tillbaka.

  • post-update – i Hub
    Denna hook kallas det automatiskt på när vår hub tar emot en uppdatering. Scriptet innebär att vi byter katalog till vår primeoch därifrån hämtar den senaste versionen.

    $ vim /var/www/git/hub/projekt1.git/hooks/post-update
    #!/bin/sh
    echo
    echo "**** Pulling changes into Prime [Hub's post-update hook]"
    echo
    
    cd ../../prime/projekt1/ || exit
    unset GIT_DIR
    git pull hub master
    
    exec git-update-server-info

    $ chmod 755 /var/www/git/hub/projekt1.git/hooks/post-update

  • post-commit – i Prime
    Denna hook anropas i prime efter att något committats. Det innebär alltså att man kan göra ändringar där (även om vi vill undvika att göra ändringar direkt i den miljön) och få dessa tillgängliga för andra utvecklare utan att riskera att förstöra något.

    $ vim /var/www/git/prime/projekt1/.git/hooks/post-commit
    #!/bin/sh
    
    echo
    echo "**** pushing changes to Hub [Prime's post-commit hook]"
    echo
    
    git push hub
    $ chmod 755 /var/www/git/prime/projekt1/.git/hooks/post-commit


För utvecklaren som vill vara med och bidra

Utvecklaren som vill vara med och bidra ska checka ut sin egen version av webbplatsen och arbeta vidare med den på sitt eget utvecklingsområde. När allt är testat och fungerar tillfredsställande där ska detta återföras till vår hub.

Utvecklaren måste logga in via ssh med sitt eget inlogg till servern. Så här enkelt är det sedan att via terminal skapa en kopia av det projekt vi nyss skapade:

$ cd ~/www
$ git clone /var/www/git/hub/projekt1.git
Initialized empty Git repository in /home/developer1/www/projekt1/.git/

Där jobbar man sedan vidare med webbplatsen med sin favorit-editor. Om man skulle använda sig av Eclipse, Zend Studio eller någon annan editor med Git-stöd kan man utföra sina Git-kommandon direkt i editorn.

 

Apache-konfiguration

Vi vill enkelt kunna jobba med nya projekt utan att behöva krångla runt alltför mycket med Apache-konfiguration för varje ny webbplats vi jobbar med. Vi vill därför använda våra standardiserade sökvägar i kombination med dynamiska virtuella hosts för att skapa en uppsättning url-er som alltid kan användas.

Vi tänker oss följande för projektet ovan:
http://projekt1.dev.bravomedia.se <– blir adressen för den version av sidan som kunden kommer att se
http://projekt1.developer1.dev.bravomedia.se <– blir adressen för utvecklingsversionen av sidan som developer1 arbetar med

Den delen av domänen som föregår dev.bravomedia.se och developer1.dev.bravomedia.se kommer alltså dynamiskt att mappas mot den katalog som motsvarar domänens inledande del.

Vi vill dessutom att mappen .git inte blir tillgänglig för åtkomst via webbläsaren.

Det gör vi genom att aktivera virtuella alias och skapa en config-fil för apache:

# a2enmod vhost_alias
Enabling module vhost_alias.
Run '/etc/init.d/apache2 restart' to activate new configuration!
# /etc/init.d/apache2 restart
# vim /etc/apache2/sites-available/git
<VirtualHost *:80>
#Developer websites
ServerAdmin daniel@bravomedia.se
ServerName code.dev.bravomedia.se
ServerAlias *.code.dev.bravomedia.se
VirtualDocumentRoot /home/%-5/www/%-6+

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog /var/log/apache2/access_log vcommon
ErrorLog /var/log/apache2/error_log
</VirtualHost>

<VirtualHost *:80>
#Staging websites for Git Development
ServerAdmin daniel@bravomedia.se
ServerName bravoadmin.dev.bravomedia.se
ServerAlias *.dev.bravomedia.se
VirtualDocumentRoot /var/www/git/prime/%-4+

# deny access to the top-level git repository:
RewriteEngine On
RewriteRule \.git - [F,L]

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
ErrorLog /var/log/apache2/error_log
CustomLog /var/log/apache2/access_log vcommon
</VirtualHost>
# a2ensite git
# /etc/init.d/apache2 reload

 

Gitweb

Vi vill dessutom gärna ha möjlighet att granska våra repositories via webbläsaren. Det gör vi med hjälp av Gitweb.

Gitweb finns färdigt att installera för de flesta Linux-distributioner. Därefter behöver vi i stort sett bara ändra sökvägen i gitwebs konfiguration och peka ut platsen där vi lagrat våra repositories.

# aptitude install gitweb
# vim /etc/gitweb.conf
$projectroot = "/var/www/git/hub"

Du kommer därefter åt Gitweb via aliases /gitweb på din server.

Med detta så avslutar jag första delen av denna två-posts beskrivning av hur vi använder Git. Läs gärna den andra delen här.

 

Del 2: GIT på Bravomedia – det dagliga arbetet

Detta är en uppföljning på min tidigare post angående hur vi konfigurerat och tillämpar Git för våra behov på Bravomedia.

 

Vårt dagliga värv

För att underlätta i vårt arbete så har vi skapat egna shell-script som initierar ett nytt projekt korrekt, såväl vårt gemensamma repository som varje utvecklares eget område.

Scripten har placerats i /usr/local/bin/ för att samtliga användare ska kunna köra dom.

 

  • bravoinit www.example.com – skapar repositories under /var/www/git/hub och /var/www/git/prime. Om det finns en existerande webbplats under vårt tidigare utvecklingsområde ( /var/www/html ) så flyttas den in till vårt nya utvecklingsområde. Filrättigheter sätts så att alla användare i gruppen webdev på vår server kan jobba och ändra våra repositories.
  • bravodevelop www.example.com – klonar ett existerande projekt i Git till utvecklarens eget område och kopplar ihop dessa.

 

Därefter jobbar vi helt enkelt som vanligt och använder oss i stort sett endast i vårt dagliga arbete av synkroniserings-funktionerna för Git samt de branching-möjligheter som användning av Git.

Branching är en viktig funktion i vår produktutveckling som möjliggör att vi kan testa vidareutveckling i vissa riktningar, med möjlighet att enkelt förkasta dessa om vi märker att de inte fyller sitt behov. Vill vi t.ex. bygga in stöd för minnescache genom hela vår plattform kan vi börja testa detta i en egen branch med vetskapen att vi helt kan förkasta denna funktionalitet om vi inte ser resultaten vi önskar.

Några av de funktioner i Git vi utnyttjar regelbundet:

$ git pull
#hämtar senaste versionen av koden från det centrala repositoryt till utvecklarens eget område
$ git commit
#sparar utvecklarens förändringar till repositoryt
#görs typiskt när en funktion är färdigutvecklad och testad på utvecklarens eget område.
$ git push
#skickar tillbaka alla uppdaterade filer från utvecklarens område till det centrala repositoryt

Flöde för att skapa branches:

När det gäller hur vi arbetar med branches så har vi lånat idéer från våra idoler på Thinkvitamin.

 

$ git push origin master:refs/heads/ny_feature_branch
#skapar en ny branch med namnet ny_feature_branch för test / utveckling av ny funktion
$ git fetch origin
#ser till att allt uppdateras från det centrala repositoryt
$ git branch --track ny_feature_branch origin/ny_feature_branch
#skapar en lokal version av den aktuella branchen
$ git checkout ny_feature_branch
#checkar ut den nya branchen så att alla förändringar vi fortsättningsvis gör sparas dit

därefter jobbar man på som vanligt, om man vill vara säker på att den nya funktionaliteten man utvecklar fortfarande är kompatibel med master – branchen bör man regelbundet slå ihop dessa på sitt utvecklingsområde.

$ git merge master

När man är nöjd med det man utvecklat och vill slå ihop detta med sin master, slår man först ihop sin branch med master-branchen enligt ovan och testar att allt fungerar tillfredsställande. Därefter gör man enligt följande:

$ git checkout master $ git merge ny_feature_branch

Om man är övertygad om att arbetet med den aktuella branchen faktiskt är klart så kan man i samband med detta även ta bort den helt.

# ta bort branchen från det centrala repositoryt
$ git push origin :refs/heads/ny_feature_branch

# ta bort den lokala branchen
$ git branch -d ny_feature_branch

 

Driftsättning av projekt

I enlighet med de metoder för branching vi just gått igenom så kan man skapa en branch som används för lansering av projekt. Genom att skapa en branch med namnet ”deploy” så kan vi regelbundet lägga undan testade och fungerande versioner av vår master – och använda denna för lansering.

Denna branch används alltså inte egentligen för någon direkt utveckling, utan endast för att sätta färdiga versioner.

 

# utcheckning av deploy-branchen, kan göras av valfri utvecklare
$ git checkout deploy

# se till att få senaste versionen
$ git pull origin deploy

# slå ihop master-branchen med deploy-branchen
$ git merge master

# tagga releasen som vi är på väg att genomföra
$ git tag -a -m "Våra kommentarer angående releasen" [tag_name]

# tryck tillbaka alla förändringar till deploy-branchen
$ git push --tags origin deploy

# återgå till master branchen, eftersom vi aldrig gör några ändringar i deploy-branchen
$ git checkout master

Därefter har vi en branch med namnet deploy som vi kan använda för att lansera våtr projekt. Vem som helst kan under tiden fortsätta arbeta med projektet och genast bygga vidare på nästa version, medans vi i lugn och ro lanserar projektet.

 

Lansering med DeployHq

Eftersom vi vill kunna lansera våra projekt till en eller flera servrar, utan att låta någon egentligen fysiskt logga in på våra produktionsservrar så använder vi oss av tjänsten DeployHq.

Där definierar vi snabbt och enkelt upp våra projekt och kopplar ihop dessa med våra fördefinierade produktions-servrar. Vi väljer att vi vill lansera projektet från dess deploy-branch och kan live följa hur projektet publiceras på en eller flera av våra servrar medans vi tar en välförtjänt kopp kaffe.

 

 

Summering

Vi är som sagt relativt nya med Git. Efter att tidigare använt oss sporadiskt av Subversion så känner vi att detta ger oss mycket större flexibilitet. Även om vi i dagsläget jobbar mot samma server så medför detta i förlängningen att vi kan göra utvecklingen lokalt om vi önskar. Det är dock framförallt i själva lanseringsfasen vi ser de stora fördelarna.

Att inte behöva göra någon utveckling lokalt, utan på ett tryggt och säkert sätt genomföra ändringarna på vår testserver och trycka ut dessa utan några märkvärdiga förkunskaper, och utan oro över att missa att överföra enstaka ändringar är ovärderligt för oss.

 

Eftersom vi fortfarande är ganska färska tar jag gärna emot era kommentarer, kan vi jobba ännu effektivare och bättre med Git skulle ingen bli lyckligare än jag 🙂

 

 

 

 

 

 

 

 

Lonely Island – Vilka sköningar

Hot Rod, en klart underskattad film som inte fått så mycket publicitet som den förtjänar var min första kontakt med sköningarna Lonely Island.

Jag vet inte vad man ska säga att de håller på med, men allt de gör blir hysteriskt roligt den saken är klar.

På senare tid så är det väl främst deras ”musik” som kan ha gjort att ni skulle kunna ha träffat på dom, men om ni inte gjort det så ta en titt på deras alster – och missa för allt i världen inte Hot Rod – en av senare års roligaste filmer, dessutom med Europe som i stort sett står för filmens hela soundtrack.

För er som vill få lite feeling har jag plockat ut lite av det bästa de gjort:

Nyast – Jack Sparrow, musikvideo med Michael Bolton

Sjukast: ”Motherlover”

Första musikvideon jag såg med dom: ”Jizz in my pants”

I’m on a boat – lite sommartema med bl.a. Justin Timberlake och T-Pain

Lite highlights från filmen Hot Rod

Twitter är genialt

Ni som inte fattat att Twitter är grymt, fatta det nu. Ni missar en värld av insiktsfulla, humoristiska och smarta budskap sammanfattade på mindre än 140 tecken.

Dessutom ger Twitter en fantastisk snabb och lättanvänd kommunikationskanal till många av de personer ni beundrar mest – och de flesta av dom är fantastiskt duktiga på att snabbt svara på de frågor eller tillrop som man skickar till dom.

För er som inte redan gjort det, ge det chansen nu. Twitter är allt som Facebook inte är. Kärnfullt, humoristiskt och underhållande. Tror inte jag läst ett enda ”dags att sticka och träna” på Twitter överhuvudtaget faktiskt. Bara en sån sak 🙂

Genialt på fotbollstema – av @Leifby
Genialt av Leifby - på fotbollstema

Snabb dialog med @Magnusbetner om vårt gemensamma intresse för poker:

@leifpagrotsky svarar helt underbart på @carlbildt och ger oss Twittrare en helt ny bild av sig själv. Kan karln verkligen skoja till det så här?!

Ett par sköna axplock som kanske kan fungera som en spark i rätt riktning för er som ännu inte börjat använda Twitter. Gör det nu, och hitta några intressanta personer attt följa. Det är en alrig sinande källa till glädje och kunskap.

Ni har väl inte missat Cirkus Kiev?

Roligast på radio det senaste året har utan tvekan P3-programmet Cirkus Kiev varit.

De lyckas alltid hitta nån sjukskön vinkel i sina klipp som tilltalar mig något oerhört. Bra genomtänkta grejer, alltid placerade i en miljö som ger en liten extra krydda. Säkert extra tilltalande för mig att det finns en del igenkänningshumor i sketcherna från supportteknik eller med teknik-Pata.

Ett par riktigt bra exempel på deras humor, där ett hyfsat enkelt, men genomtänkt manus satts in i en klockren miljö:

Lyssna: Hur gick TV-vinjetten? (Midsomer)

Lyssna: Ernst tillverkar pungvikter

London

Hemma. Slappnar av efter 4 intensiva dagar i London.

Vi åkte för att få lite tid för oss själva, jag och min fru sedan 10 år. Vi fick kanske inte så mycket tid för oss själva i denna fantastiska stad, men oj vad mycket kraft vi har med oss hem. Det var ren rekreation.

Om det är att vi snittat 6 timmar i sömn, eller gått säkert 2 mil per dag vet jag inte, men rekreation har det varit.

Kanske är det de eviga kontrasterna som gör det. Ena stunden försöker vi knö oss på en full tunnelbanevagn med tre stora resväskor, nästa stund är vi i superlugna Green Park med en kopp kaffe i handen. Försöker lista ur var vi ska ta vägen på Picadilly cirkus ena stunden för att snart därefter smita ner och käka god vietnamesisk tre-rätter i en läcker källar-lokal fjärran från all stress. Ja, kanske är det kontrasterna som gör det.

Staden har helt klart vunnit mig tillbaka i alla fall efter att jag varit lite avogt inställd till den, resultatet av en resa i tonåren med familjen där jag säkert inte var ett roligt resesällskap – något jag antagligen ställt in mig på redan i förväg.

Nu är jag helt säker på att det inte var sista gången jag besökte London, det är en stad jag kan tänka mig att bo, arbeta och turista i. Synd att detsamma inte gäller min hustru som hade svårt att komma över den första intensiva kontakten med staden när vi försökte ta oss via tunnelbanan i rusningstrafik till vårt hotell. Jag var bara glad att vi åkte utan barnen just då, för det hade blivit stressigt!

Planen var att ägna fredagen åt shopping och lördagen åt sightseeing, och det lyckades vi ganska bra med.

Harrods kvalade enligt hustrun in som sightseeing och fick därför klaras av under lördagen. Och efter att ha varit där är jag beredd att hålla med henne. Det var en sevärdhet som både fascinerade och äcklade. Med tanke på all fattighet och elände i värden så känns det ju vidrigt med ett ställe där man kan köpa te för 50 000 kronor per kilo. De säljer även te för 500 kronor per kilo. Någon anser alltså att det kan vara vårt 100 gånger så mycket för te som smakar lite bättre. Det är sjukt.

Jag hade gärna hunnit med både fotboll och musikal, men vi valde att gå och se nya filmen med Jack Sparrow i huvudrollen, i 3D. Helt klart en cool upplevelse trots att själva filmen var allt annat än bra.

På flyget hem kunde jag njuta av min bärbara Mac. Tack vare den kunde jag knåpa ihop filmen nedan för att kunna visa barnen när vi återförenades där hemma. En perfekt avslutning på helgen att träffa dom igen, visa vad vi varit med om och lämna över några presenter. London bra, men hemam bäst. Fler intryck från resan lär beskrivas här de närmaste dagarna,

London 2011 from Daniel Croona on Vimeo.

10 fantastiska år

Idag drar vi till London, jag och min underbara hustru Cathrine. Det är 10 år sedan vi lovade varandra kärlek och trohet – ett löfte som jag inte tror någon av oss behövt ifrågasätta under den här korta tiden. För snabbt har det gått, med husrenovering, två underbara barn och ett eget företag som även det kräver en hel del uppmärksamhet.

Därför ska det bli skönt att komma iväg tillsammans några dagar, och bara göra allt eller inget – det som faller oss in helt enkelt. Underbart härligt!

Det måste vara ett tecken på något vis att man får se en video idag som visar en kille som friat på exakt samma vis som jag gjorde för drygt 10 år sedan… eller borde gjort om jag hade haft grym fantasi.

Cathrine, jag älskar dig!