Warum sollte ich „Composer Update“ niemals in der Produktion ausführen?

composer install wird installiert, wann immer es in der angegeben ist composer.lock Datei, aber composer update aktualisiert alle Abhängigkeiten und erstellt eine Neu composer.lock Datei basierend auf den Anforderungen in composer.json.

So viele sagten, nur laufen composer update in Entwicklung. Aber meine Frage tut composer update habe die alte ersetzt composer.lock Datei, wenn Ihre App kaputt geht, wird sie kaputt gehen, weil es Konflikte mit den neuen aktualisierten Abhängigkeiten geben könnte.

Ich bin auf eine Situation gestoßen, in der ich tun muss composer updatebezieht sich das Problem auf pcntl Verlängerung. Die einzige Lösung ist zu tun composer update Installation des PHP-PCNTL-Moduls

Ich verstehe nicht, warum Menschen Angst vorm Laufen haben composer update auf die Produktion.

TLDR;

Renne nicht composer update Noch composer install in Produktion. Führen Sie es woanders aus und laden Sie das Ergebnis auf den Produktionsserver hoch, aber nicht in dasselbe Verzeichnis, in dem die Anwendung gehostet wird. Als allgemeine Regel sollten Sie die bereitgestellte Anwendung nicht ändern während es wird serviert. Erstellen Sie eine andere Kopie der Anwendung und ersetzen Sie sie, wenn sie fertig ist, durch einen möglichst sofortigen Befehl (z mv oder ln -s).

Aber wenn man auch laufen MUSS: immer laufen install und erstellen Sie eine neue Installation; und niemals update. install ist vorhersehbarer und zuverlässiger, mit update Sie sind den Abhängigkeiten des Projekts ausgeliefert.

Composer arbeitet rekursiv. Also selbst wenn Sie sehr strenge Versionseinschränkungen in Ihrer haben composer.jsondurch Laufen composer update Sie würden nicht nur Ihre Abhängigkeiten aktualisieren, sondern auch die Abhängigkeiten Ihrer Abhängigkeiten.

Während meistens dies wird keinen Bruch einführen, manchmal es wird. Eine Abhängigkeit auf der ganzen Linie kann eine Verhaltensänderung einführen, die Ihren Code auf eine Weise beeinflussen kann, gegen die Sie möglicherweise nicht getestet haben.

Außerdem wird im Grunde das falsche Werkzeug für den Job verwendet. Composer ist ein Abhängigkeitsverwaltungstool, kein Bereitstellungstool. Um Ihren Code für die Produktion bereitzustellen, sollten Sie eine Art Code-Bereitstellungstool verwenden (auch wenn dieses „Tool“ so einfach ist wie ein FTP-Upload und ein paar Skripts).

Der passende Ablauf ist:

• Mach das alles require und update ruft Ihre Entwicklungsmaschine auf, wo Sie das Projekt ohne Risiko testen können. Dadurch entsteht ein composer.lockwas ein bekannter Zustand für das gesamte Projekt ist, mit einzelnen installierten Versionen.
• Ein … kreieren Neu installierbare Version tun install --no-dev. Bei diesem Schritt sollten Sie auch einen optimierten Autoloader ausgeben, After-Install-Skripte ausführen usw. Normalerweise trenne ich dies in mehr als einem Schritt:

1. composer install --prefer-dist --no-scripts --no-progress --no-suggest --no-interaction --no-dev:

   ^^ Dies für eine vollständige, unbeaufsichtigte Installation von allem, ohne Entwicklungsabhängigkeiten.

2. composer dump-autoload --optimize --no-dev

   ^^ Zum Sichern eines optimierten Autoloader-Skripts, das für die Produktion geeignet ist.

3. composer run-script --no-dev post-install-cmd

   ^^ Dies gilt hauptsächlich für Symfony, aber wenn Sie nach der Installation Skripte ausführen müssen (z. B. um Assets in Ihr “öffentliches” Verzeichnis zu kopieren, eine Art Cache aufzuwärmen, irgendetwas in der Art), wäre dies ein guter Moment es zu tun.

• Das Ergebnis des obigen Schritts sollte getestet werden (in einer typischen Staging-Umgebung) und dann vollständig in die Produktion übertragen werden (Ihr Client-Code, der Vendor-Ordner, die auf prod zugeschnittene Konfiguration usw.); Verwenden Sie die von Ihnen bevorzugte Bereitstellungsmethode.

Beachten Sie, dass bei Verwendung einer “langsamen” Push-Methode (FTP, Kopieren, rsync, usw.), sollten Sie nicht direkt in das Dateisystem der Anwendung schreiben, sondern eine neue Kopie der Anwendung erstellen und, sobald die Dateiübertragung bereit ist, eine schnelle Methode verwenden, um “Produktion” durch die neue Version zu ersetzen. Eine beliebte und effektive Methode ist die Verwendung eines Symlinks als „Produktions“-Root, sodass Sie den Symlink nur einmal aktualisieren müssen Alles das oben Genannte fertig und bereit ist, ohne eine laufende Anwendung zu beeinträchtigen (die ansonsten vorübergehend beschädigt werden könnte, weil sie plötzlich Dateien enthält, die zu verschiedenen Versionen der Anwendung gehören).

Meine Gedanken dazu sind,

• Die jetzige Arbeiten Der Zustand des Systems ist sehr wichtig, da ich davon ausgehen würde, dass einige Tests dagegen durchgeführt wurden.
• Ein Composer-Update würde bedeuten, dass Bibliotheken, die Teil der App sind, ihre Updates erhalten würden, was zu einem Bruch im System führen kann. Weil sie Bibliotheken sind, die von Bibliotheken abhängig sind, die von Bibliotheken abhängig sind.
• Schließlich würde ich das lieber tun, wenn composer-update wird gebraucht:
  • Checkout in einer Entwicklungsumgebung und composer update,
  • Stellen Sie sicher, dass die App gründlich in einer Entwicklungsumgebung getestet wurde
  • dann auf live/produktion mit installieren composer install

Meine Gedanken hier:

Sie sollten Composer Update niemals verwenden ohne Argument.

composer update liest jedes in der Datei composer.json aufgeführte Paket und aktualisiert es auf die neueste verfügbare Version, die mit den angegebenen Versionseinschränkungen kompatibel ist.

In einer perfekten Welt würden alle Bibliotheken folgen halbwegs richtig, und es sollte keine Nebenwirkungen haben. Aber technisch gesehen ist das nie immer wahr, und Sie könnten eine Version herunterladen, die mit der vorherigen nicht kompatibel ist, oder nur eine Version mit nicht korrigierten Fehlern.

Aktualisieren Sie also alle Ihre Pakete auf einmal würde wahrscheinlich zu einigen Problemen führen, es sei denn, Sie haben die Zeit, alles auf Ihrer Website zu überprüfen, um sicherzustellen, dass nichts schief gelaufen ist.

Aber natürlich müssen Sie manchmal bestimmte Pakete aktualisieren, also verwenden Sie composer update xxx/xxx ist nützlich, vorausgesetzt, Sie überprüfen alle Ihre Implementierungen des Pakets.

Wenn das aktualisierte Paket vollständig getestet ist, können Sie Ihren Code für die Bereitstellung/Produktion übergeben und dann ausführen composer install um sicherzustellen, dass Sie auf allen Ihren Plattformen genau die gleiche Version des Pakets und der Abhängigkeiten haben.

Lange Rede kurzer Sinn, hier ist der Prozess, den ich verwende:

• composer require xxx/xxx um neue Pakete zu installieren
• composer update xxx/xxx um ein bestimmtes Paket zu aktualisieren
• composer install in allen Umgebungen, wenn die Datei package.lock aktualisiert wurde.

Zusätzliche Gedanken

Ich bin einmal auf eine Implementierung gestoßen, die die genaue Version des Pakets in composer.json liefern würde. Der Entwickler erklärte, dass Sie auf diese Weise verwenden könnten composer update ohne Schaden.

Ich bin mit dieser Option nicht einverstanden, da selbst bei den genauen Versionen in der composer.json die Abhängigkeiten nicht behoben sind und ein Composer-Update zu potenziellen Fehlern in ihnen führen könnte.