Kategorien
Technologie

GitLab: Das eigene GitHub (bzw. Bitbucket)

Vor gerau­mer Zeit blogg­te ich hier schon mal über Git­Hub, einem sozia­len Netz­werk für Code. Viel Zeit ist seit­dem ver­stri­chen, ande­re Anbie­ter haben sich ange­schickt, auf der glei­chen Wel­le mit­zu­schwim­men. Ein sozia­les Netz­werk aus einer Code-Platt­form zu machen hat aber bis­her wirk­lich nur Git­Hub geschafft. Als Alter­na­ti­ve mit Sitz außer­halb der USA wäre viel­leicht noch die aus­tra­li­sche Fir­ma Atlas­si­an mit ihrem Ser­vice Bit­bu­cket zu erwäh­nen.
Zurück zu Git­Lab: Git­Lab ist eine Open-Source-Alter­na­ti­ve zu u.a. den bei­den erwähn­ten Ser­vices. Die Anwen­dung ist in Ruby on Rails geschrie­ben wor­den und ist mitt­ler­wei­le ähn­lich kom­for­ta­bel wie Git­Hub. Auf­grund der Spio­na­ge- und Daten­schutz­dis­kus­sio­nen möch­te man sei­ne Daten viel­leicht nicht mehr unbe­dingt in den USA lie­gen las­sen. Hier bie­tet sich Git­Lab als kom­for­ta­ble und aus­ge­reif­te Alter­na­ti­ve zum Selbst-Hos­ting an. Git­Lab besteht aus einem GUI (für den Brow­ser) und natür­lich einem Git-Ser­ver im Hin­ter­grund. Über das Web-Inter­face wer­den Pro­jek­te und Benut­zer ange­legt sowie indi­vi­du­el­le Rech­te ver­ge­ben. Wer möch­te, kann auch noch einen CI (Con­ti­nuous Integration)-Server anbin­den. Der­zeit ver­öf­fent­licht das Pro­jekt im Monats­rhyth­mus Updates, der der­zei­ti­ge Ver­si­ons­stand ist 6.0. Mit jeder Major-Ver­si­on hat das Pro­jekt bis­her gro­ße Schrit­te gemacht.
Suchen Sie nach einem kom­for­ta­blen Git-basier­ten Ent­wick­lungs­ser­ver für Ihr Unter­neh­men oder Ihre Abtei­lung? Spre­chen Sie mich an!

Kategorien
Technologie

Cloud-Deployment von Webanwendungen auf Basis von PHP

Vor einer gan­zen Wei­le berich­te­te ich über den PaaS-Anbie­ter Hero­ku, der sein Port­fo­lio an Pro­gram­mier­spra­chen mitt­ler­wei­le deut­lich erwei­tert hat. Bis vor nicht all­zu lan­ger Zeit fehl­te aber noch ein ver­gleich­ba­rer Anbie­ter für das Deploy­ment von PHP-Anwen­dun­gen. Ver­wun­der­lich gera­de des­we­gen, weil PHP nach wie vor zu den belieb­tes­ten Pro­gram­mier­spra­chen im welt­wei­ten Netz gehört und eini­ge sehr bekann­te Sys­te­me in PHP ent­wi­ckelt wur­den.

Die­se Lücke füllt nun der Anbie­ter PHP Fog, wel­cher, genau wie Hero­ku auf das Deploy­ment von Anwen­dun­gen über das Ver­sio­nie­rungs­tool Git setzt. Das ver­spricht eine äußerst ein­fa­che Hand­ha­bung und ist deut­lich zeit­ge­mä­ßer als das sonst übli­che Deploy­ment über FTP. Allein schon in Sachen Geschwin­dig­keit steckt Git die Daten­über­tra­gung via FTP locker in die Tasche. Vor eini­ger Zeit mel­de­te ich mich dann bei PHP Fog an und begann, ein wenig zu expe­ri­men­tie­ren. Vor­bild­lich ist, dass man gän­gi­ge PHP-Anwen­dun­gen per One-Click-Instal­ler instal­lie­ren kann. Dazu gehört unter ande­rem auch das äußerst belieb­te CMS Wor­d­Press. In der Anfangs­pha­se aber war eine bei PHP Fog abge­leg­te Wor­d­Press-Instal­la­ti­on aber nahe­zu unbrauch­bar, da man kei­ne beschreib­ba­ren Ver­zeich­nis­se ein­rich­ten konn­te und somit vie­le Funk­tio­nen von Wor­d­Press nicht nutz­bar waren. Updates schei­ter­ten, die Instal­la­ti­on von Plugins oder der Upload von Datei­en war unmög­lich. Der ein­zi­ge Aus­weg war, die Wor­d­Press-Instal­la­ti­on lokal zu war­ten und die Ände­run­gen per Git zu deploy­en. Pro­ble­ma­tisch war aber natür­lich hier, dass Ein­trä­ge in der loka­len Daten­bank nicht auf der Infra­struk­tur von PHP Fog lan­de­ten. Die Anfangs­pha­se war kurz­um ziem­lich ent­täu­schend. Stän­di­ge Down­ti­mes und ein erfolg­rei­cher, groß ange­leg­ter Hacker­an­griff trüb­ten den Erstein­druck wei­ter. Mitt­ler­wei­le ist der Ser­vice deut­lich gereift und die oben genann­ten Kri­tik­punk­te sind alle­samt eli­mi­niert wor­den. Den­noch reicht der Bedie­nungs­kom­fort lei­der nach wie vor nicht an den von Hero­ku ran. Loka­le Ände­run­gen an The­me-Datei­en bspw. kann man lei­der nicht zurück auf den eige­nen Rech­ner bekom­men, da die Ver­sio­nie­rung nur in eine Rich­tung funk­tio­niert. Glei­ches gilt für hoch­ge­la­de­ne Datei­en, bei­spiels­wei­se Fotos. Die­se nach­träg­lich auf den eige­nen Rech­ner zu bekom­men, bspw. um einen Anbie­ter­wech­sel durch­zu­füh­ren ist nicht mög­lich, wenigs­tens nicht ohne Umwe­ge über Wor­d­Press-Plugins, die das erlau­ben. Die­ser Nach­teil exis­tiert natür­lich auch bei Hero­ku, nur bringt jede Rails-basier­te Anwen­dung einen inte­grier­ten Web­ser­ver mit und ver­fügt im Regel­fall über meh­re­re Daten­ban­ken (Pro­duc­tion, Deve­lo­p­ment, Test), sodass man Ände­run­gen an der Anwen­dungs­struk­tur ohne Pro­ble­me lokal vor­neh­men und auch gleich tes­ten kann. Die Schuld ist hier also nicht bei PHP Fog zu suchen, son­dern viel­mehr bei der Struk­tur von PHP-Anwen­dun­gen. Ohne eine loka­le Instal­la­ti­on eines Web­ser­vers und einer MyS­QL-Daten­bank ist eine sol­che Arbeits­wei­se nicht mög­lich. In Sachen Sim­pli­zi­tät schlägt Rails hier PHP ganz bequem. Die Idee, das Deploy­ment von PHP-Anwen­dun­gen über das effi­zi­en­te und ein­fach zu bedie­nen­de Git vor­zu­neh­men ist gut, lei­der schei­tert die Benutz­bar­keit in der Pra­xis an dem doch recht ange­staub­ten Kon­zept von PHP-Anwen­dun­gen. Hero­ku ver­bie­tet das Schrei­ben in das Datei­sys­tem des Anbie­ters ein­fach, um genau sol­chen Pro­ble­men vor­zu­beu­gen. Rails-Anwen­dun­gen spie­len da im Regel­fall auch pro­blem­frei mit, und man bin­det Sto­rage über Ser­vices wie Ama­zons S3 an. Bei PHP Fog ist das Schrei­ben ins Datei­sys­tem (lei­der) ohne wei­te­res mög­lich. Dor­ti­ge Ände­run­gen las­sen sich aber nicht reflek­tie­ren. Mei­ne Idee wäre, dass man im Backend von PHP Fog einen But­ton fin­den soll­te, der auf der ent­fern­ten Maschi­ne eine git add .; git com­mit ‑am ‘Kom­men­tar’ aus­führt und man dann mit­tels git pull die Ände­run­gen auf sei­ne eige­ne Maschi­ne bekommt. Ich wer­de wohl mal ein Sup­port-Ticket ein­rei­chen …

Kategorien
Linux Uncategorized

Drei PPAs für den modernen Mann

Um die Vor­tei­le eines LTS-Release von Ubun­tu (aktu­ell 10.04.2) wei­ter­hin genie­ßen zu kön­nen, ohne auf aktu­el­le Soft­ware ver­zich­ten zu müs­sen, gibt es unter Ubun­tu die so genann­ten PPAs, Per­so­nal Packa­ge Archi­ves. Das sind sepa­ra­te Repo­si­to­rys, mit denen man sein Ubun­tu füt­tern kann um Pake­te über die Paket­ver­wal­tung zu instal­lie­ren, die aus irgend­ei­nem Grun­de noch kei­nen Weg in die offi­zi­el­len Repo­si­to­rys der Dis­tri­bu­ti­on gefun­den haben. Cano­ni­cal ver­folgt die Phi­lo­so­phie, inner­halb eines Release kei­ne Ver­si­ons­sprün­ge der ursprüng­lich aus­ge­lie­fer­ten Soft­ware mit­zu­ma­chen. Was sehr scha­de ist, hängt man doch so auf Post­greS­QL 8.4, Git 1.7 und Nginx 0.7 fest. Dank eini­ger fleis­si­ger Paket­schnü­rer gibt es aber PPAs, die genau die­se Pro­ble­me behe­ben. Da ich alle drei zuvor genann­ten Anwendungen/Dienste regel­mä­ßig und auf ver­schie­de­nen Ser­vern nut­ze, habe ich mir dafür ent­spre­chen­de PPAs raus­ge­sucht.

Um PPAs zum Sys­tem hin­zu­zu­fü­gen, bie­tet sich das Kom­man­do add-apt-repository an. Soll­te das Kom­man­do nicht gefun­den wer­den kön­nen, leis­tet fol­gen­der Befehl Abhil­fe:

sudo aptitude install python-software-properties

Die­ses Kom­man­do fügt das Repo­si­to­ry zur Apt-Sources-Lis­te hin­zu und impor­tiert gleich den pas­sen­den GPG-Schlüs­sel.

Fügen wir nun nach­ein­an­der die drei zuvor erwähn­ten PPAs hin­zu:

sudo add-apt-repository ppa:nginx/stablesudo add-apt-repository ppa:git-core/ppasudo add-apt-repository ppa:pitti/postgresql

Ein abschlie­ßen­des sudo aptitude update nicht ver­ges­sen und schon sind die aktu­el­len Ver­sio­nen von Nginx, Git und Post­greS­QL via apt/aptitude ver­füg­bar.

Kategorien
Uncategorized

Heroku: Rails-Anwendungen in der Cloud

Die Cloud, das Buz­z­word des letz­ten Jah­res, ist in aller Mun­de. Und hat auch schon ers­te Federn las­sen müs­sen. Was die Cloud eigent­lich kenn­zeich­net, ist nahe­zu gren­zen­lo­se Ska­lier­bar­keit. Wenn es nach den Befür­wor­tern der Cloud geht, bucht nie­mand mehr phy­si­ka­li­sche Maschi­nen, son­dern Spei­cher­platz, RAM, Rechen­leis­tung in dem Umfang, den er benö­tigt. Wird zwi­schen­zeit­lich mal mehr gebraucht, dreht man kurz an der ent­spre­chen­den Schrau­be und zahlt eben für die Zeit ein wenig mehr. Es gibt unheim­lich vie­le Anbie­ter, gera­de Ama­zon, eigent­lich Inter­net­ein­zel­händ­ler, hat in die­sem Bereich von sich reden gemacht. Ama­zon bie­tet alles denk­ba­re an Cloud-Dienst­leis­tun­gen an, was man sich nur so vor­stel­len kann. Genau das ist dem Wiki­leaks-Pro­jekt zum Ver­häng­nis gewor­den, weil der Anbie­ter somit auch am ein­zi­gen Hebel sitzt. Legt er den um, ist Fei­er­abend. Ama­zon bie­tet zwar eine recht gro­ße Pro­dukt­pa­let­te an, alles abde­cken tun sie dann aber auch nicht.

Wer bei­spiels­wei­se Rails-Anwen­dun­gen in der Cloud lau­fen las­sen möch­te, ist auf ande­re Dienst­leis­ter ange­wie­sen. In den letz­ten Jah­ren hat sich ein Anbie­ter namens Hero­ku einen Namen in der Com­mu­ni­ty gemacht. Erst kürz­lich wur­de Hero­ku von salesforce.com, einem gro­ßen Anbie­ter von Geschäfts­an­wen­dun­gen, für rund 212 Mio. US-$ auf­ge­kauft.

Hero­ku hat ein für den Ent­wick­ler sehr effi­zi­ent zu nut­zen­des und ein­fa­ches Deploy­ment-Ver­fah­ren ent­wi­ckelt, wel­ches kom­plett Git- und Rake-gestützt ist. Der Rails-Ent­wick­ler muss sich also nicht mit der Admi­nis­tra­ti­on und Kon­fi­gu­ra­ti­on von Web­ser­vern her­um­är­gern. Ein Vor­teil gegen­über den klas­si­schen Rails-Hos­tern, von denen es ohne­hin rela­tiv weni­ge gibt ist, dass man nicht auf die vom Hos­ter instal­lier­ten Ruby-Gem-Ver­sio­nen ange­wie­sen ist, son­dern sei­ne eige­nen Ver­sio­nen spe­zi­fi­zie­ren kann, wie man es von sei­ner Ent­wick­lungs­ma­schi­ne her kennt.

Wer rei­ne Rails-3-Anwen­dun­gen deploy­en möch­te, hat sei­ne Anwen­dung bin­nen weni­ger Minu­ten online:

sudo gem install herokugit initheroku creategit add .git commit -a -m 'first deployment commit to Heroku'git push heroku masterheroku rake db:migrateheroku open

Das war es schon. Die Anwen­dung soll­te online sein und sich im Brow­ser geöff­net haben.

Bei Rails-2-Anwen­dun­gen gestal­tet sich das Deploy­ment etwas schwie­ri­ger, aber auch nicht viel. Bevor man die oben erwähn­te Befehls­ket­te anschub­sen kann, muss erst ein­mal eine Datei namens .gems erstellt wer­den. In die­ser müs­sen dann alle erfor­der­li­chen Gems, ggf. inklu­si­ve Ver­si­ons­num­mer notiert wer­den. Bei­spiel:

rails --version 2.3.5i18n --version 0.4.2rack --version 1.0.1

Erst dann darf deploy­ed wer­den. Neben den oben erwähn­ten Mög­lich­kei­ten gibt es aber noch vie­le wei­te­re, die alle­samt auf den wirk­lich tol­len Sup­port- und Doku­men­ta­ti­ons-Sei­ten von Hero­ku doku­men­tiert sind. So kann man, sofern man bereits lokal Post­greS­QL ver­wen­det, sei­nen kom­plet­ten Daten­bank­in­halt mit­tels hero­ku db:push in die Anwen­dung bei Hero­ku pushen. Post­greS­QL ist übri­gens die ein­zi­ge Daten­bank, die von Hero­ku ange­bo­ten wird. Laut Hero­ku des­we­gen, weil sie dort die opti­ma­le Kom­bi­na­ti­on zwi­schen Zuver­läs­sig­keit, Daten­in­te­gri­tät und Geschwin­dig­keit sehen. Ein State­ment, das ich durch­aus unter­schrei­ben kann. Das hero­ku-Gem ist äußerst mäch­tig und bie­tet einem Zugriff auf sämt­li­che instal­lier­ba­re Add-Ons (s.u.), auf die Logs und noch vie­les mehr. Eine Stu­die der Doku­men­ta­ti­on ist emp­feh­lens­wert.

Ab sofort kann dann direkt in den Anwen­dungs­con­tai­ner bei Hero­ku deploy­ed wer­den, indem man ein ganz regu­lä­res Git-Com­mit erstellt. Ein­fa­cher geht es kaum noch.

Nach­dem die ers­te Ver­si­on der Anwen­dung deploy­ed wur­de, kann man sie um eini­ge tol­le, teil­wei­se auch kos­ten­los nutz­ba­re Add-Ons erwei­tern. Dazu gehö­ren nütz­li­che Erwei­te­run­gen wie CNA­ME-Ein­trä­ge für die Anwen­dung (damit man sie auch unter einer eige­nen (Sub-)Domain betrei­ben kann), Jasondb, Mon­goDB und CouchDB für die NoS­QL-Anhän­ger unter uns, Excep­ti­on-Tra­cker, Echt­zeit­su­che, New Relic, SMS-Gate­ways, auto­ma­ti­sier­te Daten­bank­back­ups, etc. Man­che kos­ten gar nichts, man­che nur wenig Geld, ande­re wie­der­um sind recht teu­er (wobei teu­er mal wie­der rela­tiv ist). Dol­le ins Geld geht ein SSL-Zer­ti­fi­kat, da sol­che Zer­ti­fi­ka­te wei­ter­hin IP-basiert sind, was bei einem Cloud-basier­ten Dienst natür­lich recht fins­ter wer­den kann.

Apro­pos Kos­ten: jeder kann bei Hero­ku belie­big vie­le Anwen­dun­gen hos­ten las­sen, die auch erst mal nichts kos­ten, in der Leis­tungs­fä­hig­keit aber arg ein­ge­schränkt sind. Benö­tigt man mehr Res­sour­cen, muss man in die Tasche grei­fen, ab ca. 36 US-$ (0,05 $-Cent pro Stun­de) monat­lich geht es los. Dabei unter­teilt Hero­ku in Dynos und Worker. Dynos beschleu­ni­gen das Front­end, Worker die Hin­ter­grund­pro­zes­se der Rails-Anwen­dung. Der Maxi­mal­aus­bau liegt bei 24 Dynos und 24 Workern, wofür dann aber auch 2,35 US-$ pro Stun­de, oder umge­rech­net rund 1.700 US-$ monat­lich anfal­len. Die Per­for­mance­stu­fe dürf­te aber auch „geho­be­nen“ Ansprü­chen genü­gen.

Damit ist aber noch nicht Schluss, denn eine dedi­zier­te Daten­bank ist bei dem Preis noch nicht inklu­si­ve. Kos­ten­los gibt es 5 MB Shared Data­ba­se, für 20 US-$ monat­lich 20 GB Shared Data­ba­se. Wer gern eine dedi­zier­te Daten­bank hät­te, muss bspw. für den kleins­ten Tarif Ronin 200 US-$ monat­lich berap­pen. Dafür erhält er 16 gleich­zei­ti­ge Ver­bin­dun­gen, 1,7 GB RAM und 1 com­pu­ting unit. Für 6.400 US-$ gibt es 400 Ver­bin­dun­gen, 68 GB RAM und 26 com­pu­ting units. Wer’s braucht…

Hero­kus Datei­sys­tem ist read-only, Dateiu­ploads las­sen sich also nicht rea­li­sie­ren. Hier­zu kann/sollte man, auch laut Hero­ku-Doku­men­ta­ti­on, auf Anbie­ter wie Ama­zon S3 aus­wei­chen. Für Rails-Anwen­dun­gen gibt es diver­se Mög­lich­kei­ten, Uploads zu Ama­zons S3 (Simp­le Sto­rage Ser­vice) aus der Anwen­dung her­aus zu rea­li­sie­ren. Nament­lich erwähnt wer­den Attach­ment-Fu und Paper­clip. Eine per­sön­li­che Prä­fe­renz kann ich hier abge­ben, ich hab mit bei­den noch nicht gear­bei­tet. Hero­ku emp­fiehlt im Übri­gen gene­rell, gro­ße Datei­en, die die Appli­ka­ti­on zum Down­load bereit­stel­len soll, aus Per­for­mance­grün­den zu S3 oder ähn­li­chen Ser­vices aus­zu­la­gern, weil das Datei­sys­tem von Hero­ku nicht für der­ar­ti­ge Anwen­dungs­zwe­cke kon­zi­piert und opti­miert wur­de.

Um die Per­for­mance­un­ter­schie­de mes­sen zu kön­nen, habe ich eine Instal­la­ti­on von Red­mi­ne bei Hero­ku vor­ge­nom­men. Das Deploy­en die­ser Anwen­dung ist lei­der nicht total tri­vi­al, die ein­zel­nen Schrit­te habe ich des­we­gen in einem Gist (wel­cher auch noch mal ganz unten ein­ge­bet­tet ist) nie­der­ge­schrie­ben.

Zum Ergeb­nis mei­ner Bench­marks, gemes­sen auf einer Pro­jekt­über­sichts­sei­te mit ab -c 50 -n 200:

  1. 1 Dyno (kos­ten­los): 7,98 Requests pro Sekun­de
  2. 2 Dynos: 13,15 Requests pro Sekun­de
  3. 3 Dynos: 18,46 Requests pro Sekun­de
  4. 10 Dynos: 53,46 Requests pro Sekun­de
  5. 24 Dynos: 84,14 Requests pro Sekun­de
  6. 1 Worker: 7,64 Requests pro Sekun­de
  7. 2 Worker: 7,74 Requests pro Sekun­de

Die Anzahl der Worker wirkt sich also in kei­ner Wei­se auf die Anwen­dungs­per­for­mance aus, die Anzahl der Dynos hin­ge­gen beträcht­lich. Den größ­ten Gewinn (pro­zen­tu­al gese­hen) bekommt man hier, wenn man von dem einen kos­ten­lo­sen Dyno auf einen zwei­ten, kos­ten­pflich­ti­gen auf­rüs­tet. Die monat­li­chen Kos­ten lie­gen mit die­sem bei rund 36 US-$, also umge­rech­net in etwa 27 €. Eigent­lich nicht zu viel ver­langt, man darf nur nicht ver­ges­sen, dass in die­sem Preis noch kein Sto­rage und nur 5 MB an Daten­bank­platz inklu­si­ve ist.

Zum Ver­gleich: mein nicht opti­mier­ter Root-Ser­ver (Athlon64 X2 6.400+, 4 GB RAM, OpenVZ) lie­fert rund 10,5
R
equests pro Sekun­de. Den muss ich natür­lich selbst admi­nis­trie­ren, war­ten, etc. Und das Deploy­ment ist auch längst nicht so bequem bzw. müss­te erst mal von mir auf die­sen Bequem­lich­keits­le­vel gebracht wer­den.

Hero­ku bie­tet für einen akzep­ta­blen Preis einen wirk­lich tol­len und per­for­man­ten sowie äußerst fle­xi­blen Ser­vice an. Für den Rails-Ent­wick­ler, der kei­ne Lust hat, sich mit der Ein­rich­tung und Admi­nis­tra­ti­on eines Rails-fähi­gen Web­ser­vers rum­zu­schla­gen und ggf. auf­tre­ten­de Pro­ble­me zu behe­ben ist Hero­ku aus mei­ner Sicht opti­mal. Zumal man hier nicht gleich einen zwei­ten Ser­ver hin­zu kau­fen muss, nur weil die Anwen­dung an ein oder zwei Stun­den am Tag mal mehr Res­sour­cen braucht, als es die eige­ne Hard­ware zulässt. Die Anmel­dung kos­tet nichts und das Deploy­en der eige­nen (oder frem­den) Anwen­dung genau so wenig. Einem Ver­such steht also nichts im Wege. Viel Spaß dabei.

https://gist.github.com/779866

Kategorien
Uncategorized

Kaleidoscope 1.1 führt Changesets ein

Sieht wirk­lich nütz­lich aus. Wer die App noch nicht kennt, soll­te sie sich schnellst­mög­lich run­ter laden und sei­nen Mac damit füt­tern.

[vimeo 17363481 w=400 h=300]<p>Kalei­do­scope Chan­ge­set Inter­face from Sofa on Vimeo.</p>

Kategorien
Uncategorized

GitHub — ein Social Network für Code

500px-git-logo

Wer kennt Git nicht? Hand hoch. Nie­mand? Gut…

Git ist ein ver­teil­tes Ver­sio­nie­rungs­sys­tem. Vie­le von euch ken­nen viel­leicht Sub­ver­si­on, kurz SVN, was schein­bar noch immer als eine Art Syn­onym für der­ar­ti­ge Sys­te­me im Netz zu gel­ten scheint. Dabei bie­tet Git so vie­le Vor­tei­le gegen­über bspw. Sub­ver­si­on. Git ist näm­lich, im Gegen­satz zu SVN, ein ver­teil­tes Sys­tem. Man benö­tigt also nicht zwin­gend einen Ser­ver und kann auch sei­nen eige­nen Code auf sei­ner eige­nen Fest­plat­te ver­sio­nie­ren. Also selbst wenn ihr Soft­ware im Allein­gang ent­wi­ckelt, braucht ihr nicht auf die zahl­rei­chen Vor­tei­le eines Ver­sio­nie­rungs­sys­tems zu ver­zich­ten. Ach ja, Git ist übri­gens eine Erfin­dung von Linus Tor­valds, dem Begrün­der der Linux-Bewe­gung. Die Geschich­te von Git kann man im Wiki­pe­dia-Arti­kel zum The­ma nach­le­sen.

War­um man Ver­sio­nie­rung nut­zen soll­te? Der Grund ist recht sim­pel: ihr schreibt Code, oder Text, egal, wel­cher Art. Nach eini­gen Stun­den stellt ihr fest, dass die letz­ten Ände­run­gen voll­kom­me­ner Blöd­sinn gewe­sen sind. Die Rück­nah­me der Ände­run­gen wird aber ver­mut­lich ein Weil­chen dau­ern. Viel­leicht sogar län­ger als es gedau­ert hat, die­se Ände­run­gen zu imple­men­tie­ren. Und wer hat schon Lust, nach jeder Ände­rung per Hand eine Sicher­heits­ko­pie der alten Datei anzu­le­gen? Hät­tet ihr ein Sys­tem zur Ver­sio­nie­rung ver­wen­det, wür­de die Rück­nah­me der Ände­run­gen hin­ge­gen nur weni­ge Sekun­den dau­ern. Die Ein­ga­be des Befehls

git log

gibt eure letz­ten Com­mits aus. Jeder die­ser Com­mits hat einen SHA1-Hash als Iden­ti­fi­ka­tor, von dem man nur die ers­ten weni­gen Stel­len braucht. Bei­spiel­haft:

git checkout 67g4

wür­de die Revi­si­on eurer Daten wie­der­her­stel­len, deren SHA1-Hash mit 67g4 beginnt, ohne dabei neue­re Ver­sio­nen anzu­fas­sen. Git hält also immer meh­re­re, näm­lich alle, eurer erstell­ten Revi­sio­nen vor. Die­ser Arti­kel soll aber kei­ne Git-Bedie­nungs­an­lei­tung wer­den, von denen gibt’s genug im Web, zum Bei­spiel hier. Nein, ich möch­te viel­mehr den wirk­lich genia­len Git-Hostingser­vice Git­Hub vor­stel­len.

500px-github

Das Unter­neh­men hin­ter Git­Hub wur­de im Febru­ar 2008 gegrün­det und seit­dem erfreut sich die­ser Ser­vice einer immer grö­ßer wer­den­den Beliebt­heit. Ins­be­son­de­re die Tat­sa­che, dass Git­Hub für Open-Source-Pro­jek­te kos­ten­freie Accounts anbie­tet, hat dem Unter­neh­men einen gro­ßen Popu­la­ri­täts­schub ver­schafft. Vie­le äußerst popu­lä­re Open-Source-Pro­jek­te wie Perl, Ruby on Rails, PHP, jQue­ry und JUnit sind mitt­ler­wei­le zu Git und auch zu Git­Hub gewech­selt.

Und das aus gutem Grun­de. Git­Hub bie­tet eine Funk­ti­ons­viel­falt, die ihres­glei­chen sucht. Vie­le Fea­tures erschlie­ßen sich dem Benut­zer erst nach einer Wei­le, aber dann möch­te man sie nicht mehr mis­sen. So las­sen sich bspw. gra­fisch die Akti­vi­tä­ten der ein­zel­nen Ent­wick­ler dar­stel­len, die am jewei­li­gen Pro­jekt teil­neh­men. Sehr iPad- und iPho­ne-freund­lich ist der Groß­teil die­ser Gra­phen mitt­ler­wei­le nicht mehr als Flash‑, son­dern als Can­vas-Ele­ment ver­füg­bar. Eben­falls her­vor­zu­he­ben ist die Viel­falt der ver­füg­ba­ren Com­mit-Hooks. Dabei han­delt es sich um klei­ne Pro­gram­me, die eine bestimm­te Akti­on bspw. nach einem erfolg­ten Com­mit durch­füh­ren kön­nen. Ich habe die­se Hooks auf mei­nem eige­nen Ser­ver haupt­säch­lich dazu benutzt, alle betei­lig­ten Ent­wick­ler über neue Com­mits zu infor­mie­ren. Git­Hub bie­tet über die E‑Mail-Benach­rich­ti­gung hin­aus noch vie­le wei­te­re nütz­li­che Hooks an, wie bspw. einen Ser­vice-Hook, der den Com­mit an einen Base­camp-, Camp­fire- oder Light­house-Account über­mit­telt. Git­Hub befin­det sich kon­ti­nu­ier­lich im Aus­bau und man kann regel­recht zuse­hen, wie die Ent­wick­ler die Platt­form wei­ter aus­bau­en. Das Blog von Git­Hub ist in die­sem Zusam­men­hang eben­falls sehr lesens­wert. Die Trans­pa­renz die­ses Unter­neh­mens gegen­über ihren Kun­den fin­de ich bei­spiel­haft.

The_jquery_network_-_github

Seit rund zwei Wochen ist Git­Hub auch in deut­scher Spra­che ver­füg­bar. Der Groß­teil der über­setz­ten Tex­te stammt im Übri­gen aus mei­ner Feder, da ich mich gemel­det habe, als Git­Hub per Twit­ter einen Auf­ruf star­te­te, und nach Frei­wil­li­gen für die Über­set­zung gesucht hat. Wer mich kennt, weiß, dass ich dafür ein Fai­ble hab. Die Arbeit hat Spaß gemacht, auch wenn eini­ge der Co-Über­set­zer wenig Ahnung von der deut­schen Orto­gra­phie haben. Das sorg­te dafür, dass ich qua­si alle Tex­te noch mal über­ar­bei­ten muss­te. Aber Ende gut, alles gut, die Über­set­zung ist online. Noch ist nicht die kom­plet­te Web­site über­setzt, aber wie ich vom Koor­di­na­tor Scott Cha­con, der im Übri­gen eine Kory­phäe im Git-Bereich ist, erfah­ren habe, folgt die rest­li­che Web­site im Ver­lau­fe der Zeit. Ich gehe eigent­lich davon aus, dass Soft­ware­ent­wick­ler im All­ge­mei­nen über über­durch­schnitt­lich gute Eng­lisch-Kennt­nis­se ver­fü­gen, für die­je­ni­gen aber, denen es nicht so geht, ist nun auch die­se Hür­de genom­men.

Zu Beginn des Arti­kels pre­dig­te ich noch die Vor­tei­le, die eine dezen­tra­le Lösung hat und nun wer­be ich für einen Ser­vice, der doch wie­der alles zen­tra­li­siert? Fehl­an­zei­ge. Git ist und bleibt dezen­tral. Loka­le Com­mits müsst ihr erst dann zum Ser­ver schi­cken (der sog. Push), wenn ihr euren Code ande­ren Ent­wick­lern zur Ver­fü­gung stel­len wollt. Sämt­li­che Com­mits lie­gen also sowohl bei allen betei­lig­ten Ent­wick­lern, als auch auf dem Ser­ver, was eine Situa­ti­on schafft, die an Aus­fall­si­cher­heit nicht mehr zu über­bie­ten ist.

Auch wenn die Funk­ti­on an sich ein alter Hut ist, Git­Hub bie­tet ein Pas­te­bin an. Aber nicht irgend­ein Pas­te­bin, son­dern eines, das auch ver­sio­niert, also mit Git im Hin­ter­grund läuft. Die­se Funk­ti­on nennt sich Gist und funk­tio­niert so, wie man es von ande­ren Pas­te­bins gewohnt ist, nur eben mit Ver­sio­nie­rung. Eine tol­le Idee, ich nut­ze die Gists recht häu­fig um bei­spiels­wei­se häu­fig genutz­ten Code immer griff­be­reit zu haben.

Mein Rat: schaut euch sowohl Git, als auch Git­Hub gut an, wenn ihr pro­gram­miert, Web­sei­ten baut, Doku­men­ta­tio­nen schreibt oder ander­wei­tig mit kom­ple­xen Daten­be­stän­den zu tun habt. Wie ich vor einer Wei­le schon beschrie­ben habe, könnt ihr auch einen eige­nen Git-Ser­ver mit jedem han­dels­üb­li­chen Linux auf­set­zen, der War­tungs­auf­wand liegt dann aber auf eurer Sei­te. Pro­gram­miert ihr gera­de an einem Open-Source-Pro­jekt kos­tet euch die
Nut­zung von Git­Hub kei­nen Cent, wollt ihr euren kom­mer­zi­ell aus­ge­rich­te­ten Code able­gen, bekommt ihr einen geschütz­ten Zugang ab 7 US-$ (ca. 5,50 €) monat­lich. Die Tarif-Über­sicht von Git­Hub bie­tet mehr Infor­ma­tio­nen zu den Prei­sen. Typisch für die USA sind die Prei­se etwas höher, als man es von Deutsch­land gewohnt ist, der Ser­vice ist sein Geld aber alle­mal Wert.

Ich lie­be Git­Hub und möch­te auf die­sen tol­len Ser­vice nicht mehr ver­zich­ten. Give it a try, wie der Eng­län­der jetzt sagen wür­de, und ihr wer­det ver­ste­hen, wie­so ich so begeis­tert bin.

Kategorien
Uncategorized

Kaleidoscope — File comparison for Mac

Media_httpwwwkaleidos_oipcc

Ich habe die Anwen­dung soeben mal instal­liert und auf den ers­ten Blick macht sie einen wirk­lich ziem­lich coo­len Ein­druck. Sie inte­griert sich in Git, Text­ma­te und noch vie­le wei­te­re Tools. Auch eine CLI-Unter­stüt­zung ist vor­han­den. Ich wer­de die Anwen­dung wohl mal in Ruhe tes­ten, einen Kauf schlies­se ich aber schon jetzt nicht aus.

Kategorien
Uncategorized

Git: Installation eines eigenen Servers auf Basis von Ubuntu 9.10 (samt Trac)

Lei­der haben sowohl Pos­te­rous als auch Blog­ger mich dazu gezwun­gen, das Doku­ment nur im PDF-For­mat anbie­ten zu kön­nen, da sich bei­de Sys­tem ent­we­der an der Län­ge und/oder den Son­der­zei­chen im Text ver­schluckt haben.

Fra­gen und Kom­men­ta­re bit­te trotz­dem in die Kom­men­ta­re.

Kategorien
Uncategorized

Running trac-git on Ubuntu 9.04 Server

It took me around two hours to figu­re out, why Trac was always thro­wing the fol­lowing error, when laun­ched using tracd:

Warning: Can't synchronize with the repository (Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? ). Look in the Trac log for more information.

The Ubun­tu packa­ge trac-git was per­fect­ly instal­led and see­med to work fine. The real rea­son was that the Ubun­tu packa­ge trac-git depends on python2.6, which obvious­ly does­n’t work with trac-git.

So I did an

aptitude install python2.5 && rm /usr/bin/python && ln -s /usr/bin/python2.5 /usr/bin/python

which did the trick. After that, tracd was able to use the trac plugin for Git.

If it still does­n’t work make sure that you have at least the fol­lowing lines in your project’s trac.ini:

[components] # for plugin version 0.10 gitplugin.* = enabled  # for plugin version 0.11.0.1+ tracext.git.* = enabled  [git] cached_repository = true git_bin = /usr/bin/git persistent_cache = true shortrev_len = 7  [trac] repository_dir = /path/to/git/repository.git repository_type = git

If ever­ything abo­ve is set a

tracd --port 8000 /var/trac/yourpath

should start tracd and make it avail­ab­le via port 8000 on your machi­ne.