Frage zu Composer Workflow

[Forumsgast]

Mal angenommen wir hätten folgendes Szenario:

- Produktiv-Server (remote)
- Testing-Server (remote)
- Devel-Server (remote)
- Devel-PC (lokal)

Produktiv- und Testing-Server sollten denke ich soweit klar sein. Der Devel-Server ist der Entwicklungsserver des jeweiligen Entwicklers und der Devel-PC sein lokaler Entwicklungsrechner mit seiner Entwicklungsumgebung.

Der Entwickler entwickelt also lokal auf seinem Devel-PC und nutzt sagen wir mal PhpStorm als IDE. Jede Änderung wird sofort auf seinen Devel-Server übertragen wo er die Möglichkeit hat alles ohne Risiko zu testen. Anschließend kann er seine Änderungen commiten und in ein remote Main-Repository pushen. Auf dem Devel-PC sind deshalb erst mal nur Git und IDE/PhpStorm installiert.

Jetzt kommt der composer ins Spiel. Der Entwickler benötigt nun z.B. Doctrine/ORM in seinem Projekt. Er legt also zuerst eine composer.json Datei an die im einfachsten Fall so aussehen könnte:

{
    "require": {
        "doctrine/orm": "2.4.*"
    }
}

Um Doctrine zu installiern wird jetzt nur noch der Composer benötigt. Den kann man sich ja schnell runterladen und installieren. Alles ganz easy. Der Composer benötigt allerdings dann wiederum php, so daß wir auf dem Devel-PC letzendlich doch php installieren müssen. Ist auch kein Drama.

Mit einem einzigen Befehl ist Doctrine dann mit allen Abhängigkeiten schnell installiert

composer install

Der Entwickler commitet anschließend nur noch die neue composer.json und (ganz wichtig) auch die neue composer.lock in sein Git-Repo und pusht alles ins Main-Repo (die Branching-Strategie lassen wir an dieser Stell mal außen vor).

Auf dem Testing-Server wird die neue Version dann installiert (ich weiß es ist noch keine neue Version, aber tun wir mal so als ob) und dann passiert Folgendes:

our requirements could not be resolved to an installable set of packages.

 Problem 1
    - Installation request for symfony/console 2.7.x-dev -> satisfiable by symfony/console[2.7.x-dev].
    - symfony/console 2.7.x-dev requires php >=5.3.9 -> your PHP version does not satisfy that requirement.
  Problem 2
    - symfony/console 2.7.x-dev requires php >=5.3.9 -> your PHP version does not satisfy that requirement.
    - doctrine/orm 2.4.x-dev requires symfony/console ~2.0 -> satisfiable by symfony/console[2.7.x-dev].
    - Installation request for doctrine/orm 2.4.x-dev -> satisfiable by doctrine/orm[2.4.x-dev].

Was ist hier passiert?

Der Entwickler hatte auf seinem Devel-PC wegen des composeres eine aktuelle PHP Version installiert. Für den Entwickler spielt es auch keine Rolle welche PHP-Version auf seinem Rechner installiert ist, denn er entwickelt ja auf einem Remote-Devel-Server und hat in seiner IDE als PHP-Interpreter den Remote-Interpreter des Devel-Servers eingestellt. Auf allen Servern ist aber eine andere, etwas ältere PHP-Version installiert. Der Composer berücksichtigt beim Installieren der Pakete natürlich ausschließlich die Platform-Informationen des lokalen Devel-PCs des Entwicklers, die Konfiguration der Server-Maschinen kann er ja nicht kennen.

Wie kann der Entwickler also die Pakete mittels Composer so installieren, daß die Systemvoraussetzungen auf den Remote-Servern erfüllt werden?

1) Er könnte versuchen lokal seinen Devel-PC entsprechend zu konfigurieren, spricht z.B. die PHP-Version downgraden. Erstens ist das gar nicht mal so trivial, zweitens was ist wenn er an mehreren Projekten mit unterschiedlichen PHP-Versionen/Serverkonfigurationen arbeiten muss. Also keine praxistaugliche Idee.

2) Er könnte versuchen den Composer entsprechend zu konfigurieren, schlechte Nachricht: GEHT NICHT!

Ok, damit hat sich die lokale Installation vom composer eigentlich schon mal als überflüssig erwiesen, so kann man nicht arbeiten. Was bleibt, ist die Pakete mittels Composer direkt auf einer Maschine zu installieren, die im besten Fall identisch konfiguriert ist, wie der Produktiv-Server.

Zweiter Versuch:

1) composer.json auf lokalem devel-pc anpassen (wird automatisch auf den devel-server hochgeladen)
2) auf devel-server einloggen und composer install/update ausführen

Jetzt haben wir zwar garantiert die richtigen Pakete auf dem devel-server, aber unsere lokale IDE weiß leider noch nichts davon. Auf dem lokalen devel-pc fehlt uns also das akt. Vendor-Verzeichnis (wichtig wg. Autocomplete) und die akt. composer.lock (die wir ins Git-Repo commiten müssen). Es wird also noch ein weiterer Schritt notwendig:

3) Lokales Vendor-Verzeichnis und composer.lock mit remote devel-server syncen

So das war’s.

Allerdings finde ich den Worklflow etwas umständlich. Hat jemand vielleicht eine Idee wie man es besser machen könnte?

vg
jack

[Forumsgast]

Buenos Días

TL;DR: Du hättest diese Probleme nicht, wenn du direkt lokal entwickeln würdest.

Wofür brauchst du einen Remote-Devel-Server? Meinst du damit eine möglichst produktivserver-gleiche Umgebung? Eine komplett lokale Dev-Umgebung hat ein paar Vorteile (und auch ein paar Nachteile).
Vorteile sind: Du kannst offline arbeiten und solltest insgesamt schneller arbeiten können, weil du deine Änderungen nicht immer irgendwo hinpushen musst. Bei mir laufen dann auch noch SASS und gulp im Hintergrund, was so auf einem Remote-Devel-Server schwer zu handhaben wäre. Die Arbeit mit Composer ist in gleichem Maße umständlich. Man kann mittlerweile zwar auch remote Debuggen, z.B. mit xdebug. Das habe ich aber noch nicht probiert.
Nachteile: Deine Umgebung gleicht idR nicht der Produktivumgebung. Bei uns führt das aber nur sehr selten zu Problemen. Eigentlich ist der einzige Grund, dass wir alle unter Windows entwickeln und ab und zu Probleme mit Groß-/Kleinschreibung haben. Das ist ein sehr untergeordnetes Problem und rechtfertigt für uns den Weg über einen externen Dev-Server nicht. Unterschiedliche PHP-Versionen sind (zumindest bei uns) auch kein Thema, da wir immer die aktuelle PHP(5.5)-Version auf dem Liveserver haben. Ich muss mich damit vielleicht etwas beschäftigen und möglicherweise wird die Entwicklung auf einem externen Server für mich interessanter, wenn mehr Fakten dazu vorliegen. Beispielsweise kann man dann auch Kleinigkeiten von unterwegs mit Android/VIM erledigen... Naja, ich schweife ab.

Du brauchst die composer.lock eigentlich nur, wenn du in deiner composer.json nicht explizit deine Versionen festgeschrieben hast - so mache ich es. Beispielsweise "~1.2@stable". So kann es zwar immer noch passieren, dass ich eine 1.2.11 installiere, die einen Bug hat, aber das gleiche kann mir auch in einer local:composer-update/remote:composer-install-Situation passieren. Jenkins merkt es dann. Und mir ist jetzt in knapp 1,5 Jahren nichts nennenswertes passiert. Ich habe bsi mir in Apps und Libs die composer.lock auf ignore.

Anmerkung: Ich beschreibe hier nicht den way it should be sondern nur meine/unsere Arbeitsweise mit Composer.

[Forumsgast]

Buenos Días und danke erst mal für Deine ausführliche Antwort.

TL;DR: Du hättest diese Probleme nicht, wenn du direkt lokal entwickeln würdest. Wofür brauchst du einen Remote-Devel-Server? Meinst du damit eine möglichst produktivserver-gleiche Umgebung?

Ja der Remote-Devel-Rechner ist wie der Produktiv Rechner konfiguriert. Ich kann so bequem von allen möglichen lokalen Rechnern die ich benutze (Büro, zu Hause, Laptop, … + OS Win, Mac , Linux) darauf zugreifen und muss auf den lokalen Rechner im Prinzip nur die IDE installieren und einmal die Repos klonen und dann up-to-date halten. Also entwicklerseitig absolut minimaler Konfigurationsaufwand .

Auf diese Weise kann ich auch relativ einfach Projekte z.B. auf eine neue PHP Version migrieren ohne an meinen lokalen Rechnern irgendwas umkonfigurieren zu müßen. Dazu würde ich nur einen neuen Remote-Devel-Server-PHP-X.Y.Z aufsetzen, einen neuen Branch im Repo anlegen upgrade/php-5.x.x und ein neues lokales Projekt anlegen, das mit dem neuen Devel-Server verknüpft ist. Dann kann ich von einem lokalen Rechner bequem an einem Upgrade arbeiten und mit beliebig vielen Projekt/PHP-Versionen parallel arbeiten. Ich denke, das macht schon Sinn. Debuggen kannst Du remote auch und PhpUnit geht remote auch, ist also alles kein Problem.

Der einzige nennenswerte Nachteil ist das etwas umständliche Handlig mit dem Composer. Das wurde auch schon hier und da diskutiert, aber getan hat sich bis heute leider nichts (fast nichts).

Du brauchst die composer.lock eigentlich nur, wenn du in deiner composer.json nicht explizit deine Versionen festgeschrieben hast - so mache ich es. Beispielsweise "~1.2@stable".0

Da muss ich Dir entschieden widersprechen, auch wenn es bei Euch noch nie in dieser Hinsicht Probleme gegeben hat. Die composer.lock gehört auf jeden Fall ins Repo. Nur mit Hilfe der composer.lock wird ein exakter Versionsstand/Snapshot Deines Projektes samt aller Abhängigkeiten überhaupt erst möglich. Auch beim Deployen auf den Produktivserver sollte man niemals mit composer update arbeiten. Das halte ich für sehr wichtig. Auch Rollbacks zu einem beliebigen älternen Versionsstand werden so, sehr einfach und zu 100% zuverlässig möglich.

vg
jack

[Forumsgast]

Ja, das hatte ich früher auch so. Früher. Seit langer Zeit habe ich auf meine Dev-Umgebung gar nicht mehr zugegriffen. Heute verwende ich für dies Vagrant. Damit kann ich mir ein OS holen, dass

1. für alle gleich ist
2. über auf jedem Gerät eine gleiche Umgebung schafft (auch wenn ich Projekte übergeben muss)
3. sehr einfach initialisiert ist

Damit hole ich ziemlich einfach alles raus, was mein Dev-Server eben nicht konnte. Ich kann auch aus dem Zug Unit-Tests rennen lassen, Software testen etc... Und ich brauche mein Host-OS nicht einmal zu verschandel .

[Forumsgast]

Heute verwende ich für dies Vagrant. Damit kann ich mir ein OS holen, dass

Ja, das wäre auch bei mir jederzeit so problemlos möglich. Alles ist sowohl serverseitig (kvm) als auch clientseitig (virtualbox) virtualisiert.

Das ändert aber nichts an dem grundsätzlichen Problem, es sei denn Du entwickelst direkt innerhalb der Dev-Server-Vagrant-VM. Bei mir sind es sozusagen immer zwei VMs, die könnten auch durchaus lokal liegen:

- IDE-VM (hier habe ich meien Editor und andere Werkzeuge die ich zum Entwickeln so brauche, die ich aber nicht auf meinem Server haben will) und
- Devel-VM (ob lokal oder remote, ist eigentlich egal, hier ist der Webserver + php + mysql +.... + Projekt installiert)

Damit könnte ich dann auch lokal im Zug arbeiten , aber das Problem mit dem composer wird weiterhin bleiben. Ich möchte meine Serverumgebung halt nicht mit der Entwicklungsumgebung vermischen/verunreinigen. Auf demServer sollen nur die Pakete und Dienste installiert sein, die der Server unbedinngt benötigt, sonst nichts.

vg
jack

[Forumsgast]

Mit Vagrant hättest du das Problem tatsächlich aber nicht. Das ist eben nicht das gleiche, wie die Umgebung, die du jetzt hast. Vagrant stellt einen echten lokalen Ordner bereit, auf dem du dann arbeitest.

[Forumsgast]

Ich halte es, aus Erfahrung, für gefährlich, einen zentralen Dev-Server bereitzustellen, auf dem mehrere Entwickler gleichzeitig arbeiten. Einen Staging-Server ist da logischerweise etwas anderes. Für die Entwicklung finde ich soll alles lokal sein. Heutzutage ist jeder Rechner fähig, eine oder mehrere VMs gleichzeitig laufen zu lassen. Du könntest auch auf dem Server mit Vagrant (oder dann KVM) Boxen laufen lassen, wo jeder Entwickler seine eigene Umgebung hat.

Den grössten Vorteil sehe ich darin, dass du mit einer Pro-Projekt-Virtualisierung (egal wo) auch spezialisierte OS anbieten kannst. Ein Projekt läuft auf PHP 5.4 mit MySQL 5.5 und ein anderes mit PHP 5.5 und MySQL 5.6, ein drittes vielleicht dann mit PG. Wenn du auf dem Dev-Server alle Versionen gleichzeitig anbieten willst wird das irgendwann unübersichtlich und schwer wartbar.

Aus welchem Grund ist die IDE eigentlich in einer VM?

[Forumsgast]

Mit Vagrant hättest du das Problem tatsächlich aber nicht.....Vagrant stellt einen echten lokalen Ordner bereit, auf dem du dann arbeitest.

Wieso sollte ein lokaler Ordner etwas an dem Problem ändern?

Ich halte es, aus Erfahrung, für gefährlich, einen zentralen Dev-Server bereitzustellen, auf dem mehrere Entwickler gleichzeitig arbeiten.

Nein, so arbeiten wir nicht, das wäre wirklich nicht gut Alle Server, aber auch alle lokalen Arbeitsumgebungen sind VMs. Es gibt einen Produktiv-Server-VM, einen Testing/Staging-Server-VM und jeweils (mindestens) 1xDevelop-Server-VM/Entwickler.

Aus welchem Grund ist die IDE eigentlich in einer VM?

Warum nicht? Wenn ich meine Arbeitsumgebung auf einem anderen Rechner brauche, dann kopiere ich einfach nur die VM und alles ist im Handumdrehen eingerichtet und fertig konfiguriert. Wenn mir irgendein Rechner plötzlich den Geist aufgibt, dann kopiere ich nur das VM-Image (natürlich habe ich davon auch Backups...) auf irgendeinen anderen Rechner und kann wie gewohnt sofort weiterarbeiten. Das ist wirklich ein Segen

vg
jack

[Forumsgast]

Ich könnte mir das überhaupt nicht vorstellen, primär mit Programmen in einer VM zu arbeiten. Schon alleine, weil alle Entwickler bei uns mehrere Monitore haben... Bei uns ist auch alles KVM virtualisiert (Staging/Prod). Aber ich würde echt nie auf die Idee kommen, auch die Dev-Umgebung zu virtualisieren. Ich empfinde ja Vagrant schon als eine Einschränkung, weswegen wir noch immer nicht auf HHVM entwickeln . Eine Stagingumgebung reicht doch vollkommen zum testen oder nicht?

Naja, jeder, wie er es braucht. Es gibt auch Leute, die mir weiß machen wollen, sie wären mit VIM wesentlich produktiver als mit etwas schrägem wie PHPStorm. Das sind Leute, die es einfach nur cool finden, mit etwas so esoterischem wie VIM toll und schnell navigieren zu können, was überhaupt keinen Bezug zur tatsächlich und vergleichbaren Produktivität mit einem anderen Tool hat. Nichts gegen VIM!

[Forumsgast]

Ich könnte mir das überhaupt nicht vorstellen, primär mit Programmen in einer VM zu arbeiten. Schon alleine, weil alle Entwickler bei uns mehrere Monitore haben...

Wo liegt das Problem, ich arbeite in einer VM auch an mehreren Monitoren? Auf meinem Mac habe ich z.B. 3 Betriebsysteme Mac, Windows und Linux die ich parallel nutzen kann und zwischen denen ich jederzeit per Tastaturkürzel switchen kann – das ist genial

Aber ich würde echt nie auf die Idee kommen, auch die Dev-Umgebung zu virtualisieren.

Warum, was stört Dich daran? Was spricht hier aus Deiner Sicht gegen Virtualisierung?

vg
jack

[Forumsgast]

Ich kann hier die Ansicht von rkr nachvollziehen. Ich kenne die Möglichkeiten zur Virtualisierung unter Mac (z.B. mit Parallels) auch. Allerdings sehe ich im Bereich IDE-Virtualisierung den Vorteil wirklich nicht. Gerade phpStorm bietet die einfache Möglichkeit, Einstellungen zu exportieren und zu importieren. Das funktioniert auch gut. Zudem, gerade wenn du den Mac ansprichst, falls dir dieser abkratzt: TimeMachine anwerfen und am neuen Mac innerhalb 1h auf den letzten Stand installiert. Sowas würde man dann Backup nennen - und ist primär dafür da, Rechner, die abkratzen innert kürzester Zeit zu ersetzen. Wenn ich nur die VM kopiere ist ja das Basissystem auch nicht eingerichtet - mich würde das nerven.

[Forumsgast]

Naja, ich kann hier gerade nur meine persönliche Meinung wiedergeben. Irgendwie wirkt es auch mich nicht optimal, wenn eine Applikation auf nur genau einer Umgebung entwickelt und getestet wird. Wenn ein Rechner einen Totalschaden erleidet, dann brauche ich 2-3 Std um alles Essentielle wieder einzurichten. Keine Ahnung. Vielleicht ist auch alles vollkommen ok so, wie du es machst und es macht nachher praktisch keinen Unterschied wie man es macht. Ich habe nur diese von dir angesprochenen Probleme (weswegen du diesen Thread eröffnet hast) nicht.

[Forumsgast]

Zudem, gerade wenn du den Mac ansprichst, falls dir dieser abkratzt: TimeMachine anwerfen und am neuen Mac innerhalb 1h auf den letzten Stand installiert.

Das letzte Mal war das Ding wegen einem Display-Schaden 3-4 Wochen weg, hätte auch ein Ersatzgerät bekommen können (muss ich ehrlicherweise auch zugeben), wollte es aber nicht mal, da ich eh normalerweise in einer Linux-VM arbeite. Mac brauche ich eigentlich nur wegen iOS und Windows wegen einiger andere Programme und bevor ich mir hier drei Rechner hinstelle, da installiere ich lieber ein paar VMs die das Gleiche tun. Mit Parallels arbeite ich übrigens nicht.

Gerade phpStorm bietet die einfache Möglichkeit, Einstellungen zu exportieren und zu importieren. Das funktioniert auch gut.

Ja ich weiß, aber ich habe natürlich nicht nur PhpStorm drauf, da sin noch SSH-Keys, Connect-Manager, VMM-Mager, RDP-Clients, VPN-Connection etc. das kostet mich einen ganzen Tag um das alles wieder komplett einzurichten

Wir können das Thema Virtualisierung aber auch gerne wieder ganz vergessen, das ist bei dem o.g. Problem auch irrelevant.

vg
jack

[Forumsgast]

Desktop virtualisieren und du hast keins der Probleme, du richtest das einmal ein ( für alle ) und klonst die Desktops für den jeweiligen User, später kannst du dort auch updates einspielen ( in alle Desktops ) wenn notwendig.

Dev-Stages sind lokal, dev-server machen nur Sinn, wenn ihr Development-Snapshots braucht "vor" dem Test-Stage benötigt, weil Test-Stages bspw. durch Cache-files die Resource Integrität des Projekt-Repository verletzen könnte oder ihr euch ein "Application Warm-up after commit" sparen wollt.

[Forumsgast]

Desktop virtualisieren und du hast keins der Probleme

Inwiefern spielt Virtualisierung hier eine Rolle?

Dev-Stages sind lokal...

Was genau verstehst Du unter einem lokalen Dev-Stage und wieso ist das wichtig?

Man entwickelt entweder direkt auf einem Dev-Server/PC (lokal oder remote), dann braucht man auf der Maschine eben die komplette Entwicklungs- und Serverumgebung (Desktop/GUI, IDE, Browser, PHP, DB, Webserver), oder man unterscheidet zwischen einem (meist lokalen) Entwickler-PC (Desktop/GUI, IDE, Browser, kein php, kein Webserver, keine DB) und einem Dev-Server (PHP, Webserver, DB, kein GUI, kein Browser, keine IDE) .

Ich halte eine Trennung zwischen Entwicklungsumgebung und Dev-Server aus verschieden Gründen für sinnvoll:

- Paralleles Arbeiten von einem Entwickler-PC an beliebig vielen Projekten mit unterschiedlichen PHP-Versionen, Webserver-Konfigurationen und Datenbanken/Datenbankversionen
- Die Konfiguration/Pakete des Entwickler-PCs beeinflusst nicht die Konfiguration des Dev-Servers und umgekehrt genau so
- Der Dev-Server entspricht beinahe einem 100%-Klon des Produktiv-Servers, daraus ergeben sich weitere Vorteile beim Debuggen, evtl. Fehler aufgrund unterschiedlicher Server-Konfigurationen sind damit so gut wie ausgeschlossen und werden nicht erst auf dem Testing-server sichtbar.

In Verbindung mit Virtualisierung ergeben sich dann noch eine Reihe weiterer Vorteile, insbesondere dann wenn man an mehreren PC und/oder mit unterschiedlichen Betriebssystemen arbeiten muss.

All diese Vorteile hat man nicht wenn man lokal auf einer Dev-Maschine arbeitet, auf der alles (GUI, IDE, PHP, DB, Webserver etc.) installiert ist. Daran ändert auch nichts wenn man die Dev-Maschine innerhalb einer Vagrant-Box/VM eingerichtet hat (was sicherlich die bessere Alternative ist).

vg
jack