Ankündigung

Einklappen
Keine Ankündigung bisher.

Lokale Entwicklungsumgebung mit Windows

Einklappen

Neue Werbung 2019

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

  • Lokale Entwicklungsumgebung mit Windows

    Hallo Leute!

    Ich arbeite grundsätzlich beruflich mit Mac's und dann entweder über Ports alles selbst installiert (PHP und Built-In Webserver) oder dann VirtualBox, Vagrant, vmware Fusion. Jetzt würde ich gerne wieder einmal unter Windows programmieren... Bzw ich hab keinen privaten Mac.

    Ich hatte VirtualBox/Vagrant mit Ubuntu und NFS und native Filesystem versucht. Das eine schreibt schnell (ich kann composer install machen wueeehhh...), das andere liest schnell (ich kann damit arbeiten bzw caches generieren lassen für Symfony während einem Seitenaufbau usw. wueeeeh). Beides (schnell lesen und schreiben) scheint irgendwie nicht möglich... Eventuell auch vmware Fusion Lizenz kaufen? -.-
    Die Geschwindigkeit war halt nicht berauschend, aber es war ansonsten akzeptabel wenn dann der Cache aufgebaut war und composer install durch war...

    War unter dem Strich aber nicht zufrieden und hab mir dann xampp auf Windows installiert. Es läuft... Ja.... Einigermassen... Hier fehlen mir einfach Tools! Datenbank Verbindung mit PHPMyAdmin, sehr unschön. (Mac = Sequel Pro). Visuelles GIT (Ja PHPStorm bringt was mit, aber ein File zeilenweise zu commiten, kurz den ganzen Tree anschauen, Tags finden usw. usf. das ist sehr umständlich damit) habe ich auch noch keines gefunden (Mac = SourceTree). Dann noch das ganze Line-Brakes gedöns bei Windows und sowieso: Hosting ist ja dann auf Linux. Geschwindigkeit war erstaunlicherweise auch nicht gerade viel besser als bei VirtualBox. Dann natürlich fehlendes GIT mit SSH Keys / Agents usw. Agent Forwarding. Da kommt wieder nur das hässliche Putty...

    Kurzum: Hat jemand ein brauchbares Setup (für Symfony2?) unter Windows in Betrieb? Aktuell überlege ich mir Ubuntu nativ auf einer Partition zu installieren und dann halt beim Booten auswählen wenn ich arbeiten will.
    Nichts hat mich bisher so glücklich wie Mac gemacht um zu entwicklen. PHPStorm / Ports / SourceTree / Terminal mit SSH und GIT / Vagrant oder Built-In WebServer.

    Einen teuren Mac möchte ich mir eigentlich privat nicht anschaffen...


  • #2
    Geht vielleich etwas am Wunsch vorbei, aber wenn das Produktivsystem ein Linux-Server sein soll (was zu 99% der Fall ist) würde ich empfehlen in einer VM mit Linux zu entwickeln, da es zwischen Windows und Linux doch einige gravierenden Unterschiede gibt.

    Hat außerdem den Vorteil, dass man wirklich das selbe Betriebssystem wie der Produktivserver verwenden kann. Das erspart einiges an Testerei und Troubleshooting und vereinfacht das Deployment.

    Kommentar


    • #3
      Nichts hat mich bisher so glücklich wie Mac gemacht um zu entwicklen. PHPStorm / Ports / SourceTree / Terminal mit SSH und GIT / Vagrant oder Built-In WebServer.
      Da biste gefühlt näher an Linux als an Windows. SourceTree Pendant kenn ich keins, aber PHPStorm gibts und bietet ja bereits git support. Ubuntu LTS auf den USB stick ziehen und einfach mal ausprobieren, ob du mit der Oberfläche zurecht kommst/deine Hardware unterstützt wird. Neben unity gibts auch noch Gnome, KDE, Cinnamon u.v.m. Als Bonus bekommste docker, btrfs, ne anständige Paketverwaltung und .. bescheidene WLAN/Grafiktreiber
      I like cooking my family and my pets.
      Use commas. Don't be a psycho.
      Blog - CoverflowJS

      Kommentar


      • #4
        Ich würde einfach einen 2010er MacBookPro kaufen. Dürfte es für unter 500 Euro geben und ist zum Entwickeln super geeignet.

        Gruß

        Claus
        Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

        Kommentar


        • #5
          Hatte das Ausgangsposting nur überflogen, von dem her hier noch ein paar Ergänzungen:

          Datenbank Verbindung mit PHPMyAdmin, sehr unschön. (Mac = Sequel Pro).
          => mysql workbench
          Visuelles GIT (Ja PHPStorm bringt was mit, aber ein File zeilenweise zu commiten, kurz den ganzen Tree anschauen, Tags finden usw. usf. das ist sehr umständlich damit)
          gitk (screenshot)
          eben entdeckt: http://www.syntevo.com/smartgit/

          git graph alias für die shell:
          Code:
          graph = log --graph --all --pretty=format:'%Cred%h%Creset - %Cgreen(%cr)%Creset %s%C(yellow)%d%Creset' --abbrev-commit --date=relative
          Ich würde einfach einen 2010er MacBookPro kaufen. Dürfte es für unter 500 Euro geben und ist zum Entwickeln super geeignet.
          Für 5 Jahre alte Scheiße noch so viel Geld ausgeben - Respekt. Und als Bonus ist die Festplatte noch eine rotierende Scheibe ohne Durchsatz und lahmen Zugriffszeiten. Für das Geld gibts bspw. ne neue skylake CPU (mit integrierter GPU), Motherboard + SSD... Oder ein Chromebook + Cloudserver + Cloud9 IDE für 1 Jahr.
          I like cooking my family and my pets.
          Use commas. Don't be a psycho.
          Blog - CoverflowJS

          Kommentar


          • #6
            Entschuldige bitte wenn ich hier am Thema vorbeirede, ich kann da bei deinem Problem grundlegend nicht mitreden. Aber bin ich in deinem Eintragsbeitrag über "SourceTree", als nur Macprogramm gestolpert. https://www.sourcetreeapp.com/ <- das ist für Windows und nennt sich SourceTree, ist es das was du meintest?

            Liebe Grüße

            Kommentar


            • #7
              Das SourceTree, das du verlinkst ist für Mac und Windows.
              GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

              Kommentar


              • #8
                SourceTree tatsächlich auch für Win zu haben! Danke für die Info. Den Rest probier ich mal durch... Merci fürs Feedback.

                Kommentar


                • #9
                  Kurz ein paar Dinge, die ich unter Windows nutze:

                  SSH-Agent: pageant (ist beim Putty-Installer dabei). Funktioniert mit sehr vielen SSH-Tools. Auch mit den in PHP-Storm integrierten.

                  Remote-Skripte ausführen mit plink (auch beim Putty-Installer bei).

                  Alternative zu Putty: MobaXTerm

                  MySQL: HeidiSQL ("Das Auto"), MySQL Workbench; Bloß kein PHPMyAdmin
                  Remotezugriff auf Mysql via Putty-Tunnel, oder HeidiSSH. Mir ist Heidi sogar sympathischer als SequelPro. Einige meiner Kollegen schwören auf SQLYog.

                  Htdocs: Lokal installierter Xampp (nicht so schnell wie unter OSX oder Linux, tut aber). Anders als viele meinen, ist Groß/Kleinschreibung wirklich kein wesentliches Problem. Die wichtigsten PHP-Erweiterungen sind alle da und PHP7 ist ebenfalls in einer recht aktuellen Version verfügbar. Verglichen mit den Schmerzen, die Vagrant und co. verursachen, ist das wirklich die bessere Alternative.

                  GIT: SourceTree (ja, gibt es für Windows), PHPStorm und TortoiseGIT

                  Texteditor: Ultraedit / Notepad++

                  Taschenrechner: Speedcrunch (bis version 0.10.1)

                  Gesendet von meinem Nexus 6 mit Tapatalk




                  Standards - Best Practices - AwesomePHP - Guideline für WebApps

                  Kommentar


                  • #10
                    Welche Schmerzen verursacht Vagrant denn? Ich hatte noch nie Probleme damit?
                    GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                    Kommentar


                    • #11
                      Wenn du nur wenige, einfache Projekte hast, dann ist alles ziemlich geradeaus. Wenn du allerdings über 50 verschiedene Projekte hast, die unterschiedliche Ausführungsprofile haben (www / shell / service), die du auch nach zufälliger zeitlicher Ordnung ständig schnell öffnen und bearbeiten musst, dann ist ein lokal installiertes XAMPP da besser geeignet.

                      Lass die Diskussion mal umkehren: Welche tatsächlichen Vorteile hat denn Vagrant gegenüber XAMPP? Es geht doch immer nur darum, die gleichen Mittel in der Entwicklungsumgebung zu haben, wie in der Liveumgebung. Zähle mal wirklich alles auf, was du besser mit Vagrant, als direkt unter Windows machen kannst.
                      Btw: Ja, du kannst Varnish in einer VM betreiben und trotzdem das Hauptprojekt mit XAMPP unterhalten.
                      Standards - Best Practices - AwesomePHP - Guideline für WebApps

                      Kommentar


                      • #12
                        Es geht doch immer nur darum, die gleichen Mittel in der Entwicklungsumgebung zu haben, wie in der Liveumgebung.
                        Eben nicht, denn zum Entwickeln braucht man viele Werkzeuge, die man in der Liveumgebung überhaupt nicht benötigt. Das fängt schon mit der IDE an und geht dann weiter mit irgendwelchen Git-Tools, SSH-Agents etc.

                        Die IDE und das Betriebsystem auf dem die IDE läuft brauchen strenggenommen nicht mal PHP oder einen Webserver. Dadurch bleibt die eigene Entwicklungsumgebung erstens schön schlank und zweitens nicht an eine bestimmte Serverkonfiguration, PHP-Version etc. gebunden. Wenn man die Enwicklungsumgebung virtualisiert, dann wird man auch noch vom Betriebssystem und von der Hardware unabhängig. Das parallele Arbeiten mit unterschiedlichen PHP-Versionen, Serverkonfiguartionen etc. wird so zum Kinderspiel.

                        Ein weiterer Vorteil ist, daß die Entwicklungsserver (damit meine ich die Rechner/VMs wo ein Webserver läuft und PHP-Skripte während der Entwicklung ausgeführt werden) bereits während der Entwicklung 100% identisch konfiguriert sein können wie die Produktivsysteme.

                        Zuguterletzt kann es so auch nicht passieren, daß irgendein blöder Skriptfehler einem den ganzen Rechner in die Knie zwingt oder komplett zerschissen kann.

                        VG
                        Jack
                        -

                        Kommentar


                        • #13
                          Ich habe zwar Mac, aber wenn du's auf Windows beziehst:

                          Ich bekomme eine echte Shell ?!
                          GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                          Kommentar


                          • #14
                            Nichts hat mich bisher so glücklich wie Mac gemacht um zu entwicklen.
                            Vergiss den Mac, es geht besser

                            Eine konkrete Empfehlung:

                            - installiere VirtualBox https://www.virtualbox.org/wiki/Downloads
                            - richte für den Anfang zwei VMs ein
                            - VM1/Entwickler-IDE
                            - VM2/Entwickler-Server

                            Konfigurationsvorschlag für VM1

                            - Linux Mint auf Ubuntu-Basis mit Mate-Desktop (schlank, schnell, sehr übersichtlich) http://www.linuxmint.com/edition.php?id=192
                            - PAC als SSH-Client/connection Manager http://sourceforge.net/projects/pacmanager/ (ein wirklich HERVORRAGENDER SSH-Client/Connection Manager, der KEINE Wünsche offen läßt)
                            - PhpStorm
                            - GIT
                            - für SourceTree müßtest Du Dich evtl. nach einer Alternative umsehen (ich glaube das gibt es nur für Win + Mac), evtl. könntest Du direkt vom PAC aus über RDP auf eine Installation auf dem Hostsystem Zugreifen, das sollte eigentlich schnell genug sein

                            Konfigurationsvorschlag für VM2
                            - Eine schlanke Linux-Server-Distribution für Dein Symfony-Projekt. Ich empfehle Debian
                            - PHP + MySQL + Apache etc. (keine Desktopumgebung und natürlich auch keine IDE)


                            Dann richtest Du in VM1 Deine IDE/PhpStorm wie folgt ein:

                            - Die Projektfiles sollten nur auf der lokalen Platte der VM1 liegen, auf keinen Fall ein Netzlaufwerk verwenden, sonst gibt es bei größeren Projekten starke Performaceprobleme wegen git
                            - der PHP-Interpreter wird als Remote-Interpreter konfiguriert
                            - PhpUnit wird ebenfalls "by RemoteInterpreter" konfiguriert
                            - xDebug läuft auch remote
                            - Unter Tools->Deployment->Configuration VM2 als DeploymentServer einrichten und "Automatic Upload" konfigurieren
                            - Es bleibt nur noch der Composer übrig. Der geht leider (noch) nicht per remote. Es gibt aber grundsätzlich zwei Möglichkeiten:

                            1) composer wird lokal in VM1 installiert und lokal ausgeführt
                            2) composer wird nur in VM2 installiert und remote ausgeführt.

                            Zu Möglichkeit 1):
                            Hier sollte man darauf achten, daß sich die lokale PHP-Version von der Remote PHP-Version unterscheiden kann. Das kann dazu führen daß der Composer Bibliotheken installiert, die später auf dem Zielsystem entweder gar nicht oder nicht fehlerfrei laufen. Um das zu verhindern ist ein entsprechende Ergänzung in der composer.json im bereich config->platform unbedingt erforderlich https://getcomposer.org/doc/06-config.md#platform

                            Zu Möglichkeit 2):

                            Wernn der composer remote ausgeführt wird, müssen nach jedem Aufruf (wegen Autocomplete und composer.lock) die remote Vendor-Dateien und die composer.lock mit den lokalen Dateien synchronisiert werden. Dazu kann man sich einfach ein kleines Bash-Skript schreiben welches den composer remote aufruft und die Dateien synct. Das Skript läßt sich dann innerhalb von PhpStorm bequem auf dem Terminal aufrufen.

                            z.b. in der Art (pseudocode, ungetestet)
                            Code:
                            ssh webuser@vm2 cd /var/www/project/ && composer install && \
                            rsync -av --delete --include="/vendor" --include="/vendor/**" --include="/composer.lock" --exclude=* . VM1_PROJECT_PATH/

                            So bleibt man vom Host-Betriebsystem ein für alle Mal unabhängig, kann Snapshots sowohl der Entwicklungsumgebung als auch der Entwicklungsserver per Mausklick erstellen und die Maschinen im Handumdrehen falls gewünscht auf jedem andern Rechner kopieren und unabhängig von der verwendeten Hardware oder Betriebsystem blitzschnell einrichten.

                            Ich arbeite nur noch so und es funktioniert hervorragend. Die VMs sind von "echten" Rechner in der Paxis nicht zu unterscheiden. Performanceeinbußen oder eine träge Entwicklungsumgebung braucht man da bei halbwegs akt. Hardware nicht zu fürchten.

                            VG
                            Jack
                            -

                            Kommentar


                            • #15
                              Zitat von jack88 Beitrag anzeigen
                              Eben nicht, denn zum Entwickeln braucht man viele Werkzeuge, die man in der Liveumgebung überhaupt nicht benötigt. Das fängt schon mit der IDE an und geht dann weiter mit irgendwelchen Git-Tools, SSH-Agents etc.
                              Genau. In einer Entwicklungsumgebung gibt es häufig Komponenten, die es im Livebetrieb nicht gibt. Allerdings gibt es im Live-Betrieb auch häufig Komponenten, die es in der Entwicklungsumgebung so nicht gibt, weswegen viele Teams viel Aufwand betreiben, um ihre Live-Umgebung als virtuelle Maschine nachzubauen und so für die Entwickler eine möglichst wirklichkeitsnahe Umgebung zu schaffen. Es gibt da ein paar Punkte, die durchaus solch eine Umgebung rechtfertigen können. Allerdings sind die allermeisten Projektsituationen damit unnötig kompliziert aufgestellt. Eine virtuelle Maschine bringt nun mal einiges an Overhead mit und die Übertragung von Daten in so eine virtuelle Umgebung ist nun mal nicht so direkt, wie die Arbeit im eigenen Dateisystem.

                              Ich arbeite wohl mit einem Mac, als auch mit Windows und alles wird später auf Linux-Maschinen im Livebetrieb laufen. Die Wahrscheinlichkeit, dass etwas wegen unterschiedlicher Ausführungsumgebungen nicht funktioniert, kann ich für mich heute auf Groß-/Kleinschreibung herunterbrechen und habe da die Erfahrung gemacht, dass es vielleicht 1-2 mal pro Quartal zu Problemen kommt, die darauf zurückzuführen sind. Es gibt zwischen Linux und Windows einen deutlichen Unterschied: Performance und Komponenten, die es nicht für Windows gibt. Beispielsweise HHVM. Wenn du mit Vagrant unter Windows arbeitest, ist die Performance selbstredent quasi so schlecht, als hättest du gleich unter Windows gearbeitet.

                              Das Argument, dass man seine Arbeitsumgebung Plug'n'Play auf eine andere Maschine übertragen kann, ist ein relativ schwaches Argument. Die Identität meiner Dev-Maschine aus PHP-Sicht besteht aus:
                              - Apache-Konfiguration / virtuelle Hosts (dafür habe ich mir ein eigenes Verwaltungstool geschrieben)
                              - PHP-Ini
                              - die eigentlichen Projekte und deren Konfiguration
                              - Lokale MySQL-Datenbanken

                              Alles kein ernstzunehmender Ballast.
                              Standards - Best Practices - AwesomePHP - Guideline für WebApps

                              Kommentar

                              Lädt...
                              X