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 🙂