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.

 

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *