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

  • mYkon
    hat ein Thema erstellt Lokale Entwicklungsumgebung mit Windows.

    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...

  • jack88
    antwortet
    Genau die Provisionierung nimmt einem docker oder vagrant ab. Egal, ob docker oder vagrant, du kannst bspw. das image automatisiert neu bauen und musst dafür nur ein Text-File zwischen den Rechnern syncen. Oder das build file ins Repo committen und die Arbeitsumgebung ist bei allen Kollegen die gleiche. Darüber lässt sich auch einfach das komplette Image ziehen, so dass man das auch nicht selbst bauen muss.
    Das macht die ganze Sache sicherlich noch angnehmer. Man muss sich allerdings zuerst ein wenig mit Vagrant/Docker beschäftigen bevor man loslegen kann. Da in meinem Fall alle Server ohnehin virtualisiert sind, kann ich auf die automatische provisionierung verzichten. Ich kopiere einfach das Image des Live-Servers, passe es ein wenig an und die Sache ist erledigt.

    Nativ auf dem Hostsystem oder nur mit geringem Overhead (docker unter Linux) zu entwickeln ist schon deutlich performanter/flexibler als mithilfe einer VM.
    Ja, allerdings ist das - zumindest für mich - nicht wichtig. Solange die komplette Entwicklungsumgebung Ruckelfrei und ohne spürbare Verzögerungen läuft, kann ich mit einer etwas schlechteren Performance gut leben. Ob das Hostsytem im Vergleich zur VM nun 100 oder 1000 Requests/Min mehr schafft ist mir während des Entwicklung egal. Der Performacefaktor wird sowieso oft überbewertet. Die meisten Server nutzen ohnenhin nur einen Bruchteil der zur Verfügung stehenden Resourcen. Virtualisierung kostet Performance, aber Virtualisierung hilft gleichzeitig auch die Rechnerresourcen besser zu Nutzen. Nachdem wir bei uns alle Server virtualisiert haben, hat sich die Anzahl der dedizierten Maschinen glatt halbiert und wir haben immer noch Luft nach oben. Ja die Performance hat sich ein wenig verschlechtert, die Backups Nachts brauchen jetzt ein paar Minuten länger

    Wenn du deinen Projektcode in der VM persistierst, in der alle Dienste laufen, hast du zwar das Problem der Synchronisierung umschifft, aber gibst einiges an Flexibilität auf. Unit tests unter verschiedenen PHP-Versionen/VMs bspw.
    Das alles ist möglich, nur das ich dafür dann jeweils eine neue VM brauche. Da sich eine VM per Mausklick klonen läßt, sehe darin kein großes Problem. Bei einem Upgrade von z.B. squeeze auf wheezy gehe ich so vor, dass ich zuerst ein Upgrade-Branch erstelle, dann checke ich diesen Branch in einem neuen Projekt aus und verknüpfe dieses Projekt anschließend mit der neu erstellten Wheezy-VM. So kann ich am demselben Projekt gleichzeitug unter Squeeze und Wheezy arbeiten. Wäre möglich, daß es mit Docker noch deutlich eleganter und performanter geht, das kann ich nicht beurteilen. Ich denke jedoch, daß Docker vielen Entwicklern noch recht unbekannt sein dürfte und deshalb für viele anfangs eine Hürde darstellen könnte. Es geht in erster Linie ja auch um das Konzept an sich und nicht so sehr um die Wahl der konkreten Software dahinter. Wobei Docker in diesem Zusammenhang mit Sicherheit eine sehr spannende Sache ist.

    VG
    Jack

    Einen Kommentar schreiben:


  • rudygotya
    antwortet
    Zitat von ChristianK
    Vagrant ist eine leichtgewichtige VM, das heist, weniger Speicherverbrauch. Siehe z.B. die Infografik am Ende hier: https://www.scriptrock.com/articles/docker-vs-vagrant
    Nö, Vagrant ist nur ein Provisionierungs- und Verwaltungstool für virtuelle Maschinen, die meisten Boxen, die ich kenne, setzen auf Virtualbox auf. Wenn ich das mal salopp runterbrechen darf, dann unterhaltet ihr euch da über den Unterschied zwischen dem Persistieren von Projektdaten in der VM und dem Synchronisieren über nfs/smb.

    Zitat von jack88
    In meinem Fall verhält es sich so, daß ich in der Firma an einem Win-Pc und einem Win-Laptop arbeite und zuhause mit iMac und Macbook. So müßte ich meine Entwicklungswerkzeuge insgesamt vier mal auf zwei verschiedenen OS einrichten. Außerdem arbeite ich weder mit Mac OS noch mit Windows wirklich gerne. Warum also nicht gleich alle die Entwicklungswerkzeuge einmal in eine schicke Linux-VM packen und bei bedarf auf so viele Rechner kopieren wie nötig.
    Genau die Provisionierung nimmt einem docker oder vagrant ab. Egal, ob docker oder vagrant, du kannst bspw. das image automatisiert neu bauen und musst dafür nur ein Text-File zwischen den Rechnern syncen. Oder das build file ins Repo committen und die Arbeitsumgebung ist bei allen Kollegen die gleiche. Darüber lässt sich auch einfach das komplette Image ziehen, so dass man das auch nicht selbst bauen muss.

    Zitat von jack88
    Wer glaubt, daß sich das alles irgendwie langsam, oder indirekt anfühlt, der sollte es einfach mal selbst ausprobieren.
    Nativ auf dem Hostsystem oder nur mit geringem Overhead (docker unter Linux) zu entwickeln ist schon deutlich performanter/flexibler als mithilfe einer VM. Wenn du deinen Projektcode in der VM persistierst, in der alle Dienste laufen, hast du zwar das Problem der Synchronisierung umschifft, aber gibst einiges an Flexibilität auf. Unit tests unter verschiedenen PHP-Versionen/VMs bspw. Oder ein Update des Host-Systems von debian squeeze auf wheezy. Oder mal eben MariaDB anstelle von MySQL ausprobieren... Im docker-compose file ist das ein Unterschied von einer Zeile. Und damit man nicht jedesmal die Daten synchronisieren muss, einfach ein docker-volume einhängen P.S.: Mit docker machine lässt sich docker auch unter Windows oder Mac betreiben (auch ein Virtualbox Aufsatz, jedoch mit sehr schlanker VM).

    Einen Kommentar schreiben:


  • jack88
    antwortet
    Zitat von rkr Beitrag anzeigen
    Mal anders gefragt: Wenn du direkt unter Linux arbeiten würdest (Hauptsystem = Linux), das ähnlich eingerichtet ist, wie der Live-Server, würdest du selbst dann noch in einer VM arbeiten? Wenn ja: Warum?
    Ich kann mir ehrlich gesagt kein Szenario vorstellen wo ein Server ähnlich konfiguriert wäre wie eine IDE oder umgekehrt? Ich wüßte nicht wofür sowas gut wäre.

    Eine Entwicklungsumgebung besteht für mich grundsätzlich aus

    - Entwicklungswerkzeugen
    - Ausführungsumgebung

    Während die Entwicklungswerkzeuge innerhalb eines System i.d.R. gut koexistieren können, benötigen Ausführungsumgebungen oft jeweils ein eigenes System. Man kann mit dem gleichen Editor durchaus Programme für mehrere Sprachen schreiben, aber man braucht oft unterschiedliche Ausführungsumgebungen um diese Programme auszuführen.

    Ich arbeite z.B. viel mit PHP und Bash, als Editor verwende ich für Beides den PHPStorm. Es ist nicht so wichtig auf welchem System ich die Programme schreibe (Win/Mac/Linux), aber ich kann z.B. keine Bashskripte unter Windows ausführen. Sollte ich jetzt wegen Bash einen weiteren Rechner einrichten und dann nachmal alle die Entwicklungswerkzeuge installieren?

    Und die Sicherheit? Bashskripte z.B. benötigen oft Rootrechte, da kann schon ein „kleiner“ Fehler fatale Folgen für das gesamte System haben.

    Und wie sieht es mit Migrationen aus, z.B. auf eine neue PHP-Version? Mehrere PHP-Versionen, Datenbanken... alles in einer Ausführungsumgebung, wie soll das gehen?

    Nein, Ausführungsumgebung und Entwicklungswerkzeuge parallel auf einem System, das ist keine gute Idee. Da wird nichts einfacher oder besser. Eine solche Arbeitsweise bietet aus meiner Sicht absolut keine Vorteile.

    Um einen flexiblen IDE-Workflow zu realisieren bietet es sich deshalb an auf Virtualisierung zurückzugreifen. Dazu muss man lediglich eine Virtualisierungssoftware installieren und zumindest die Ausführungsumgebungen virtualisieren. Dabei muss man natürlich nicht gleich für jedes Projekt eine eigene Ausführungsumgebung erstellen. Wenn nichts dagegen spricht, dann können sich mehrere Projekte natürlich eine VM teilen, aber wenn ein Projekt es erfordert, dann hat man die Flexibilität dieses Projekt jederzeit in einer anderen, angepassten Ausführungsumgebung weiter zu entwickeln und zwar ohne an dem restlichen System mit Entwicklungswerkzeugen irgendetwas ändern zu müssen.

    Ob man die Entwicklungswerkzeuge selbst, direkt auf dem Host installiert oder in einer VM, hängt ganz von den persönlichen Anforderungen ab.

    In meinem Fall verhält es sich so, daß ich in der Firma an einem Win-Pc und einem Win-Laptop arbeite und zuhause mit iMac und Macbook. So müßte ich meine Entwicklungswerkzeuge insgesamt vier mal auf zwei verschiedenen OS einrichten. Außerdem arbeite ich weder mit Mac OS noch mit Windows wirklich gerne. Warum also nicht gleich alle die Entwicklungswerkzeuge einmal in eine schicke Linux-VM packen und bei bedarf auf so viele Rechner kopieren wie nötig. Damit habe ich unabhängig von dem verwendeten Host-OS auf jedem Rechner immer eine identische, vertraute Entwicklungsumgebung und nur noch ein OS mit dem ich mich ggf. herumärgern muss Wer glaubt, daß sich das alles irgendwie langsam, oder indirekt anfühlt, der sollte es einfach mal selbst ausprobieren.

    VG
    Jack

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    Zitat von rkr Beitrag anzeigen
    [...]
    Mal anders gefragt: Wenn du direkt unter Linux arbeiten würdest (Hauptsystem = Linux), das ähnlich eingerichtet ist, wie der Live-Server, würdest du selbst dann noch in einer VM arbeiten? Wenn ja: Warum?
    Meine Antwort zu dieser Frage: Ja. Denn ich will mein Hostsystem clean halten. Alles "experimentieren" geht in eine VM.

    Einen Kommentar schreiben:


  • rkr
    antwortet
    Zitat von Ulfikado Beitrag anzeigen
    rkr Das mit den bis zu 50 Projekten am Tag nehme ich Dir nicht ab, sofern Du auf Arbeit einen ordentlichen Entwicklungsworkflow hast.
    Das habe ich oben doch erklärt. Genauer: Ich habe (es sind tatsächlich sogar mehr als) 50 Projekte, die ich in zufälliger Reihenfolge öffne und bearbeite. Je nach dem, wo gerade Änderungen anstehen. Normal brauche ich am Tag nicht mehr als 5 bis 6 Projekte. Es ist alles immer da. Muss nur die virtuelle Domain aus der Lesezeichenleiste aufrufen und zack - alles da. Ohne VM. Es mag Szenarien geben, wo man erst mit einer VM bestimmte Ziele erreicht. Ich richte mein System im Schnitt alle 2 Jahre neu ein. Die zwei Stunden, die ich für die Einrichtung mehr brauche, sind da unwesentlich...

    Zitat von jack88 Beitrag anzeigen
    In einer virtuellen Umgebung abreitet man doch genau so direkt im eigenen Dateieinsystem? Die Daten liegen nur in der virtuellen Umgebung, da muss nicht dauernd was übertragen werden.
    Mal anders gefragt: Wenn du direkt unter Linux arbeiten würdest (Hauptsystem = Linux), das ähnlich eingerichtet ist, wie der Live-Server, würdest du selbst dann noch in einer VM arbeiten? Wenn ja: Warum?

    Einen Kommentar schreiben:


  • Ulfikado
    antwortet
    rkr Das mit den bis zu 50 Projekten am Tag nehme ich Dir nicht ab, sofern Du auf Arbeit einen ordentlichen Entwicklungsworkflow hast.

    Mal davon ausgehend das man bei Kleinkram durchschnittlich pro Projekt ~10 Minuten braucht um Codeänderungen zu machen (selbst wenn da nen paar ausreisen mit 5 minuten dabei sind, egal), das die Unittests dafür nochmal mindestens genau so lange brauchen und dann noch die Änderungen commiten und im Browser/CLI/... testen auch nochmal 10 Minuten sind das rund 30 Minuten pro Projekt. Das sind summa summarum 25h Arbeitszeit pro tag.

    Respekt!

    selbst bei nur 20 minuten sind das immer noch 16 2/3 Stunden am Tag.

    DU scheinst ein guter Burnout-Kandidat zu sein.

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    Zitat von hellbringer Beitrag anzeigen

    Ehrlich gesagt kenne ich das nicht mal. Ich bin von dem einfachen Fall ausgegeben, dass man mit einer VM arbeitet. Wozu die Dinge komplizierter machen, als sie sind?
    Vagrant ist eine leichtgewichtige VM, das heist, weniger Speicherverbrauch. Siehe z.B. die Infografik am Ende hier: https://www.scriptrock.com/articles/docker-vs-vagrant

    Zitat von jack88 Beitrag anzeigen

    Soll das heißen, daß vor jedem einzelnen Request zuerst ein Datensync ausgeführt wird? Das wäre ja der totale Overhead.

    Ich habe gerad kurz auf der Vagrant-Website nachgesehen. Wenn ich es richtig verstehe läßt sich der Sync auch deaktivieren. Also wenn sich files innerhalb einer Vagrant-Box persistent ablegen lassen, dann kann man sich den Sync-Prozess doch komplett sparen, je nachdem wie man arbeitet bzw. die eigene Entwicklungsumgebung konfiguriert ist der Syncprozess überflüssig.

    VG
    Jack
    Nein, nicht vor jedem Request. Entweder via NFS/SMB als Netzlaufwerk, d.h. die Ressourcen werden über das Netzwerk eingebunden oder dann via rsync, wobei da vermutlich jede Änderung synchronisiert wird. Es kann durchaus sein, dass du den Sync nicht benötigst. Ich könnte den aus meinem Arbeitsprozess nicht wegdenken, bzw. jede Änderung würde mehr Overhead bedeuten. Zudem erhält man ja keinen Nachteil [auf Linux oder Mac] durch den Sync-Prozess.

    Einen Kommentar schreiben:


  • jack88
    antwortet
    Zitat von ChristianK Beitrag anzeigen
    Die Synchronisation ist/muss live (sein)?
    Soll das heißen, daß vor jedem einzelnen Request zuerst ein Datensync ausgeführt wird? Das wäre ja der totale Overhead.

    Ich habe gerad kurz auf der Vagrant-Website nachgesehen. Wenn ich es richtig verstehe läßt sich der Sync auch deaktivieren. Also wenn sich files innerhalb einer Vagrant-Box persistent ablegen lassen, dann kann man sich den Sync-Prozess doch komplett sparen, je nachdem wie man arbeitet bzw. die eigene Entwicklungsumgebung konfiguriert ist der Syncprozess überflüssig.

    VG
    Jack

    Einen Kommentar schreiben:


  • hellbringer
    antwortet
    Zitat von ChristianK Beitrag anzeigen
    Dir ist bekannt wie Vagrant funktioniert? Ich möcht hier nicht das Manual vorlesen...
    Ehrlich gesagt kenne ich das nicht mal. Ich bin von dem einfachen Fall ausgegeben, dass man mit einer VM arbeitet. Wozu die Dinge komplizierter machen, als sie sind?

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    Dir ist bekannt wie Vagrant funktioniert? Ich möcht hier nicht das Manual vorlesen...

    Einen Kommentar schreiben:


  • hellbringer
    antwortet
    Zitat von ChristianK Beitrag anzeigen
    Die Synchronisation ist/muss live (sein). Denn du arbeitest ja und testest den Code. Wenn du den Sync abstellst, hast du ja gar keine Daten in der VM?
    Warum nicht direkt die Daten in der VM bearbeiten? Wozu die Herumsynchronisiererei?

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    Die Synchronisation ist/muss live (sein). Denn du arbeitest ja und testest den Code. Wenn du den Sync abstellst, hast du ja gar keine Daten in der VM?

    Einen Kommentar schreiben:


  • jack88
    antwortet
    Verstehe, ich arbeite nicht mit Vagrant, deshalb kenne ich das Problem so nicht. Wie oft wird da eingentlich synchronisiert, beim Hochfahren, vor jedem Request? Läßt sich das Synchronisieren nicht einstellen oder komplett abschalten, oder werden die Daten nach Shutdown jedes Mal komplett gelöscht?

    Bei mir läuft die Entwicklungsumgebung (nur IDE + Entwicklungstools + alle erforderlichen Keys etc.) in einer eigenen Virtualbox-VM und der/die Entwicklungsserver in einer anderen Virtualbox-VM. Die VMs werden einmal komplett eingerichtet und behalten dann ihre Daten. Um Synchronisation muss ich mich nicht weiter kümmern, weil jede Codeänderung in PhpStorm unmittelbar auf den Entwicklungsserver übertragen wird.

    VG
    jack

    Einen Kommentar schreiben:


  • ChristianK
    antwortet
    jack88 Bei Vagrant liegen die Daten Hostdateisystem und werden synchronisiert mit der virtuellen Maschine (via rsync, ntfs, ...; konfigurierbar). Das führt insbesondere bei grossen Projekten oder gar bei der Symfony-Standardinstallation unter gewissen Hostsystemen (sagen wir, Windows) zu extremen Performanceeinbrüchen (Ladezeit >15 Sekunden pro Seite).

    Einen Kommentar schreiben:

Lädt...
X