Archiv Juli, 2011

Im letzten Artikel PhpStorm, Git und ein Remote Webserver ging es um die Einrichtung von PhpStorm + Git und die automatische Synchronisierung des lokalen Projektverzeichnisses mit einem Remote Verzeichnis auf dem Testserver. In diesem Artikel geht es um die Einrichtung eines sehr einfachen Deploymentprozesses den man vom Git Server aus anstoßen kann.

Alle Teile dieser Artikel Serie

Update eines Git Repository auf dem Live Server

Da Git ein dezentrales Versionierungssystem ist, legt man einfache einen Clone auf dem Live Server an. Zum wechseln der Version loggt man sich auf dem Live Server ein und führt ein "git pull" aus. Dabei wird das Repository und im Anschluss die Dateien des Work Tree aktualisiert. Nun muss man sich aber für diesen Ablauf jedes mal mit dem Live Server verbinden, was bei vielen Systemen unhandlich ist.

Git Hooks und wie man das Update damit vereinfachen kann

Git bringt einige nützliche Hooks mit die nach bestimmten Aktionen ausgeführt werden und die man für seine Zwecke nutzen kann. Für das Update von einem Zentralen Ort aus, ist der post-update Hook interessant. Dieser wird nach einem Repository Update von extern (git push) ausgeführt. Damit ist es möglich vom Git Server aus durch ein einfaches git push die Version auf dem Zielserver zu aktualisieren. In meinem Fall richte ich das Live Repository als production ein (git push production). Mit dieser Methode kann man auch weitere Repositories anschließen. Zum Beispiel Staging oder auch mehrere Repositories auf unterschiedlichen Servern mit einem Befehl aktualisieren.

Nun hatte ich in einem vorherigen Artikel das Git FAQ zitiert, das sagt das man nicht in ein Git Repository pushen soll an dem ein Work Tree hängt. In diesem Fall ist dies aber Okay, da der Hook auf die daraus resultierenden Probleme eingeht. Persönlich benutze ich den Hook der im Git FAQ beschrieben wird, aber es gibt weitere die ebenfalls ihre Aufgabe erfüllen.
(mehr …)

Im Artikel Git Repository erstellen und mit den Git Server verbinden, wurde ein lokales Git Repository angelegt, auf den Server kopiert und dann wurden beide verknüpft. In diesem Artikel geht es um die Einrichtung von PhpStorm. Hierbei wird das lokale Git Repository benutzt, dessen Dateien automatisch mit dem Remote Webserver synchronisiert werden sollen um Veränderungen dort testen zu können. Die Einrichtung ist relativ einfach, aber da PhpStorm eine Menge an Einstellungsmöglichkeiten bietet, kann es anfänglich etwas überwältigend sein. Weiß man irgend wann nicht mehr weiter, lohnt sich ein Blick in die Hilfe, die wirklich sehr gut und vor allem vollständig ist. Dort wird soweit mir bekannt auf jede Einstellungsmöglichkeit eingegangen.

Alle Teile dieser Artikel Serie

Neues PhpStorm Projekt erstellen

Als erstes starten wir PhpStorm. Dann erstellen wir ein neues Projekt von existierenden Dateien und geben an das sich unser Webserver auf einem Remote Host befindet.

File -> New Project from Existing Files -> 
My web server is on remote host, files are accessible via FTP/SFTP

Als nächstes gibt man die Zugangsdaten zum Testserver an. In meinem Fall SFTP und die Authentifizierung passiert per Private Key.

PhpStorm Server Settings

Die Testserver Einstellungen sind nicht Projektspezifisch und können wiederverwendet werden. Deshalb wird bei Root Path auch nicht der Projektpfad angegeben, sondern ein etwas allgemeiner Pfad. Auf der nächsten Seite wählt man den root Ordner für sein Projekt auf dem Remote Server aus und wenn nötig kann man noch einen Projekt Web Pfad einstellen. Dann gibt man dem Baby noch einen Namen und gibt den lokalen Projekt Ordner an. Das ist das Verzeichnis mit dem lokalen Git Repository. Beim Remote Ordner sollte man darauf achten das dieser leer ist, da sonst die dort vorhandenen Dateien heruntergeladen und ins Projekt eingegliedert werden, aber vielleicht ist dies auch genau das was man möchte.

Phpstorm Lokaler Pfad

Hat man bei den Deployment Optionen einen Hacken bei Custom gesetzt, kommt man zu dieser Seite. Auf dem Bild sieht man meine Einstellungen.

  • Upload changed files automatically to the default server bewirkt das man sich nicht selbst um die Synchronisierung der Server kümmern muss.
  • Upload external changes sorgt dafür das man auch außerhalb von PhpStorm Veränderungen an Projektdateien vornehmen kann und diese auch automatisch auf den Remote Server kopiert werden. Sehr hilfreich wenn man zum Beispiel Bilder hinzufügt oder löscht.
  • Create empty directories erstellt leere Verzeichnisse die man lokal anlegt auch auf dem Server.
  • Delete target item if source one is missing würde ich nicht empfehlen zu benutzen. Hier kann es zu unerwünschten Reaktionen kommen. Mir ist es passiert das ich ein Projekt vom Remote Server herunterladen wollte. Da mein lokales Projekt aber leer war, hat PhpStorm die Dateien auf dem Remote Server auch gelöscht...

Phpstorm Deployment Options

Nach einem Klick auf Finish legt PhpStorm los. Hat man sein Projekt lokal angelegt, muss man es jetzt noch auf den Testserver übertragen. Dazu rechts klicken auf den Projektordner im Dateimanager und ganz unten auf Deployment -> Upload to Testserver klicken. Nun kann man lokal Änderungen vornehmen, wie gewohnt mit dem VCS arbeiten und die Anpassungen auf dem Testserver ansehen. Die in dem Wizard getroffenen Einstellungen kann man jederzeit ändern. Dazu klickt man auf File -> Settings -> Project Settings und hier Deployment und Options.

Git und was ist mit dem .idea Verzeichnis?

PhpStorm legt im Projektverzeichnis das .idea/ Verzeichnis an. Das möchte man natürlich auch nicht in seinem Repository haben. Schaut man in die Git Hilfe zum Thema .gitignore, dann sollte der Ausschluss in die projectname/.git/info/exclude Datei eingetragen werden. Es gibt aber auch den Weg das Verzeichnis direkt in PhpStorm zu ignorieren. Ich bevorzuge aber den info/exclude weg.

# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~
.idea/

PhpStorm möchte ein Passwort beim pushen/pullen?

Standardmäßig benutzt PhpStorm seine eigene SSH Implementierung. Umstellen kann man dies in den Settings.

File -> Settings ->Project Settings -> Version Control -> VCSs -> Git

Dort stellt man SSH Executable auf Native um und dann sollte kein Passwort mehr abgefragt werden (wenn man Public Key Auth wie im anderen Artikel beschrieben eingerichtet hat).

Hinweis: Das funktionierte bei mir eine Zeit lang sehr gut, aber seit ich meine portable Einstellungen benutze, friert PhpStorm beim push/pull ein und muss beendet werden. Ich habe noch nicht herausgefunden warum dies geschieht. Um trotzdem arbeiten zu können, lasse ich die SSH Executable auf PhpStorm ssh stehen und benutze den PhpStorm Passwortmanager um nicht ständig Passwörter eingeben zu müssen. Wenn jemand hierfür eine Lösung hat, würde ich mich über ein Kommentar freuen.

Zeichensatz einstellen

Ich hatte noch ein anderes Problem bei einem Projekt das kein UTF8 benutzte. Sobald ich Dateien in PhpStorm geöffnet hatte und sie wieder speicherte, waren die Sonderzeichen zerschossen. Dem kann man entgegenwirken in dem man die File Encodings anpasst.

File -> Settings ->Project Settings -> File Encodings

Hier kann man für jede Datei, für Ordner/Unterordner oder für die komplette IDE das Encoding festlegen.

Deployment auf den Live Server vom Git Server aus

Im nächsten Artikel wird gezeigt wie man vom Git Server aus das Projekt auf den Live Server (oder mehrerer) veröffentlicht: Deployment einfach gemacht mit Git Hooks

Im ersten Teil dieser Anleitung wurde gezeigt wie man den Git Server einrichtet und Git for Windows an den Git Server anschließt. In diesem Teil wird gezeigt wie man ein neues Repository anlegt, es auf den Server überträgt und beide mit einander verbindet.

Alle Teile dieser Artikel Serie

Lokales Repository erstellen in der Git Bash

$ cd x
$ cd /www/
$ mkdir projectname
$ cd projectname
$ git init
Initialized empty Git repository in /www/projectname/.git/

Wenn man seine Git Config noch nicht angepasst hat, dann sollte man dies nun machen. Um die aktuelle Config zu sehen reicht ein "git config --list" aus. Es sollte mindestens der user.name und die user.email gesetzt sein.

$ git config --global user.name "kostaki"
$ git config --global user.email kostaki@gmx.net

Arbeitet man für unterschiedliche Firmen oder möchte unterschiedliche E-Mail Adressen benutzen, kann man die Config auch nur für das aktuelle Repo anpassen.

$ git config --local user.name "Marco"
$ git config --local user.email marcosemail@firma.de

Jetzt kann man seine Projekt Dateien in den Git Projektordner kopieren und wenn nötig eine .gitignore anlegen für Dateien die nicht von Git getrackt werden sollen.

.gitignore erstellen: Wie man Temp Verzeichnisse behandelt

In Webprojekten hat man oft Temp Verzeichnisse. Die Inhalte dieser möchte man natürlich nicht in seinem Repository haben, aber die Verzeichnisse sollen trotzdem angelegt werden wenn man einen neuen Clone anlegt. Dies kann man mit den folgenden Zeilen in der .gitignore bewerkstelligen.

# tmp verzeichnisse
app/tmp/smarty/compile/*
app/tmp/cache/*
!.gitignore

Das /* am Ende bewirkt das nur Dateien in den Verzeichnissen ignoriert werden und nicht das Verzeichnis an sich. Da Git aber keine leeren Verzeichnisse tracken kann, legt man eine leere .gitignore in die Verzeichnisse und die letzte Zeile !.gitignore ist eine Ausnahme für diese Dateien. Die .gitignore in den Temp Verzeichnissen werden also zum Repo hinzugefügt und damit wird bei einem neuen Clone das Verzeichnis angelegt. Tipp: Wenn man Funktionen hat die Temp Verzeichnisse leeren, sollte man hier eine Ausnahme für .gitignore Dateien hinzufügen. :)

Der erste Commit (Initial commit)

Jetzt werden alle Dateien zum Git Index hinzugefügt und der erste Commit durchgeführt.

$ git add .
$ git commit -m "Initial commit"

Damit hat man nun ein lokales Repository mit dem man arbeiten kann. Im nächsten Schritt wird dies auf den Server übertragen.

Git Repository auf den Git Server kopieren und anbinden

In der Git Bash wird nun ein Clone des Repositories angelegt. Das muss nur ein bare Clone sein, da dieser auf den Git Server kopieren werden soll und dort nur der .git Ordner gebraucht wird (nicht die Dateien an sich). Im Git FAQ steht außerdem das man nur in bare Clone pushen soll, außer man weiß was man tut. Dazu später mehr.

A quick rule of thumb is to never push into a repository that has a work tree attached to it, until you know what you are doing.

Hat man den bare Clone erstellt, kann man ihn per SCP auf den Git Server kopieren. Den Clone kann man nach dem übertragen löschen.

$ cd ..
$ pwd
/x/www
$ git clone --bare projectname/.git projectname.git
$ scp -P 12345 -r projectname.git \
mygituser@server.com:/home/mygituser/repos/
$ rm -rf projectname.git

Als nächstes wird dem lokalen Repository ein neues Remote Repository hinzugefügt.

# anlegen eines neuen remote repos, git remote add <name> <url>
$ git remote add origin \
ssh://mygituser@myserver.com:12345/home/mygituser/repos/projectname.git

# löschen eines eingetragenen remote repos, git remote rm <name>
$ git remote rm origin

# anzeigen welche remote repos eingetragen sind
$ git remote

Man kann die .git/config auch mit einem Editor von Hand bearbeiten, wenn man weiß was man tut. Nun kann man aus dem lokalen Repository heraus nach Origin pushen oder Änderungen von dort pullen.

$ git pull origin master
$ git push origin master

Damit man den Namen und den Branch nicht bei jedem push/pull angeben muss, kann man seine Standards in die git config eintragen. Dann reicht ein einfaches "git push" bzw. "git pull".

$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master
$ git pull
$ git push

PhpStorm, Git und ein Remote Webserver

Im nächsten Artikel gehe ich dann auf die Integrierung des Git Repositories in PhpStorm ein und die Anbindung des Remote Testservers: PhpStorm, Git und ein Remote Webserver

Ich wollte vor ein paar Tagen mal eine schnelle Auswertung machen welche E-Mail Provider die Benutzer einer meiner Seiten benutzen. Ich dachte da an ein einfaches PHP Script das die E-Mail Adressen ausliest, den Teil vor dem @ weg nimmt und dann die zurückbleibenden Domains zählt. Nach ein bisschen Suchen fand ich aber eine noch viel einfachere Lösung direkt per MySQL.

SELECT
	SUBSTRING_INDEX(email, '@', -1) AS provider,
	COUNT(*) AS count
FROM users
GROUP BY provider
ORDER BY count DESC

Vielleicht hilft es ja jemandem.

Nachdem Debian Squeeze veröffentlicht wurde, habe ich nach und nach meine Webprojekte auf einem Squeeze System (PHP 5.3) getestet und dabei einige Probleme gefunden. Eines davon hat mich eine Weile Zeit gekostet zu lösen. Es ging um ein Projekt in dem eine Session über mehrere Subdomains benutzt wurde. Also www.domain.de und subdomain.domains.de sollten beide auf die gleiche Session zugreifen, aber immer nach einem Switch der Domain war die Session leer. Probleme damit hatte ich schon öfter, wenn man zum Beispiel nicht die richtige Cookie Domain beim Session Cookie setzt, aber dieses mal wurde keine neue Session generiert, sondern die Session ID blieb gleich, nur die Daten wurden reseted. Glücklicherweise fand ich dann diesen Post auf PHP.net.

debian 5 installs by default the php-suhosin module, which changes the behavior of session_set_save_handler read/write function. on calling the session write function the session data will be encrypted, and the returning string from the read function are decrypted and verified. the encrypted data is no more compatible with session_encode/session_decode. and breaks by default, subdomain handling and multiple host setups where different document roots are used.

Suhosin verschlüsselt die Session Daten und bezieht hierfür die Document Root mit ein. Glücklicherweise kann man das Suhosin abgewöhnen indem man die in der Dokumentation beschriebenen Settings anpasst. Ich habe es gleich komplett abgeschaltet, aber man kann wohl auch den Salt anpassen.

$ nano /etc/php5/cgi/conf.d/suhosin.ini
; Transparent Encryption Options
suhosin.session.encrypt = off

Man kann es auch für einzelne vhosts abschalten per php_value oder in der vhost php.ini wenn man verschiedene definieren kann.

Setzt man Git auf einem Windows System ein und deployed dann auf ein UNIX/Linux System, kann es zu Problemen kommen wenn das Git Repository ausführbare Dateien beinhaltet. Da Windows Dateien nicht speziell als Ausführbar kennzeichnet, werden die Rechte bei jedem push/pull wieder zurück gesetzt. Ein Beispiel: Ich habe ein Bash Script geschrieben. Dies wurde deployed und hatte keine Ausführungsrechte. Diese wurden auf dem Server von mir gesetzt und das Script funktionierte. Beim nächsten Deployment (auch wenn ganz andere Dateien kopiert werden) wurde das Ausführungsrecht wieder entfernt und ich musste es erneut setzen.

Git bietet für "broken filesystems" einen Modus an in dem die Dateirechte nicht verändert werden. Dafür muss man in der Git Config einfach core.fileMode auf false setzen.

$ git config core.filemode false

Das macht man auf dem Live System in das man pusht und indem man die Dateirechte behalten möchte.

Related Links

Eine Sache die mich schon immer an der Windows Konsole gestört hat ist das markieren, kopieren und einfügen. Wenn man Putty gewohnt ist, ist der Umstieg auf die Windows CMD ein Problem... Ich ging immer davon aus das man an diesem Problem nichts ändern kann, bis ich heute den Artikel QuickEdit für Windows-Konsole (cmd.exe) ähnlich wie bei PuTTY SSH fand. Dort wird erklärt das man nur 1 Hacken setzen muss um QuickEdit zu aktivieren und dann funktioniert die Windows CMD wie Putty.

Windows CMD Putty

Das erleichtert die Arbeit ungemein, da man nur noch den Text markieren muss und ihn per Rechtsklick in die Zwischenablage kopiert. Mit einem weiteren Rechtsklick fügt man die Zwischenablage wieder ein. Zum dauerhaften aktivieren muss man einen Registry Eintrag anpassen.

Seit ein paar Monaten ist beruflich nun auch bei mir Git im Einsatz und wenn man sich erst mal dran gewöhnt hat, will man nicht mehr darauf verzichten. Deshalb stelle ich gerade meine private Entwicklungsumgebung auch darauf um. Im gleichen Schritt wechsle ich gleich noch meine IDE auf PhpStorm. In diesem Artikel möchte ich die nötigen Schritte erklären die zur Einrichtung nötig waren. Vielleicht interessiert es ja den ein oder anderen.

Alle Teile dieser Artikel Serie

Ausgangssituation

Ich entwickle für Linux Systeme, aber benutze einen Windows Rechner, was es manchmal komplizierte macht. Bisher besteht meine private Entwicklungsumgebung aus einem Debian Entwicklungsserver mit Webserver, MySQL und dem ganzen Klimbim. Ich mappe mir einzelne Verzeichnisse auf dem Entwicklungsserver per SFTP über Webdrive und arbeite dann direkt mit Notepad++ auf dem Server. So brauche ich keinen lokalen Webserver und muss nicht auf die Windows/Linux Unterschiede bei der Entwicklung eingehen. Der Live Server ist ebenfalls ein Linux Server.

Beim arbeiten führe ich ein manuell gepflegtes Changelog, damit ich am Ende noch weiß was ich hoch laden muss. Wenn Änderungen abgeschlossen sind und ich sie deployen möchte, kopiere ich mir die geänderten Dateien in ein extra Verzeichnis und lade sie auf den Live Server. Wenn ich nicht gerade zu faul bin, mache ich vorher noch ein extra Backup der Dateien zum schnellen Wiederherstellen.

Das funktioniert eigentlich sehr gut, da ich nur allein an meinen Projekten arbeite, aber das pflegen des Changelogs und das manuelle uploaden ist nicht mehr zeitgemäß und kostet Zeit. Außerdem habe ich keine Historie und ich kann nur schwer ein Backup zurück spielen wenn mal etwas nicht funktioniert.

Zielstellung

Ich möchte einen zentralen Git Server auf dem die Repositories liegen. Ich hatte überlegt dies per Github oder ähnliche zu machen, aber das Geld dafür möchte ich lieber sparen und da ich eh noch ungenutzte VServer habe, wurde einer davon zum Git Server auserkoren. Wer gern eine Weboberfläche haben möchte und sich nicht um die Serveradministration kümmern möchte, ist bei Github gut aufgehoben. Hat man Open Source Projekte und benötigt keine privaten Repositories, ist Github natürlich auch zu empfehlen, da es dafür kostenlos ist!

Als Client benutze ich weiterhin Windows und als Server weiterhin Linux. Als IDE kommt bei mir nun PhpStorm zum Einsatz, da ich die VCS Implementierung mag und ich es als sehr viel schneller empfinde als zum Beispiel Eclipse. Die ganzen Einstellungsmöglichkeiten sind natürlich auch super. Als Git Client benutze ich die portable Version von Git for Windows. Die lokalen Repositories habe ich auf einer externen Festplatte die ich per Truecrypt verschlüssle und immer dabei habe. Als großer portable Apps Fan der öfters an unterschiedlichen Rechnern arbeitet, freue ich mich natürlich das msysgit (Git for Windows) sowie auch PhpStorm portable laufen und nicht installiert werden müssen. Wie man das einrichtet steht hier: portable msysgit, portable PhpStorm

Meinen Entwicklungsserver behalte ich, da ich keinen lokalen Windows Webserver (z.B. XAMPP) haben möchte. Das ist auch kein Problem, da PhpStorm per FTP/SFTP auf den Entwicklungsserver zugreifen kann und die Synchronisierung automatisch erledigt. Auf meinem Git Server wird Public KeyAuth aktiviert, da ich ohne Passwortabfragen per Git pushen/pullen möchte. Der Name Git Server ist in meinem Fall eigentlich nicht richtig gewählt, da es sich nur um einen normalen Debian Server handelt auf dem git-core installiert ist. Ich setze keine Weboberfläche ein und auch kein Gitosis, da es sich um meine private Entwicklung handelt an der ich allein arbeite. Wer das aber gern haben möchte, findet hier eine Anleitung dafür: Zentrales Git Repository unter Debian GNU/Linux 5.0 "Lenny" Howto.
(mehr …)