Administrator's Blog

Eine Versionsverwaltung bestimmt den Alltag in größeren Projekten. Wo bisher SVN oder Merurical herhalten durfte, hat sich ein neuer Platzhirsch durchgesetzt, der aufgrund seiner Simplizität und Mächtigkeit überzeugt. Viele dürften es erraten haben, es handelt sich um Git.

Es gibt vielerlei Möglichkeiten mit Git eine Versionierung zu erreichen, sei es lokal oder auf github, bitbucket oder anderen Git-Repository Providern. Spätestens wenn es aber um Firmeninterne Projekte geht oder aber um allgemein nicht der Öffentlichkeit zugängliche Projekte muss man meist in die Tasche greifen und den Providern einen kleinen Obolus zahlen, damit diese die privaten Projekte Hosten und mehreren Teammitgleider ggf. Zugriff darauf gewähren.

Kostengünstiger wäre es da einen eigenen Git-Server zu haben, welcher die internen Projekte angemessen verwaltet. Theoretisch ist auch dies schnell von statten gegangen, kann man doch über SSH auf ein zentrales Bare-Repository tunneln und Änderungen pushen und pullen.

Wenn man jedoch auch gleichzeitig eine schöne Übersicht sämtlicher Commits haben möchte, samt Administration für Repoverwaltung, Benutzerverwaltung, etc. dann kommt man nicht umher sich diverse Webinterfaces anzuschauen, die einem diese Arbeit abnehmen können.

Eine begrenzte Auswahl wären die folgenden Verwaltungssysteme:

• http://www.gitalist.com/ (Seit Mai 2012 scheinbar keine Entwicklung mehr?)


• http://www.gitblit.com/ (Basiert auf Java und benötigt entsprechend einen Jetty o.ä.)


• http://www.gitlabhq.com/ (Basiert auf Ruby und hat als Komplementärprojekt auch ein eigenen CI-Server mit Gitlab integration)

Für den Blogeintrag betrachten wir letzteres (Gitlab) genauer.

Gitlab bring viele Funktionen mit, wie man sie auch von öffentlichen Git-Repository Servern wie z.B. GitHub kennt. Man hat eine pro Benutzer Projektverwaltung, ein Wiki, Issuetracker mit Redmine Integrationsmöglichkeiten, einfache Möglichkeiten POST-Hooks bei einem push in das Repo auszulösen und das mitunter beste ist, dass das Gitlab Webinterface fast ausschließlich über die Gitlab eigene API aufbaut. Das bedeutet man kann alles was man im Webinterface klicken kann auch über automatisierte Skripte auslösen, abfragen und verarbeiten.

Die Installation die hier vorgestellt wird, nutzt abseits von dem empfohlenen Weg ein RVM (Ruby Virtual Environment), da man sich nicht unbedingt mit dem Betriebssystem über die installierte Rubyversion oder verschiedener Gems streiten möchte. Jedoch verlangt dies einige nachträgliche Anpassungen, welche aber so minimal gehalten sind, dass diese nicht ins Gewicht fallen. Zudem werden wir statt nginx den Apache2 nutzen um Gitlab auszuliefern. Die Schritte für nginx stehen auch im vorgestellten Skript, sind jedoch auskommentiert. (Es sei darauf hingewiesen das es kein richtiges Bash-Skript ist sondern mehr eine Anleitung was wann zu tun ist).

An den Stellen, wo zum bearbeiten der Konfigurationsdateien ,vim‘ genutzt wird kann der persönlich bevorzugte Editor genutzt werden (emacs, nano, etc.)

Bevor es nun los geht weise ich noch darauf hin, dass wir hier Gitlab @master nutzen, bedeutet die aktuelle Entwickler Version. Dies wird entsprechend so gemacht, da ab der Version 5.0 (Zum Zeitpunkt dieses Posts @master) gitolite durch eine eigene Loginshell ersetzt wird. Da gitolite als Repositoryverwaltung im Zusammenspiel mit Gitlab sehr verbuggt war. Sollte es also irgendwann einmal ein 5-x-stable branch geben so wäre dieser zu bevorzugen. Das kann man enstprechend prüfen, indem man nach dem clone des gitlab repos ,git branch -a‘ aufruft. Sollte da ein remotes/origin/5-x-stable existieren so kann man dies mit ,git checkout 5-x-stable‘ auschecken und fortan nutzen. (x steht für eine beliebige Zahl) Die Loginshell wird nach einem Erfolgreichen authentifizieren gegenüber SSH für den Benutzer git gerufen. Das ganze kann man sich anschauen, wenn man sich die Datei ,/home/git/.ssh/authorized_keys‘ anschaut. Hat man für einen Benutzer einen Key im Frontend importiert, so wird dieser in diese Datei geschrieben (zusammen mit dem command auf die gitlab-shell) und regelt den SSH Zugriff auf das Repository über die git-checkout URL eines Projekts.

Die genutzte Distribution, bei der die folgenden Anweisungen genutzt wurden, ist Debian 6 „Squeeze“. Der Benutzer mit dem installiert wird ist ,root‘ aber keine Angst, Gitlab wird später unter dem Benutzer ,git‘ in das System installiert, für die ersten Schritte wie apt-get ist root jedoch vorrausgesetzt. Der Name des Benutzers sollte nicht verändert werden, da sonst viele der Standard Skripte angepasst werden müssten, da diese ,git‘ als Benutzer für sämtliche ,sudo‘ Befehle hard-coded haben.

Zuerst aktivieren wir das Backports Repository damit wir einen Redis-Server >v2.0 installieren können. Dieser wird benötigt, da Gitlab BRPOP nutzt, welches erst seit v2.0.0 in Redis implementiert ist.

# Enable backports
echo "deb http://backports.debian.org/debian-backports squeeze-backports main" >> /etc/apt/sources.list

# System up-to-date
apt-get update && apt-get dist-upgrade

Als nächstes benötigen wir sudo und einige weitere Pakete um Ruby und dessen Gems entsprechend kompilieren zu können.

># Install all packages we need
apt-get install -y \
sudo \
vim \
build-essential \
checkinstall \
gcc \
make \
automake \
wget \
curl \
openssh-server \
git-core \
mysql-server \
mysql-client \
sqlite3 \
libsqlite3-dev \
zlib1g-dev \
libyaml-dev \
libssl-dev \
libgdbm-dev \
libreadline-dev \
libncurses5-dev \
libffi-dev \
libxml2-dev \
libxslt-dev \
libcurl4-openssl-dev \
libicu-dev \
libxml2-dev \
libxslt-dev \
libcurl4-openssl-dev \
libreadline6-dev \
libc6-dev \
libssl-dev \
libmysql++-dev \
zlib1g-dev \
libyaml-dev \
libpq-dev \
libmysqlclient-dev

# Redis from backports 2.x +
apt-get install -y -t squeeze-backports redis-server

Soll Gitlab auch Mails versenden können (z.B. „Passwort vergessen“-Mails), so wird auch ein postfix benötigt.

# Install Postfix for mail sending (optional)
apt-get install postfix

Als nächstes intallieren wir Python, dies wird von Gitlab auch noch benötigt.

# Install python (2.x preferable, if python --version is 3.x+ use python27)
apt-get install python

# Ensure python2 exists (needed by gitlab)
which python2 || ln -s /usr/bin/python /usr/bin/python2

Als nächstes legen wir die Datenbank an.

# Create Database
mysql -u root -p

CREATE USER 'gitlab'@'localhost' IDENTIFIED BY 'YOUR GITLAB PASSWORD';
CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.** TO 'gitlab'@'localhost';


# Test SQL (need to enter YOUR GITLAB PASSWORD)
mysql -u gitlab -p -D gitlabhq_production

Jetzt wechseln wir auf den Benutzer und installieren Gitlab in dessen HOME-Verzeichnis:

su git
# Set git username and email
git config --global user.name "GitLab"
git config --global user.email "gitlab@localhost"

# Install Ruby RVM with ruby1.9.3
\curl -L https://get.rvm.io | bash -s stable

echo "source /home/git/.rvm/scripts/rvm" >> .bashrc

source /home/git/.rvm/scripts/rvm
source ~/.profile

rvm get head
rvm reload
rvm install 1.9.3
rvm --default use 1.9.3
echo "source /home/git/.rvm/scripts/rvm" >> .bashrc
source /home/git/.rvm/scripts/rvm

# Install bundler
gem install bundler

# Clone & Install GitlabShell
git clone https://github.com/gitlabhq/gitlab-shell.git
cd gitlab-shell
cp config.yml.example config.yml
vim config.yml
./bin/install

# Adjust the shebang for RVM
# Nach einem frischen clone steht da: #!/usr/bin/env ruby
# Das muss geändert werden in: #!/usr/bin/env /home/git/.rvm/bin/ruby
vim bin/gitlab-shell

cd /home/git

# Clone gitlab
git clone https://github.com/gitlabhq/gitlabhq.git gitlab
cd /home/git/gitlab
cp config/gitlab.yml.example config/gitlab.yml
vim config/gitlab.yml

chmod -R u+rwX log/
chmod -R u+rwX tmp/

# Create directory for satellites
mkdir /home/git/gitlab-satellites

# Create temp and make sure its wirtable
mkdir tmp/pids/
chmod -R u+rwX tmp/pids/

# Copy config templates
cp config/unicorn.rb.example config/unicorn.rb
cp config/database.yml.mysql config/database.yml

# Enable TCP instead of socket listening as we use apache
# Use port 46660 on 127.0.0.1 and comment the socket, as we don't need it
# die # vor listen 127.0.0.1:8080 entfernen und 8080 in 46660 ändern.
# eine # vor listen "#{app_dir}/tmp/sockets/gitlab.socket" setzen.
# !Dieser Schritt fällt weg, wenn man Gitlab auf einem nginx laufen lassen möchte, da dieser mit UNIX-Sockets reden kann.
vim config/unicorn.rb

# Configure database
vim config/database.yml

# Setup gitlab dependencies and database
gem install charlock_holmes --version '0.6.9'
bundle install --deployment --without development test postgres

bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:seed_fu RAILS_ENV=production
bundle exec rake gitlab:setup RAILS_ENV=production

# Check configuration
bundle exec rake gitlab:env:info RAILS_ENV=production

exit

Nun haben wir Gitlab erfolgreich auf dem System installiert und müssen dies nur noch starten. Dazu kann man das vom Entwickler bereitgestellte init.d Skript nutzen.

# Install init.d-script and run gitlab's sidekiq and unicorn
curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab
chmod +x /etc/init.d/gitlab
update-rc.d gitlab defaults 21
/etc/init.d/gitlab start

Nun hat man 2 Möglichkeiten, einmal NGinx und einmal Apache2.

NGinx:

# Install nginx and install gitlab site-config
apt-get install nginx
curl --output /etc/nginx/sites-available/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/nginx/gitlab
ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
vim /etc/nginx/sites-available/gitlab
service nginx restart

Apache2:

apt-get install apache2 libapache2-mod-ssl libapache2-mod-proxy-html
vim /etc/apache2/sites-available/git.domain.tld
a2enmod ssl
a2enmod proxy_http
a2ensite git.domain.tld
/etc/init.d/apache2 restart

git.domain.tld-VHost Konfiguration:

# require apache module mod_proxy and mod_proxy_http
<IfModule mod_proxy_http.c>
<VirtualHost :80>
ServerName git.domain.tld
ServerAdmin support@domain.tld

<IfModule mod_ssl.c>
RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
</IfModule>

# Server Gitlab over http as we don't have https/ssl
<IfModule !mod_ssl.c>
ProxyPass / http://127.0.0.1:46660/
ProxyPassReverse / http://127.0.0.1:46660/
ProxyPreserveHost On

# Entsprechend anpassen!
# Deny from all, but allow BasicAuth and skip BasicAuth for 192.168.0.30
# Satisfy Any will make sure that all paths are tested, before deny all will get triggered
<Location />
Order deny,allow
Deny from all

AuthType Basic
AuthName "Git Repository"
Require valid-user
AuthUserFile /etc/apache2/git_auth.passwd

#Allow from 192.168.0.30
Satisfy Any
</Location>

CustomLog /var/log/apache2/gitlab_access.log combined
ErrorLog /var/log/apache2/gitlab_error.log
</IfModule>

</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName git.domain.tld
ServerAdmin support@domain.tld

# Sollte man noch auf seine eigenen Zertifikate anpassen!
SSLEngine On
SSLCertificateFile /etc/ssl/domain/domain.crt
SSLCertificateKeyFile /etc/ssl/domain/domain.key
SSLCACertificateFile /etc/ssl/domain/root.pem

ProxyPass / http://127.0.0.1:46660/
ProxyPassReverse / http://127.0.0.1:46660/
ProxyPreserveHost On
RequestHeader set X-Forwarded-Ssl on

# Entsprechend anpassen!
# Deny from all, but allow BasicAuth and skip BasicAuth for 192.168.0.30
# Satisfy Any will make sure that all paths are tested, before deny all will get triggered
<Location />
Order deny,allow
Deny from all

AuthType Basic
AuthName "Git Repository"
Require valid-user
AuthUserFile /etc/apache2/git_auth.passwd

#Allow from 192.168.0.30
Satisfy Any
</Location>

CustomLog /var/log/apache2/gitlab_access.log combined
ErrorLog /var/log/apache2/gitlab_error.log
</VirtualHost>
</IfModule>
</IfModule>

Danach kann man prüfen ob alles läuft und funktionsfähig ist:

# Check if everything works
su git
cd /home/git/gitlab
bundle exec rake gitlab:check RAILS_ENV=production

Schon hat man seinen eigenen Git-Repository Server am laufen, welcher zudem große Ähnlichkeiten mit Github hat. Viele Entwickler im eigenen Team die schon einmal mit Github gearbeitet haben, werden sich da schnell zurechtfinden.

Der initiale Administratoren Login lautet dann admin@local.host mit dem Passwort: 5iveL!fe

Dieser Benutzer sollte nach dem anlegen des eigenen Admin-Benutzers am besten gelöscht werden.

Bei Fragen oder Kritiken können gern die Kommentare genutzt werden

Synergy ist interessant für jeden der 2 Monitore, 2 Rechner und nur 1 Set an HID`s besitzt.

Man könnte jetzt Maus und Tastatur über ein KVM Hardware Switch ständig zwischen beiden Rechnern hin-und-her wechseln. Jedoch besitzt nicht jeder ein solches Gerät, noch lohnt sich die Anschaffung des selbigen Aufgrund der doch sehr hohen Kosten von USB KVM Switches.

Eine mittlerweile sehr gute Softwarelösung ist Synergy, welches Maus und Tastatur über das Netzwerk mit beiden Rechnern verbindet. Dabei fungiert der Rechner mit angeschlossenen Geräten als Server und der Rechner, welche keine Maus und Tastatur angeschlossen hat als Client.

Dabei hat man die freie Wahl der Plattform, denn Synergy ist Plattformunabhängig. Ein weiterer Vorteil ist die synchronisierte Zwischenablage. Zuletzt sei erwähnt dass man durch die Software Lösung auch gerne schnell vergisst, dass man 2 verschiedene Rechner bedient, denn Synergy schaltet seamless zwischen beiden Systemen um, sobald man den Konfigurierten Randbereich mit der Maus überschreitet.

Konfiguration
Vorab: Ich empfehle euch unbedingt die Beta zu benutzen, da hier die Benutzerschittstelle um einiges ausgereifter ist.
Szenario: Rechner 1 ist ein Windows mit angeschlossenen Gerätschaften, Rechner 2 ist ein OSX Lion der diese Geräte nutzen möchte.

Zuerst installiert man auf beiden Systemen die Software. Dabei wählt man in der Installation für Rechner 1, Server aus und für Rechner 2 wählen wir Client. Die Frage nach dem Automatischen Start kann jeder so beantworten wie er es gerne mag, bei mir starten beide Rechner die Software im "Desktop" Level, bedeutet erst nachdem ich mich angemeldet habe.

Nun kann man auf Seite des Servers entsprechend "Configure Server..." wählen. Nun hat man eine Übersicht aller konfigurierten Rechner (im unkonfigurierten Fall entsprechend ein Monitor in der Mitte mit dem Netzwerknamen des eigenen Rechners).


Nun kann man von oben Rechts einen Monitor, via drag-and-drop an die Position ziehen, die der zweite physische Monitor hat, welcher an den 2. Rechner angeschlossen ist. Dadurch wird ein "Unnamed" Bildschirm erstellt.


Durch einen Doppelklick auf diesen gelangt man entsprechend in den Konfigurationsdialog. Dort gibt man diesem Bildschirm den Netzwerknamen/Hostname des 2. Rechners als "Screen name" an. In meinem Fall ist das "Christophs-MacBook-Pro.local". Jetzt kann man noch diverse "Key-Modifier" umsetzen, was bei OSX z.B. Praktisch ist, da sonst Super(Apfel) und Alt vertauscht sind. Daher mappe ich in meinem Fall "Alt auf Super" und "Super auf Alt". Damit ist auf Seiten des Servers alles fertig konfiguriert. Starten wir nun also den Server über die "Start" Schaltfläche und kümmern wir uns um den Client.

Beim Client muss man nun einfach nur den Namen des Servers eintragen. Dabei kann man den NetBios/DNS Namen oder aber die IP Adresse benutzen. Danach kann man auch hier auf "Start" drücken. Nun sollte bei beiden Rechnern in der Log von Synergy stehen, das eine Verbindung erfolgreich aufgebaut wurde.



Ab jetzt kann man den anderen Rechner von seinem Hauptsystem aus wie einen 2. Bildschirm verwenden. Einfach über den Randbereich hinweg gehen, je nachdem wie man den Monitor eingestellt hat links oder rechts, schon hat man Maus und Tastatur nutzbar auf dem 2. Rechner. Im selben Moment wird dann auch die Zwischenablage synchronisiert. Thats it.

Fazit
Der einzige Nachteil des ganzen ist, dass man den Monitor händisch an den 2. Rechner anschließen muss. Zudem werden auch Audiosignale nicht übertragen. Jedoch ist dies für den Office gebrauch nicht weiter tragisch. Für Audio könnte man die Software Airfoil nehmen, diese ist jedoch entsprechend kostenpflichtig und beim Monitor müsste man zwangsweise einen Hardware KVM Switch für Monitore besitzen.

Vorteil ist die ständige Weiterentwicklung dieses Projekts und dass es Open Source ist. Zudem sind, trotz Beta, während meiner Benutzung keinerlei Fehler aufgetreten. Einzig das Mapping von AltGr auf Command+Alt ist für OSX ziemlich nervig. Ein Patch scheint dafür schon in das Projekt eingeflossen zu sein, jedoch bietet die GUI noch keine Möglichkeit diese Einstellung vorzunehmen.

In aller Munde ist das Versionierungssystem Git, da es unter Anderem von großen Projekten zur Versionsverwaltung genutzt wird. Entwickelt wurde es von Linus Torvalds, da alle anderen Versionierungssystem nicht dynamisch genug für die Kernel Entwicklung waren, vor allem sobald es um das 'mergen' von einzelnen 'branches' ging.

Doch wie funktioniert Git nun eigentlich? Zuerst sei die Architektur von Git erwähnenswert, da diese nicht zentralisiert, sondern eher verteilt ist. Das bedeutet, dass Jeder, der mit einer Kopie eines Git-Clones arbeitet, im Endeffekt das gesamte Repository mit allen Änderungen auf seinem Rechner lokal vorliegen hat. Daraus resultiert auch ein gewaltiger Vorteil von Git z.B. gegenüber SVN oder CVS. Die Verwaltung sämtlicher Änderungen findet komplett Offline im 'working directory' statt. Ist man z.B. gerade im Zug unterwegs, muss man daher nicht auf eine Versionsverwaltung für sein aktuell bearbeitetes Projekt verzichten.

Die Basics sind dabei relativ einfach erlernbar und nach wenigen Nutzungen muss man auch nicht mehr groß darüber nachdenken Anbei eine kleine Einführung:

Zuerst müssen wir die Versionierung für ein Projekt oder genauer für das aktuelle Verzeichnis erstellen:

 git init 

Ab jetzt ist das Verzeichnis bereit, den Inhalt zu versionisieren. Welche Dateien oder Verzeichnisse man nun verwalten möchte, kann man über:

 git add <file|dir> 

festlegen, ziemlich analog zu SVN. Dennoch gibt es einen Unterschied, denn es werden nur die Änderungen zum 'Stage' hinzugefügt, welche bis zu diesem Zeitpunkt gemacht wurden. Bearbeitet man die Datei erneut, so müsste man diese Änderungen auch wieder mit einem 'add' erneut hinzufügen (auch wenn man in der Datei die bereits versionisierten Änderungen gelöscht hat, so muss man diese erneut hinzufügen, damit diese gelöschten Änderungen hinzugefügt werden).

Doch was ist denn eine 'Stage'? Der Stage ist ähnlich wie eine Kiste. In dieser liegen alle Änderungen, die wir über den 'add' Befehl hinzufügen oder über den 'reset' Befehl löschen. Zusätzlich gibt es auch noch eine temporäre Kiste in der man Änderungen zwischenspeichern kann um z.B. externe Patches auf einen Quelltext anzuwenden und dann die eigenen Änderungen wieder anwenden zu lassen. Letzteres geht jedoch für Beginner erstmal zu weit, es sei aber am Rande erwähnt.

Möchte man die 'staged' Änderungen verwerfen, kann man Dies erreichen, indem man folgendes eingibt:

 git reset <file|dir> 

Möchte man die Änderungen nun endgültig versionisieren, so kann man diese nun commiten:

 git commit 

Dabei werden sämtliche Änderungen in das lokale Git-Repository geschrieben.

Was jedoch machen, wenn man dennoch etwas vergessen hat dem aktuellen Commit hinzuzufügen oder aber man noch einen Fehler gefunden hat, der direkt auf den Commit bezogen ist? Git ermöglicht es dem letzten Commit weitere Änderungen anzuhängen. im Jargon nennt man dies entsprechen 'Amend'. Dabei kann auch die Commit-Message umgeschrieben werden.

Hat man also weiter Änderungen über add hinzugefügt, dann kann man diese dem letzten Commit hinzufügen:

 git commit --amend 

Damit hat man - grob - die Basics von Git umrissen.
Im nächstenTeil werde ich noch erklären, warum man immer auf einem Branch arbeiten sollte und die Änderungen entsprechend in den 'master' zurückfließen lassen sollte. In dem Zusammenhang werde ich auch noch erläutern, wie man sein lokales Repository auf github.com hochladen kann um eine 'globale' Version des Repositories zu haben.

Dependency Management ist auch in PHP ein wichtiger Teil der Entwicklung, da man sich vor allem beim Ausrollen der Anwendung sicher sein muss, dass alles auf den - meist stabilen - Versionen läuft, für welche die Anwendung entwickelt wurde.

Hilfreich kann hierbei Composer werden. Das Projekt entspringt zum Teil der Entwicklung von Symfony2, wodurch auch so ziemlich alle Symfony2 Pakete dort gefunden werden können, sofern der Maintainer des Pakets sein Repository entsprechend Composer kompatibel gestaltet. 

Zudem kann der Maintainer entsprechende Abhängigkeiten angeben, welche dann von Composer aufgelöst, heruntergeladen und installiert werden.

Die Nutzung von Composer wird sehr gut auf der Standard Repository Seite Packagist erklärt. Dort kann man dann auch entsprechend nach sämtlichen von Haus aus unterstützen, bzw. verwalteten Paketen suchen und sich deren Abhängigkeiten, etc. anschauen.

Geliefert wird die Composer im .phar Format, wodurch es ggf. nötig ist, die suhosin.ini für php-cli entsprechend anzupassen, falls Suhosin für PHP aktiviert ist (wie z.B. default unter Debian)

suhosin.executor.include.whitelist = phar

Hat man nun alle Einstellungen getätigt und sich seine composer.json erstellt, kann man sich nun die Abhängigkeiten bequem herunterladen via:

php composer.phar update

Dies erstellt zudem eine composer.lock Datei, welche die soeben heruntergeladenen Versionen dokumentiert. Rollt man die Anwendung nach der Entwicklung auf dem Produktivsystem aus, führt man einfach ein:

php composer.phar install

aus.

Dies installiert dann genau die Versionen, welche beim Aufruf von "update" festgesetzt wurden, selbst wenn in der Versionsverwaltung neuere Versionen existieren sollten.

Ein weiterer Vorteil ist die 'autoloader.php' im 'vendor' Verzeichnis, welches von Composer angelegt wird. Diese enthält das PSR-0 kompatible, automatische Laden von unbekannten PHP-Klassen anhand des Klassennamens und aktuellem Namespaces. Fügt man diese Datei in seinem Skript hinzu, kann man die Abhängigkeiten (bzw. deren Klassen) nutzen, ohne 100 Dateien inkludieren zu müssen.

Der initiale Konfigurationsaufwand scheint dabei groß zu sein, jedoch profitiert man umso mehr davon, je mehr Abhängigkeiten die Anwendung hat und je öfter man die Anwendung auf einem Produktivsystem ausrollen möchte.