Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP Entwicklungsumgebung online / offline / verteilt

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHP Entwicklungsumgebung online / offline / verteilt

    Hallo zusammen,

    ich bin auf der Suche nach einer guten Lösung für eine PHP Entwicklungsumgebung.

    Ist-Situation:
    Xampp und Ecplise sind auf einem Laptop installiert, welchen ich die ganze Zeit mit mir herum trage. Bin ich an Orten, wo mir feste Rechner zur Verfügung stehen, verdinde ich zum Laptop mit Remote-Desktop.

    Problem:
    Auch wenn es nicht viel ist, stört mich mittlerweile die Verzögerung beim Tippen. Wenn ich schnell tippe, schaffe ich mehr als 5 Anschläge pro Sekunde. Zudem habe ich teilweise einemal meinen Laptop vergessen und muss doch ein, zwei kleine Änderungen vornehmen. Ich möchte halt nicht mehr auf den Laptop angewiesen sein.

    Soll-Situation:
    Es wäre schön, wenn ich auf allen Rechnern (aktuell 2x Desktop 1x Laptop), den gleichen Stand der Entwicklungsumgebung habe, incl. SQL-User, Eclipse Einstellungen, etc.
    Zudem wäre es super, wenn ich die Umgebung auch offline verwenden könnte, dies ist aber nur very-nice-2-have und kein must-have.
    Idealerweise sollte es eine Software-Seitig kostenlose Lösung sein.

    Wie würdet ihr das realisieren bzw. wie habt ihr das bei euch realisiert, falls ihr auch auf mehreren Rechnern an unterschiedlichen Standorten entwickelt?

    VG
    Daniel
    PS: Ich hoffe ich habe die richtige Kategorie für meine Frage gefunden.

  • #2
    In Eclipse hast du die Möglichkeit Einstellungen als Projekteinstellungen zu erstellen. Diese kannst du dann, soweit ich weiß, anderen Benutzern/Rechner im Rahmen des gesamten Projektes mit übergeben. PHPStorm hingegen bietet z.B. einen automatischen Mechanismus, der es ermöglicht Einstellungen über mehrere Installationen zu verteilen und diese von einem Server abzurufen.

    Um die Projekte zur organisieren empfiehlt es sich eine Versionsverwaltung wie z.B. Git zu nutzen und diese auf einem Server zu verwenden. Dann kannst du jedesmal wenn du an einem Rechner fertig bist mit arbeiten, den Stand ins Repository nehmen und dir vom anderen Rechner wieder holen. Standardvorgehen bei Projekten.
    "Software is like Sex, it's best if it's free." - Linus Torvalds

    Kommentar


    • #3
      Ich hatte ja oben schon geschrieben, dass ich kostenlose Software bevorzugen würde. PHPStorm ist mir bekannt, aber alles andere als kostenlos.

      Git ist mir auch bekannt, setzt aber voraus, dass ich online bin, damit wäre der offline Modus quasi abgeknipst.

      Zudem: Korrigiere mich, falls ich mich irre, aber mit Git würde ich nur den Sync der PHP Dateien bekommen. Ein Sync des SQL Servers wäre damit noch nicht gegeben, oder?

      EDIT:
      Ich wollte eigentlich nichts vorweg greifen, aber ich habe schon einen ersten Lösungsansatz, welche ich auch schon leider nicht erfolgreich getestet habe:
      Umstieg von Xampp auf Laragon da eigentlich 100% portable und Eclipse eh 100% portable.
      Sync der kompletten Folder (entpackt ca. 21.000 Dateien) gegen die Cloud.
      Ergebnis: Eclipse läuft ohne Probleme. Laragon Server (apache und SQL) auch ohne Probleme. Meine Anwendungen auf Laragon auch, aber phpmyadmin funktioniert nicht mehr. Hier weiss ich allerdings nicht, ob es ein Cloud-Sync-Problem ist oder die Datei fehlerhaft, oder oder oder.
      Ergebnis2: es ist nicht möglich direkt im lokal zu syncronisierenden Cloud-Verzeichnis zu arbeiten, da die Cloud-Sync-Software nicht auf von Prozessen blockierte Dateien zugreifen kann. Workaround, nach jedem lokalen arbeiten, manueller Trigger für den Upload in die Cloud.
      Spontan weiss ich noch nicht ob ich diesen Ansatz weiter verfolgen sollte, daher auch die Frage hier im Forum...

      Kommentar


      • #4
        Ok, habe ich leider überlesen.

        Naja du musst nur zum Pushen und zum Pullen online sein, dazwischen kannst du offline sein. Und wenn du die Dateien zwischen den Rechnern austauschen möchtest, musst du ja irgendwann mal online sein (außer du willst das natürlich über LAN o.ä. machen).
        Für SQL geht das natürlich nicht.
        Da müsstest du dann evtl. auf eine Master-Slave Replikation zurückgreifen, bei der der Master Server ein Remote Server ist und deine beiden Rechner Slaves.
        Von Microsoft gibt es außerdem auch einiges (Microsoft Sync Framework). Aber das ganze ist dann doch etwas komplexer und dürfte für ein Setting wie bei dir viel zu viel Aufwand darstellen.

        Was ich auch habe ist folgendes:
        Ich habe die htdocs von XAMPP und den mysql Ordner in einen synchronisierten OwnCloud Ordner ausgelagert.
        Von anderen Rechnern kannst du dann auch jederzeit auf die Daten zugreifen und hast beides aktuell (insofern natürlich eine Internetverbindung vorhanden ist). Muss man eben aufpassen mit Dateikonflikten (nicht gleichzeitig an beiden Rechnern arbeiten).
        Das ist aber eher ein Lazy Ansatz, den ich eher für Backup Funktionen habe.
        "Software is like Sex, it's best if it's free." - Linus Torvalds

        Kommentar


        • #5
          Den Ansatz habe ich bisher auch so praktiziert. Aber wenn man dann an SQL User, Apache und PHP Einstellungen denkt, oder an Änderungen in Eclipse, dann zieht das bei drei Rechnern auch immer drei Mal Änderungen nach sich und diesem Schlamassel wollte ich eigentlich aus dem Weg gehen.

          Hast du schon Erfahrung mit OwnCloud beim Sync von > 20k kleinen Dateien?

          Kommentar


          • #6
            Dann lagerst du eben die php.ini und die Apache Setting Files mit aus. SQL User werden ja auch geteilt durch den SharedFolder. Eclipse genau das gleiche. Entweder du lagerst deine kompletten Konfig Files in die Cloud aus, oder du nutzt Projektbezogene Settings. Lässt sich alles so aufbauen, dass du nicht alles neu einstellen musst.
            Inwieweit das irgendwann noch sinnvoll ist, ist die nächste Frage.

            Kommt drauf an wie oft Änderungen an den Files vorgenommen werden. Sollte klar sein, dass der Initial Upload/größere Änderungen etwas länger dauern. Im normalen Betrieb, also wenn du an den Files arbeitest, sind die Just in Time auf dem Server.
            "Software is like Sex, it's best if it's free." - Linus Torvalds

            Kommentar


            • #7
              Master/Slave und dann offline Modus?

              Nimm Vagrant und bootstrappe deine App richtig. Dann kannst du beim Neustart der VM automatisch die DB migrieren.
              [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

              Kommentar


              • #8
                Zunächst mal: Dein Problem haben viele Entwickler. Dafür gibt es Lösungen. Und da viele Entwickler dieses Problem schon lange haben, gibt es diese Lösungen schon lange und sind mittlerweile verrückt gut dokumentiert und stabil. Wenn du glaubst ein Problem zu haben, zu dem es im Bereich SCM keine Lösung gibt, hast du dein Problem oder die dazu passenden Lösungen nicht verstanden. Wahrscheinlicher ist aber, dass du einfach nur einen Blick über den Tellerrand werfen solltest.

                Verwaltung für Projektdateien
                Ja, Git ist für den Abgleich deiner Projektdateien gedacht. Die Daten eines SQL-Servers sind da dann nicht bei. Das ist für mich auch ein getrenntes Thema. Deine Projektdateien sind auf jeden Fall bei Git besser aufgehoben, als in einer Own-Cloud. Da gibt es auch rein objektive Argumente, die so lange gültig sind, bis es etwas besseres als Git gibt, oder es Features gibt, die Git nicht (nicht gut) leisten kann - was auch immer das dann für (mir bislang unbekannte) Gründe sein mögen. Solange kein triftiger Grund vorliegt, Git nicht einzusetzen, wäre jede andere Arbeitsweise weniger optimal und maximal subjektiv "besser" - wahrscheinlich weil man nur zu faul ist, neue und große Konzepte richtig kennenzulernen.
                - SCMs erhöhen die Nachvollziehbarkeit von Änderungen
                - Anders als bei Own-Cloud hat man IDE-aided Support für einen Blick in die Vergangenheit, Vergleich zweier zeitverschiedener Versionen der gleichen Dateien unterschiedlicher Entwicklerarbeitsplätze und eine Kontrolle darüber, was du "veröffentlichst" und was nicht. Und viele(!) weitere Features.
                - Der Aufwand ein Git-Repository aufzusetzen ist im Vergleich zu einem Own-Cloud-Server lächerlich.
                - Git ist schnell, wenn man lokal eincheckt. Sehr viel schneller als SVN, wenn man den lokalen Stand auf einen Remote-Server pusht. Das ist selbst dann noch richtig, wenn viele, größere "Commits" ausstehen, wohingegen SVN Änderungen bei Reconnect zum Internet als eben einen Commit realisiert. Das Gegenstück zu lokalen Commits bei SVN sind Patches, die dann zumindest nicht kleiner sind als die Git-Commits.
                - Git arbeitet (optional) mit SSH and therefore mit einem SSH-Agent für passwortlose Authentifizierung.
                - Die Kommunikation ist durch die Nutzung von SSH oder durch die Nutzung von HTTP mit SSL vor MITM-An- und Abgriffen relativ sicher.
                - Anders als bei einer Own-Cloud-ähnlichen Lösung hast du bei SCM-Systemen generell Branching/Merging-Support, inkl. Cherry-Picking und anderen Techniken.
                - Es gibt dann noch Github (für öffentliche Projekte) und Bitbucket (kostenlos selbst für private, nichtöffentliche Projekte). Bei beiden Lösungen kümmern sich andere um die ständige Verfügbarkeit der Services und darum, dass keine Daten verloren gehen.

                Verwaltung für das SQL-Schema
                Je nach dem, was du für ein DBMS einsetzt, gibt es hier unterschiedliche Tools, die sogenannte Schema-Migration ermöglichen. Diese Lösungen haben unterschiedliche Herangehensweisen, im einfachsten Fall kann man sich eine mögliche Lösung so vorstellen, dass irgendwo in der Hauptdatenbank eine Tabelle mit einem Zähler erstellt wird, der trackt, welche Version das Schema der Datenbank aktuell hat. Dann werden alle ausstehenden Migrationsskripte ausgeführt um das Datenbankschema für alle Entwickler auf den gleichen Stand zu bringen. Nochmal: Nicht alle DB-Migrationtools arbeiten so. Das sollte nur einmal eine grundsätzliche Idee vermitteln, wie sowas funktionieren kann. Manche Migrationsskripte können Aktionen auch Rückgängig machen. Wenn diese Migrationsskripte im SCM liegen und man das Projekt auf eine frühere Version zurückstellt, dann kann man die Datenbank auch auf ein zur damaligen Zeit funktionierendes Schema zurückbringen. Tatsächlich funktioniert sowas meiner Erfahrung nach nur richtig gut, wenn der Entwickler einen Fetisch dafür entwickelt, die Skripte so zu erstellen, dass solche Tools bei einer Rückmigration keine Daten vernichten.

                Verwaltung der SQL-Daten
                Hier gibt es keine perfekte Lösung. Es darf wohl allgemein als common sense angesehen werden, nicht auf einer Live-Datenbank zu entwickeln. Ich kenne hier mehrere Anätze, die alle ihre Vor- und Nachteile haben:
                - Irgendwo steht ein zentraler Entwicklungsserver, dessen Datenbank via SSH-Tunnel zugänglich gemacht wird. In der Windows-Welt gibt es sowas bestimmt auch.
                - Man holt sich von Zeit zu Zeit immer mal wieder einen aktuellen Stand auf dem ohnehin ständig laufendem Backup der Live-Datenbank.
                - Man arbeitet nur mit fiktiven Daten, die jeden bekannten Fall in jeder Dimension abdecken und man so immer gegen die Extreme möglicher Daten testen kann - optional auch automatisiert mit Tools wie PHPUnit.

                Verwaltung abweichender Standards bei Apache-Config und php.ini
                Ganz ehrlich? Geh immer davon aus, dass es nicht diese eine Konfiguration gibt. Irgendwann wechselt jede Umgebung von einer PHP-Version auf eine andere. Die Vergangenheit hat gezeigt, dass es dabei immer zu Kollateralschäden kam. Gebe vor, was deine Anwendung für Komponenten braucht und frage das an zentralen Punkten deiner Applikation ab. Beim Live-Gang in einem Deployment-Script, auf einer Entwicklermaschine bei einem Composer-Update oder bei jedem Seitenaufbau über den Bootstrap. Die Abfrage, ob gewisse ini-Direktiven gesetzt sind oder gewisse Module aktiv sind, kostet sehr wenig Zeit. Ich mache das beispielsweise tatsächlich so, dass bei manchen Projekten solche Checks bei jedem Seitenaufruf passieren, wenn xdebug präsent ist. XDebug brauche ich häufig und so wird bei einem if(function_exists('xdebug_enable')) { ... } eben jener Code ausgeführt, der die Checks macht.

                IDE-Einstellungen
                Die kannst du mit einem Cloud-Sync-Tool wie OwnCloud-Client oder Dropbox oder OneDrive oder oder oder verbinden. Windows kann Symlinks. MacOS auch. Linux auch.

                IDE
                Es wirkt auf mich fast so, als würdest du das alles in einem beruflichen Zusammenhang machen. 8,90€ im Monat ist der Preis für ein PHPStorm auf monatlich kündbarer Basis. Ich habe schon lange nicht mehr mit Eclipse gearbeitet (bis 2012 Zend Studio, was auf Eclipse basiert). Aber da ich von Leuten, die in dem Bereich gerne experimentieren, ständig höre, wo PHP on Eclipse steht, kann ich dir nur raten zumindest mal eine Probezeit in PHPStorm zu investieren. PHPStorm ist nicht irgendwie etwas besser. Der Unterschied ist extrem groß. Gleichzeitig höre ich immer wieder, das PHP für Netbeans eine Gute und kostenlose Alternative für PHP ist.

                Kommentar


                • #9
                  Noch ein Ansatz der schon kurz angesprochen wurde.

                  Ich nutze ein komplett virtuelles System in dem der Entwicklungs Webserver die DB und anderes benötigte Gedöhs drin liegen.

                  Zu Verwaltung der Virtualisierung (Virtual Box hier) nutze ich Vagrant und Puppet. Das Dokument-Root wird auf dem Hostsystem als Verzeichnis verfügbar gemacht (NFS). Auf dem Hostsystem liegt auch die IDE.

                  Die Virtualisierung liegt auf einem USB Medium und kann so auf jedem Hostsystem auf dem VirtualBox und Vagrant läuft genutzt werden. Ein Backup wird jeden Abend vom USB Medium gemacht. Da hst Du alles zusammen was zusammen gehört. Und die Projektbezogenen IDE einstellungen werden natürlich auch auf dem USB Medium abgelegt.

                  Eclipse zur PHP Entwicklung war vor 15 Jahren vieleicht mal ne Sache. Das ist heut zu tage soweit hinter PHPStorm und Netbeans das es nicht mal mehr die Rücklichter sehen kann (symbolisch gesprochen )

                  Seit Netbeans for PHP endlich PHP7 Code kennt ist es auch wieder eine Empfehlung wert.

                  PhpStorm ist sozusagen "state of the art" und jeden Cent wert den es kostet. Hab ich mir auch für private Projekte geleistet und teuer isses ja nicht wirklich.

                  Kommentar

                  Lädt...
                  X