Ich habe ein paar große Symfony-Projekte und habe festgestellt, dass nach der Aktualisierung von allem auf Symfony 4 (Flex), wenn unsere Bereitstellungsautomatisierung wie folgt abläuft:
composer install --no-dev
Wir enden mit (zum Beispiel):
%Vor% Dann führt dies erwartungsgemäß zu Änderungen von symfony.lock und config/bundles.php , plus was auch immer, abhängig davon, was in require-dev in composer.json enthalten war.
Nichts davon bricht genau, aber es ist ärgerlich, wenn eine Produktionsbereitstellung nicht mehr über eine saubere git status -Ausgabe verfügt und zu Verwirrung darüber führen kann, was tatsächlich bereitgestellt wird.
Es gibt verschiedene Problemumgehungen dafür, zum Beispiel könnte ich einfach alles in require anstatt require-dev setzen, da es keinen wirklichen Schaden bei der Bereitstellung gibt, oder ich könnte den --no-dev -Teil des Composer-Befehls weglassen .
Aber wirklich, was ist die richtige Übung hier? Es scheint seltsam, dass es keine Möglichkeit gibt, Flex mitzuteilen, dass es keine Änderungen an der Konfiguration vornehmen soll, wenn Sie nur eine gesperrte Software bereitstellen. Ist das eine Feature-Anfrage, oder habe ich hier etwas Konfiguration vergessen?
Wenn Sie deploy von Ihrem Master-Zweig aus bereitstellen, können Sie stattdessen einen Deploy-Zweig einrichten. Und in diesem Zweig können Sie verhindern, dass bestimmte Dateien zusammengeführt werden. Siehe diesen Beitrag für weitere Details . Dies erzeugt eine Situation, in der Sie einen Master-Zweig haben, einen Versionszweig (Beispiel: 3.21.2) und Sie haben Devices Checkout-Master, arbeiten daran und fügen dann ihre Änderungen in den Versionszweig ein. Von dort wählst du aus und wählst aus, was zum Einsatz gebracht wird. (Es wird hier einen kleinen Balanceakt geben. Sie werden alle Änderungen in den Master migrieren müssen, bis sie mit Ihrem Versionszweig übereinstimmen und sicherstellen, dass der Master mit der Version übereinstimmt, nachdem Sie ihn bereitgestellt haben. Das fügt ein wenig Arbeit hinzu und Sie müssen behalte es im Auge usw.)
Eine weitere Option besteht darin, Ihr Git-Repository von Ihrem Bereitstellungsverzeichnis zu trennen. In diesem Beispiel , Ein Git-Verzeichnis wird in /var/repo/site.git erstellt und das Bereitstellungsverzeichnis ist /var/www/domain.com . Ein Post-Receive-Git-Hook wird verwendet, um das www-Verzeichnis automatisch zu aktualisieren, nachdem ein Push-Vorgang an das Repo- / Site-Verzeichnis gesendet wurde. Sie laufen natürlich Composer, Npm, Schluck, Whathaveyou im WWW-Verzeichnis und das Git-Verzeichnis bleibt wie es ist.
Wenn Sie keine kommerziellen Optionen wie z. B. Apps für die kontinuierliche Bereitstellung verwenden, können Sie ein Bereitstellungsskript schreiben. Es gibt viele Möglichkeiten, ein Shell-Skript zu schreiben, das ein Verzeichnis übernimmt und es kopiert, Composer ausführt, Npm usw. in einem einzigen Befehl ausführt - den Git von den Bereitstellungsverzeichnissen trennt. Hier ist eine einfache , die das aktuelle datetime nutzt, um ein Verzeichnis zu benennen und es dann zu verlinken das Bereitstellungsverzeichnis
Tags und Links symfony composer-php symfony4 symfony-flex