Jak prawidłowo wdrożyć, korzystając z przełącznika programistycznego / produkcyjnego Composera?

Composer ma możliwość załadowania kilku zależności tylko podczas opracowywania, więc narzędzia nie zostaną zainstalowane w środowisku produkcyjnym (na serwerze rzeczywistym). Jest to (w teorii) bardzo przydatne w przypadku skryptów, które mają sens tylko w programowaniu, takich jak testy, narzędzia do fałszywych danych, debugger itp.

Najlepszym sposobem jest dodanie dodatkowego require-devbloku z narzędziami potrzebnymi w programie deweloperskim:

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

a następnie (teoretycznie) załaduj te zależności za pośrednictwem

composer install --dev

Problem i pytanie:

Composer zmienił zachowanie installi updateradykalnie w 2013 roku, require-dev-zależności są teraz instalowane domyślnie (!), Możesz swobodnie utworzyć plik composer.json z require-devblokiem i wykonać go composer installdo odtworzenia.

Ponieważ najbardziej akceptowanym sposobem wdrażania jest wypchnięcie kompozytora. lock (który przechowuje twoją obecną konfigurację kompozytora), a następnie wykonaj composer installna serwerze produkcyjnym, to również zainstaluje programowanie.

Jaki jest prawidłowy sposób wdrożenia tego bez instalowania zależności -dev?

_{Uwaga: próbuję tutaj utworzyć kanoniczne pytania / odpowiedzi, aby wyjaśnić dziwne wdrożenie kompozytora. Zapraszam do edycji tego pytania.}

Czemu

IMHO ma dobry powód, dla którego obecnie Composer będzie używał tej --devflagi domyślnie (podczas instalacji i aktualizacji). Composer jest najczęściej uruchamiany w scenariuszach, w których jest to pożądane zachowanie:

Podstawowy przepływ pracy Composer wygląda następująco:

• Rozpoczyna się nowy projekt: composer.phar install --devpliki json i lock są przekazywane do VCS.
• Inni programiści rozpoczynają pracę nad projektem: checkout VCS i composer.phar install --dev.
• Programista dodaje zależności: composer.phar require <package>dodaj, --devjeśli chcesz, aby pakiet znalazł się w require-devsekcji (i zatwierdź).
• Inni idą razem: (kasy i) composer.phar install --dev.
• Deweloper chce nowszych wersji zależności: composer.phar update --dev <package>(i commit).
• Inni idą razem: (kasy i) composer.phar install --dev.
• Projekt jest wdrażany: composer.phar install --no-dev

Jak widać, --devflaga jest używana (znacznie) częściej niż --no-devflaga, zwłaszcza gdy rośnie liczba programistów pracujących nad projektem.

Wdrożenie produkcyjne

Jaki jest prawidłowy sposób wdrożenia tego bez instalowania zależności „dev”?

Cóż, plik composer.jsoni composer.lockpowinien zostać zatwierdzony do VCS. Nie pomijaj, composer.lockponieważ zawiera ważne informacje o wersjach pakietów, które powinny być używane.

Podczas wdrażania produkcyjnego możesz przekazać --no-devflagę do Composera:

composer.phar install --no-dev

composer.lockPlik może zawierać informacje o dev-pakietów. To nie ma znaczenia. --no-devFlag zadba te dev-pakiety nie są zainstalowane.

Kiedy mówię „wdrożenie produkcyjne”, mam na myśli wdrożenie, którego celem jest wykorzystanie w produkcji. Nie spieram się, czy composer.phar installnależy to zrobić na serwerze produkcyjnym, czy na serwerze pomostowym, na którym można sprawdzić. To nie jest zakres tej odpowiedzi. Po prostu wskazuję, jak to zrobić composer.phar installbez instalowania zależności „dev”.

Poza tematem

--optimize-autoloaderFlaga może być również pożądane na produkcji (generuje klasy mapę, która przyspieszy samoładownicze w aplikacji):

composer.phar install --no-dev --optimize-autoloader

Lub po zakończeniu automatycznego wdrażania:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

Jeśli Twój kod obsługuje to, możesz zamienić --optimize-autoloaderna --classmap-authoritative. Więcej informacji tutaj

Właściwie to zdecydowanie poleciłbym PRZECIWKO instalowaniu zależności na serwerze produkcyjnym.

Zalecam pobranie kodu na maszynie wdrożeniowej, zainstalowanie zależności w razie potrzeby (obejmuje to NIE instalowanie zależności dev, jeśli kod trafi do produkcji), a następnie przeniesienie wszystkich plików na maszynę docelową.

Czemu?

• w przypadku hostingu współdzielonego dostęp do wiersza poleceń może być niemożliwy
• nawet jeśli tak, PHP może być tam ograniczone w zakresie poleceń, pamięci lub dostępu do sieci
• narzędzia CLI repozytorium (Git, Svn) prawdopodobnie nie zostaną zainstalowane, co mogłoby się nie udać, gdyby plik blokady zarejestrował zależność do wypisania określonego zatwierdzenia zamiast pobierania tego zatwierdzenia jako ZIP (użyłeś --prefer-source lub Composer nie ma innego sposobu na uzyskanie tej wersji)
• jeśli twoja maszyna produkcyjna bardziej przypomina mały serwer testowy (pomyśl o mikro instancji Amazon EC2), prawdopodobnie nie ma nawet wystarczającej ilości pamięci zainstalowanej do wykonania composer install
• Podczas gdy composer nie próbuje niczego zepsuć, co myślisz o zakończeniu częściowo zepsutej witryny produkcyjnej, ponieważ nie można było załadować jakiejś losowej zależności podczas fazy instalacji Kompozytorów

Krótko mówiąc: korzystaj z Composera w środowisku, które możesz kontrolować. Twoja maszyna programistyczna kwalifikuje się, ponieważ masz już wszystko, co jest potrzebne do obsługi programu Composer.

Jaki jest prawidłowy sposób wdrożenia tego bez instalowania zależności -dev?

Polecenie do użycia to

composer install --no-dev

To zadziała w każdym środowisku, czy to na samym serwerze produkcyjnym, na maszynie wdrożeniowej, czy też na maszynie deweloperskiej, która ma wykonać ostatnią kontrolę, aby stwierdzić, czy jakiekolwiek wymagania programistyczne nie są nieprawidłowo używane w rzeczywistym oprogramowaniu.

Polecenie nie zainstaluje ani aktywnie odinstaluje wymagań programistycznych zadeklarowanych w pliku composer.lock.

Jeśli nie masz nic przeciwko wdrażaniu komponentów oprogramowania deweloperskiego na serwerze produkcyjnym, uruchomienie composer installwykonałoby to samo zadanie, ale po prostu zwiększyłoby ilość przenoszonych bajtów, a także utworzyło większą deklarację autoloadera.

Teraz require-devjest domyślnie włączony, w przypadku lokalnego programowania można to zrobić composer installi composer updatebez tej --devopcji.

Jeśli chcesz wdrożyć w środowisku produkcyjnym, musisz upewnić się, composer.lockże nie ma żadnych pakietów, które pochodzą z require-dev.

Możesz to zrobić za pomocą

composer update --no-dev

Po przetestowaniu lokalnie --no-devmożesz wdrożyć wszystko do produkcji i zainstalować w oparciu o composer.lock. Potrzebujesz tej --no-devopcji ponownie, w przeciwnym razie kompozytor powie "Plik blokujący nie zawiera informacji require-dev" .

composer install --no-dev

Uwaga: uważaj na wszystko, co może powodować różnice między programowaniem a produkcją! Generalnie staram się unikać require-dev, gdy tylko jest to możliwe, ponieważ dołączenie narzędzi programistycznych nie jest dużym narzutem.

Na serwerach produkcyjnych zmieniam nazwę vendorna vendor-<datetime>i podczas wdrażania będę mieć dwa katalogi dostawców.

Plik cookie HTTP powoduje, że mój system wybiera nowego dostawcę autoload.php, a po przetestowaniu wykonuję całkowicie atomowe / natychmiastowe przełączanie między nimi, aby wyłączyć katalog starego dostawcy dla wszystkich przyszłych żądań, a następnie usuwam poprzedni katalog kilka dni później.

Pozwala to uniknąć wszelkich problemów spowodowanych przez pamięci podręczne systemu plików, których używam w apache / php, a także pozwala każdemu aktywnemu kodowi PHP na kontynuowanie korzystania z katalogu poprzedniego dostawcy.

Pomimo innych odpowiedzi zalecających przeciwko temu, osobiście działam composer installna serwerze, ponieważ jest to szybsze niż rsync z mojego obszaru przejściowego (maszyna wirtualna na moim laptopie).

Używam --no-dev --no-scripts --optimize-autoloader. Powinieneś przeczytać dokumentację dla każdego z nich, aby sprawdzić, czy jest to odpowiednie dla twojego środowiska.

Myślę, że lepiej zautomatyzować ten proces:

Dodaj plik composer.lock do repozytorium git, upewnij się, że używasz pliku composer.phar install --no-dev po wydaniu używasz , ale na swoim komputerze deweloperskim możesz bez obaw użyć dowolnego polecenia composer, to nie przejdzie do produkcji, produkcja oprze swoje zależności w pliku blokady.

Na serwerze pobierasz tę konkretną wersję lub etykietę i uruchamiasz wszystkie testy przed zastąpieniem aplikacji, jeśli testy zakończą się pomyślnie, kontynuujesz wdrażanie.

Jeśli test zależy od zależności dev, ponieważ kompozytor nie ma zależności zakresu testowego, niezbyt eleganckim rozwiązaniem może być uruchomienie testu z zależnościami dev ( instalacja composer.phar ), usunięcie biblioteki dostawcy, uruchomienie instalacji composer.phar - -no-dev ponownie, użyje buforowanych zależności, więc jest szybsze. Ale to hack, jeśli znasz pojęcie zakresów w innych narzędziach do kompilacji

Zautomatyzuj to i zapomnij o reszcie, idź napić się piwa :-)

PS .: Jak w komentarzu @Sven poniżej, nie jest dobrym pomysłem nie sprawdzanie pliku composer.lock, ponieważ spowoduje to, że instalacja narzędzia Composer będzie działać jako aktualizacja kompozytora.

Możesz zrobić tę automatyzację za pomocą http://deployer.org/ jest to proste narzędzie.