27. Dezember 2015 , 22:38 Uhr
von Marc Eggert

 

Seit Jahren bin ich auf der Suche nach dem für mich perfekten Setup für die allgemeine „PHP/MySQL/Subversion/“-Entwicklungsumgebung. Ziele sollten dabei sein, möglichst einen Remote-Entwicklungs-Server nutzen zu können (also keine lokalen Entwicklungs-Server auf der lokalen Linux-Maschine oder unter Windows via XAMPP), denn die Entwicklung sollte möglichst auf dem zukünftigen Zielsystem laufen. Lange Zeit waren bei mir diverse Editoren im Einsatz, die an jeweils unterschiedlichen Stellen ihre Schwächen hatten oder aber mit der Zeit wurden die verschiedenen Ansprüche so komplex, dass man selbst die Funktionsweisen der unterschiedlichen Dienste nicht mehr durchblickte. Inzwischen habe ich zu einer Entwicklungsumgebung gefunden, die meinen Ansprüchen vollstens gerecht wird und zudem unter meinen 3 verschiedenen Client-Systemen einsetzbar ist (Windows/Linux/MAC). Eventuell ist dies ja auch eine Lösung für den ein oder anderen unter den Lesern. Die Entwicklungsumgebung bietet dabei folgende Features:

  • Einsetzbar unter Linux/Windows/MAC
  • Editor mit der Unterstützung, Dateien Remote zu verändern (Dateien werden direkt auf einem Zielserver editiert/bzw. ersetzt)
  • direkte Integration von Subversion entferntes Repository wird bedient
  • PHPDoc integriert (sowohl eigene Dokumentation, als auch PHP-Funktions-Referenz)

Die Ausgangslage

Meine Entwicklungsumgebung sieht so aus, dass ich zusätzlich zur Produktiv-Domain www.DOMAIN.TLD eine Entwicklungsumgebung betreibe – i.d.R. „dev.DOMAIN.TLD“ oder „entwicklung.DOMAIN.TLD“. Beide Server oder VHost-Instanzen laufen unter den exakt selben Voraussetzungen/Installationen (was PHP/MySQL/Apache inkl. dazugehöriger Module angeht). Beim Entwickeln von PHP-Code dient der DEV-Server dazu, Auswirkungen des aktuell editierten Codes sofort einsehen zu können und eben zu debuggen.

Der Entwicklungscode an sich wird wiederum nicht (nur) auf dem Entwicklungs-Server belassen, sondern wird jeweils auf einem entfernten SVN(„Subversion“)-Server aktuell gehalten und versioniert. Ich nutze hier als selbst gehostete Lösung den Verbund SVN mit der Software „Redmine“. Redmine bietet zusätzliche weitere Features, wie einen Online-SVN-Browser, Projekt-Verwaltung, Wiki, Forum, Datei-Ablage, etc. Dies ist für die Entwicklungsumgebung wie sie hier beschrieben wird, nicht notwendig – ein SVN-Server an sich rundet das lokale Entwicklungssystem allerdings m.E. ab.

Natürlich ist es auch möglich, die hier beschriebene Umgebung im lokalen Netz oder gar auf dem lokalen Rechner mittels virtueller Maschinen umzusetzen.

Der Editor (Netbeans PHP)

Wie ich bereits zuvor geschrieben hatte, bin ich schon seit einigen Jahren auf der für mich „endgültigen“ Lösung für eine Entwicklungsumgebung. Meine aktuelle Lösung in dieser Aufgabe kommt aus einer eher unerwarteten Ecke: Aus der Java-Entwicklung. Das stimmt eigentlich nicht so ganz, denn bis vor einigen Monaten war ich begeisterter Nutzer von Aptana, was als Ableger von Eclipse ja ebenfalls aus der Java-Ecke stammt.

Mein Editor für die Lösung aller der meisten Probleme ist: Netbeans – und hier speziell die für PHP ausgelegte Version. Hier ist auf der Download-Seite die gewünschte Sprache, Version, sowie OS auszuwählen und dann eben der Download der PHP-Version zu starten.

Konfiguration des Editors

meine Netbeans-Plugins

Abb. 1: meine Netbeans-Plugins

Die Installation des Editors kann nach Standard-Vorgaben vorgenommen werden. Die relevanten Einstellungen nehme zumindest ich in den jeweiligen Projekt-Einstellungen vor, welche ich im Übrigen ebenfalls gleich mit auf dem SVN-Server mit aktuell halte. In meiner Situation ist es so, dass ich je nach Situation auch tatsächlich auf einem der drei verschiedenen Systemen arbeite (Linux, MAC oder Windows).

Netbeans kann durch Plugins erweitert werden. Im Menüpunkt „Tools“->“Plugins“ kann nach Plugins im Netbeans-Repository gesucht werden und bei Bedarf auf installiert werden. Auf Abb. 1 ist meine derzeitige Plugin-Liste angezeigt. Hier wird aber vermutlich jeder seine eigenen Vorlieben haben.

Erstmalige Projekt-Einrichtung

Die folgenden Beschreibungen beziehen sich auf die deutsche Netbeans-Version. Die aufgerufenen Menüpunkte haben in der englischen Version entsprechend andere Bezeichnungen.

Zunächst legt man in Netbeans ein neues Projekt an. Im folgenden Dialog-Fenster wählt man dann „PHP Application“ und die entsprechende PHP-Version aus, vergibt einen Namen für das Projekt (ich nehme hier i.d.R. den Namen des Software-Projekts oder eben gleich den Domain-Name) und wählt das Verzeichnis aus, in welchem die Projektdaten LOKAL gespeichert werden sollen. Die Auswahl der PHP-Version hat hier für unsere Zwecke die Auswirkung, dass die integrierte PHP-Dokumentation die entsprechenden Hinweise auf mögliche Script-Fehler korrekt ausgibt (was unter PHP 5.5. funktioniert hat, muss nicht zwangsweise unter PHP 5.6 funktionieren, etc.). Mit der Auswahl dieser zwei Optionen kann man bereits auf „Fertigstellen“ klicken und den Dialog hiermit schließen. Netbeans legt in den Standard-Einstellungen jetzt bereits eine index.php-Datei an. Diese kann auch gleich wieder gelöscht werden. Wir wollen in diesem Setup ja unsere SVN-Quellen nutzen und daran weiterarbeiten.

Subversion-Konfiguration

Eine Voraussetzung für den folgenden Konfigurations-Schritt ist es, dass du bereits ein Subversion-Repository angelegt hast, auf welches du zugreifen kannst. Eine grundsätzliche Beschreibung zur Einrichtung eines einfachen SVN-Servers beschreibe ich in einem anderen Artikel. Du benötigst also an dieser Stelle die URL des Repositoriums, einen Benutzernamen und das Passwort hierzu.

Hinweis: Im Repository können, aber müssen sich noch keine PHP-Dateien befinden. Ein „typisch“ vorbereitetes Repository mit der Aufteilung in Trunk/Tags/Branches wäre allerdings sinnvoll.

SVN Checkout

Abb. 2: SVN Checkout

Die Subversion-Einrichtung startet man innerhalb von Netbeans mit einem Checkout. Diesen Punkt findet man via Rechtsklick auf das PHP-Projekt im Reiter „Projekte“ im linken Abschnitt von Netbeans (siehe Abb. 2).

Im folgenden Dialogfenster trägt man nun die o.g. Daten ein – also Repository-URL, Benutzername und Passwort. Auf dem eigenen Rechner kann man auch gleich die Checkbox „Benutzernamen und Passwort speichern“ nutzen, um sich nicht jedesmal und bei jedem Commit neu am SVN-Server anmelden zu müssen. Bei der Repository-URL muss man noch nicht mit angeben, welches Verzeichnis man explizit auschecken möchte – es ist also nicht notwendig, „trunk“ o.ä. an die URL mit anzuhängen.
Sind diese Daten eingetragen, klickt man auf „weiter“ – Netbeans versucht dann, eine Verbindung zum SVN-Server aufzubauen. Wenn dies geklappt hat, wird das Dialogfenster wie in Abb. 3 angezeigt. Über den oberen Button „Durchsuchen“ kann man auch bereits durch das nun verbundene SVN-Repository navigieren – und wählt an dieser Stelle dann auch direkt aus, was ausgecheckt werden soll. In aller Regel dürfte dies das Verzeichnis „trunk“ und die Repository-Version „HEAD“ sein – also die derzeit aktuelle Revision im Repository.
Die Checkbox zum Punkt „trunk übergehen und nur den Inhalt herunterladen“ ist evtl. eine gewünschte Option. Dies bedeutet, dass das Verzeichnis „trunk“ selbst nicht lokal angelegt werden soll, sondern nur dessen Inhalt. Genau das möchte ich beispielsweise sowohl in meinen lokalen Daten, als auch später auf dem Remote-Entwicklungs-Server ganz genau so haben.

Unter dem Punkt „Lokales Verzeichnis“ gibt man (wie der Name schon sagt) das lokale Verzeichnis auf dem Rechner an. In dieses Verzeichnis werden die Dateien aus dem Subversion-Repository geladen, später editiert und wieder abgeglichen.

Als letzter Punkt in diesem Dialog ist die Checkbox „Nach dem Herunterladen nach Netbeans-Projekten suchen“ relevant. Dies ist notwendig für die Funktion, die ich schon zuvor beschrieben hatte: Die Projekt-Einstellungen möchte ich ebenfalls im Subversion-Verzeichnis speichern, so dass ich diese Einstellungen auch auf anderen Rechnern oder bei einer lokalen Neu-Installation von Netbeans gleich wieder verfügbar habe.
Wichtig an dieser Stelle: Es werden auch die Angaben zu den Verzeichnissen gespeichert und diese sind natürlich auf Windows-/Linux- und MAC-Systemen unterschiedliche. DIESE Einstellungen müssen also nach einem Checkout über ein anderes System angepasst werden, was allerdings auch schnell erledigt ist.

Per Klick auf „Fertigstellen“ werden im Anschluss die zuvor ausgewählten Verzeichnisse und Dateien aus dem SVN-Repository heruntergeladen – dies dauert je nach Größe eine gewisse Weile. Sind alle Daten geladen, meldet sich Netbeans mit einer Nachfrage, ob ein Projekt geöffnet werden soll. Dies ist in diesem Fall allerdings nicht notwendig: Ein Projekt haben wir bereits angelegt und in diesem Projekt sieht man auf der linken Seite von Netbeans unter „Source Files“, dass die Daten bereits in unserem Projekt liegen. Also: Dialog-Box „Schließen“ auswählen.

Remote-Konfiguration

Die SVN-Daten sind geladen, lokal verfügbar – theoretisch kann es mit dem (Weiter-)Programmieren losgehen. Allerdings möchten wir die Auswirkungen der Programmierarbeiten auch direkt auf unserem Entwicklungs-Server sehen. Sprich: Datei editieren -> Datei speichern -> Seite im Browser aufrufen -> Ergebnis einsehen. Dazu richten wir unser Netbeans-Projekt jetzt so ein, dass die lokalen Daten nach Veränderungen sofort auf den Entwicklungs-Server geladen werden. Glücklicherweise funktioniert das auch „out-of-the-box“ via SSH/SFTP (FTP ist allerdings auch möglich).

In die entsprechenden Einstellungsoptionen gelangt man wieder via Rechtsklick auf die Wurzel des Projekt-Baumes in der linken Seitenleiste von Netbeans. Hierbei wählt man dann den letzten Menüpunkt in der Liste („Einstellungen“). In diesem Einstellungsfenster lassen sich sämtliche Projekt-Optionen einstellen und verändern. Die Option für das Remote-Aktualisieren der Daten versteckt sich unter „Run Configuration“. Hier lassen sich auch verschiedene Konfigurationen abspeichern. Mir hat bislang immer eine Konfiguration gereicht.

Netbeans_pproperties

Abb. 4: Projekt-Einstellungen REMOTE

Der erste wichtige Punkt verbirgt sich hinter der zweiten Dropdown-Liste, in welcher jetzt „default“-mässig „Local Web Site“ steht. Das gilt für unser Projekt nicht – unsere Webseite soll auf dem entfernten Entwicklungs-Server laufen. Dazu wählt man den Eintrag „Remote Web Site“ aus der Liste aus und legt via Klick auf „Manage…“ die Verbindung für den Remote-Server fest. Hier können verschiedene Profile geladen und angelegt werden. Über den Button „Add“ wird eine neue Verbindung angelegt. An dieser Stelle einfach einen Namen für die Verbindung zum Remote-Server eintragen und das Übertragungsprotokoll auswählen (Entweder FTP oder eben SFTP). Die Einstellungen in diesem Fenster dürften selbsterklärend sein. Die SFTP-Verbindung klappt auch wunderbar über Zertifikat-Authentifizierung – dies ist auch der Weg, wie ich mich zu meinen Servern verbinde.

Wenn die Verbindung funktioniert (Klick auf „Test Connection“) kann diese Verbindung in den Projekteinstellungen übernommen werden.

Unter „Upload“ Directory kann angegeben werden, in welches Verzeichnis auf dem Remote-Server die Dateien geladen werden sollen. I.d.R. ist nicht das Root-Verzeichnis des (S)FTP-Zugangs auch das DocRoot-Verzeichnis, in welches man die Daten laden möchte. Hier ist also das Docroot/Zielverzeichnis anzugeben (beispielsweise /web oder ../var/www <- afaik ist das Verzeichnis hier relativ anzugeben!).

Der letzte wichtige Punkt in diesem Dialog ist die Einstellung „Upload Files“. Für mich ist dieser Punkt deshalb wichtig, weil ich beispielsweise die internen „Run“-Funktionen aus der Netbeans-IDE nicht nutze, sondern einfach parallel einen Browser mitlaufen lasse oder gar einen Browser auf einem anderen Rechner nutze, um die getätigten Veränderungen im Browser anzuschauen.
Sprich: die Option „On Run“ ist o.k., wenn man die Run-Funktion aus Netbeans heraus nutzen möchte. Das bedeutet, dass per Klick auf den grünen Pfeil in der oberen Leiste von Netbeans die Änderungen erst dann hochgeladen werden und dann ein Browser gestartet wird, welcher die hochgeladenen Veränderungen auf dem Remote-Server anzeigt. Die Option „manually“ dürfte ebenso selbsterklärend wie „on save“ sein. „on save“ nutze ich – so dass nach jedem Speichern die Veränderte Datei sofort auf den Remote-Server geladen wird. So erzielt man gefühlt eine Art direktes Editieren auf dem Remote-Server.

Arbeiten in dieser Entwicklungsumgebung

Funktionsweise beim Editieren

Um grundsätzlich zu verstehen, was mit der so konfigurierten Entwicklungsumgebung im Hintergrund passiert, erkläre ich dies mit ein paar Worten und einem vereinfachten Schaubild.

Funktionsweise der IDE-Umgebung

Funktionsweise der IDE-Umgebung

Sobald sämtliche Daten erstmalig vom Subversion-Server auf den lokalen Rechner geladen wurden, kann lokal editiert und programmiert werden. Bei jedem Speichern einer Datei auf dem lokalen Rechner wird automatisch der „DEV-Server“ mit den veränderten Dateien und Verzeichnissen aktualisiert. Dies dient vor allem dem Debugging und Testen von Webseiten auf einem Extra-Server oder VHost, ohne Einfluss auf den Produktiv-Server zu nehmen.

Zu selbst festgelegten Zeitpunkten wird außerdem MANUELL das SVN-Repository („Subversion-Server“) direkt aus Netbeans heraus aktualisiert („svn commit“). Entsprechende GUI-Befehle sind in Netbeans bereits integriert – so auch die Neu-Aufnahme von Verzeichnissen und Dateien in ein Repository.

Bestimmte Revisionen werden via Subversion auf dem Subversion-Server als „produktiv“ getaggt und solche Versionen dann auf den Produktiv-Server geladen. Nicht jeder commit vom lokalen Rechner heraus muss eine stabile oder funktionsfähige Version sein. Tiefergehende Erklärungen zu SVN würden hier allerdings den Rahmen sprengen und vermutlich hast du zu diesem Thema vermutlich so oder so schon das entsprechende Know-How.

PHPDoc – dokumentiere den Code!

Wer kennt es nicht? Man laufe mal durch die eigene IT-Abteilung und fragt nach einer Dokumentation zur Software. Das muss noch nicht mal eine Benutzer-Dokumentation sein – es reicht bereits das Verlangen nach einer Dokumentation zur Funktionsweise der Software auf Entwickler-Basis. Vor diesem Problem steht man oftmals dann, wenn es darum geht, dass neue Mitarbeiter, Freunde oder Helfer an einer Software mitentwickeln sollen. Beim Programmieren gibt es in der Umsetzung oftmals sehr viele Herangehensweisen, Stile und Vorlieben, die oftmals auch guten Programmierern nicht gleich schlüssig sind.

Netbeans PHPDoc Screenshot

Automatisierte Anzeige der integrierten Dokumentation

Wer JAVA kennt, wird auch JavaDoc kennen – eine Art Dokumentation während der Programmierung. Mit PHPDoc (oder aktuell geht es bei PHP in Richtung apigen) steht ein ähnlich nützliches Tool zur Verfügung, welches die Dokumentation von Code unterstützt. Netbeans integriert die PHPDoc-artige Dokumentation sehr gut, so dass bereits beim Tippen eines Methoden-Aufrufes bereits über ein Pop-up erklärt wird, was diese Methode macht, welche Parameter die Methode erwartet und welches Ergebnis diese Methode ausgibt. Ebenso werden Variablen dokumentiert und deren Inhalte beschrieben oder beim Ansprechen einer Klasse bereits vorgeschlagen, welche Methoden zur Verfügung stehen.

Zu guter letzt lässt sich eine solche Dokumentation später auch als Entwickler-Doku ausgeben (PDF, XML, Whatever…) – hierzu muss der Pfad zur entsprechenden Binary innerhalb der Netbeans-Einstellungen angegeben werden (NetBeans erfragt diese Einstellungen allerdings automatisch sobald der Menüpunkt „generate Documentation“ aufgerufen wird (apigen oder PHPDoc).

Subversion

Wie bereits weiter oben beschrieben, sind die gängigsten SVN-Befehle bereits in die GUI integriert. Sprich: Commit, Delete, Add, etc. kann alles über das Netbeans-Kontext-Menü erledigt werden. Ein idealer Arbeitsvorgang mit Subversion sieht also i.d.R. so aus, dass man vor Arbeitsbeginn ein Update durchführt, um die aktuellen Quellen aus dem Repository auf dem Rechner zu haben. Nach erledigter Arbeit beendet man diese via Commit, um die aktuellsten Veränderungen dem SVN-Server zuzuführen (bei Team-Arbeit gibt es hier dann eben oftmals noch die „Konfliktlösungen“ wie eben auch von anderen SVN-Lösungen bekannt).

Wichtig ist auch hier immer wieder, dass man beachtet, dass  Dateien und Verzeichnisse über Netbeans kopiert oder gelöscht werden sollten und nicht über den eigenen Datei-Manager an Subversion vorbei (auf zweiterem Weg wird nämlich kein „svn delete“ oder „svn add“ ausgeführt und die Dateien fehlen oder existieren zwar lokal aber nicht im Repository!).

Fazit

Die Beschreibung wurde jetzt doch ziemlich detailliert und vielleicht für so manchen auch etwas zu einfach. Ich versuche hier allerdings auch Einsteigern das Thema schmackhaft zu machen und sich auf diese Weise evtl. neuer Themen anzunehmen. Ich bin mir inzwischen relativ sicher, dass die oben beschriebene Konfiguration eine ganze Weile meine Standard-Umgebung für Web-Geschichten sein wird, da sie meinen Ansprüchen zur Zeit am Komplettesten entspricht und wohl das größte Feature für mich bietet: Auf allen der von mir genutzten Plattformen gleich stark lauffähig sein!

    Zu diesem Beitrag gibt es noch keine Kommentare...

Kommentar verfassen