Як правильно розгортатись при використанні перемикача розробки / виробництва Composer?

180

Композитор має можливість завантажувати кілька залежностей лише під час розробки, тому інструменти не будуть встановлені у виробництві (на реальному сервері). Це (теоретично) дуже зручно для сценаріїв, які мають сенс лише в розробці, як тести, підроблені дані-інструменти, налагоджувач тощо.

Шлях слід додати додатковий require-devблок із необхідними інструментами у розробці:

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

а потім (теоретично) завантажувати ці залежності через

composer install --dev

Проблема та питання:

Композитор змінив поведінку installі updateв 2013 році кардинально змінив , require-dev-залежності тепер встановлені за замовчуванням (!), Сміливо створюйте composer.json з require-devблоком і виконайте composer installвідтворення.

Оскільки найприйнятнішим способом розгортання є підштовхування композитора. замок (що містить поточну настройку композитора), а потім зробіть composer installна виробничому сервері, це також встановить розробку.

Який правильний спосіб розгорнути це без встановлення залежності -dev?

_{Примітка. Я намагаюся створити тут канонічне запитання для пояснення дивного розгортання композитора. Не соромтесь редагувати це питання.}

php deployment composer-php

— Sliq
джерело

@all: Не знаю, де баунті :( Почну інший підхід.

— Sliq,

1

Якщо ви його не присуджуєте активно, і жодна відповідь не приймається або отримує достатньо грошей, ніхто не отримує винагороду.

— Свен

2

Мені особисто такий підхід взагалі не подобається. composer.lockНіколи не повинні бути додані в репозиторій Git, НІКОЛИ. Правильний підхід - використовувати оновлення композитора під час постановки, а потім синхронізувати файл у виробництво (якщо, звичайно, все працює). Постановка повинна бути точною копією виробничого середовища. composer.lockмає бути частиною .gitignore.

— іменник

6

composer.lock однозначно повинен бути включений у ваш CSV !!! Як ще ти переконаєшся, що всі користуються однаковою версією ?? Тож НІКОЛИ не виключайте composer.lock зі свого CSV !!!

— Тобіас Гартнер

3

@TobiasGaertner Я думаю, ви маєте на увазі VCS (програмне забезпечення для управління версіями), але в іншому випадку ви правильні та відповідають офіційним рекомендаціям проекту .

— Xiong Chiamiov

327

Чому?

ІМХО є вагомою причиною, чому композитор сьогодні використовуватиме --devпрапор за замовчуванням (при встановленні та оновленнях). Композитор здебільшого працює в сценарії, де така бажана поведінка:

Основний робочий процес композитора:

Починається новий проект:, composer.phar install --devjson та файли блокування передаються в VCS.
Інші розробники починають працювати над проектом: замовлення VCS та composer.phar install --dev.
Розробник додає залежності:, composer.phar require <package>додайте, --devякщо ви хочете, щоб пакет був у require-devрозділі (і виконувати зобов'язання).
Інші йдуть: (замовлення та) composer.phar install --dev.
Розробник хоче новіші версії залежностей: composer.phar update --dev <package>(і виконувати).
Інші йдуть: (замовлення та) composer.phar install --dev.
Проект розгорнуто: composer.phar install --no-dev

Як бачимо, --devпрапор використовується (набагато) більше, ніж --no-devпрапор, особливо коли кількість розробників, що працюють над проектом, зростає.

Виробництво розгорнути

Який правильний спосіб розгорнути це без встановлення залежності "dev"?

Ну, composer.jsonі composer.lockфайл повинен бути призначений для VCS. Не опускайте, composer.lockоскільки вона містить важливу інформацію про версії пакету, які слід використовувати.

Виконуючи виробниче розгортання, ви можете передати --no-devпрапор композитору:

composer.phar install --no-dev

Цей composer.lockфайл може містити інформацію про пакети розробки. Це не має значення. --no-devПрапор буде переконатися , що ці DEV-пакети не встановлені.

Коли я кажу "виробниче розгортання", я маю на увазі розгортання, яке спрямоване на використання у виробництві. Я не сперечаюся, чи composer.phar installслід це робити на виробничому сервері чи на інсталювальному сервері, де речі можна переглянути. Це не є сферою цієї відповіді. Я просто вказую, як це зробити composer.phar installбез встановлення "dev" залежності.

Не по темі

--optimize-autoloaderПрапор може бути також бажаний на виробництві (він генерує клас-карту , яка прискорить самозарядну в додатку):

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

Або коли виконано автоматичне розгортання:

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

Якщо кодова підтримує це, ви могли б поміняти --optimize-autoloaderна --classmap-authoritative. Більше інформації тут

— Джаспер Н. Брауер
джерело

5

Я згоден з більшістю сказаного за одним винятком. "встановлення композитора - no-dev" має виконуватися лише в постановочному середовищі, і це середовище слід вважати незмінним. Я не хотів би, щоб будь-яка залежність завантажувалася безпосередньо на моєму виробничому сервері і не проходила попередній перегляд / постановку. Це просто додаткова обережність.

— Масштабованість

3

@Scalable: Хоча я згоден з вами (і Свен це чудово висвітлює у своїй відповіді), це не сфера моєї відповіді, і не те, що я мав на увазі під „виробництвом розгортання“. Я додав абзац, щоб зробити це зрозумілим.

— Джаспер Н. Брауер

5

Насправді я вважаю, що за замовчуванням має бути менш небезпечний варіант. Зробити --dev за замовчуванням і випадково встановити композитор у виробництві може бути фатальним.

— Гектор Ордонез

3

Хороший момент у --optimize-autoloader. Враховуйте також --classmap-authoritative- З документації тут getcomposer.org/doc/03-cli.md ви бачите це: "Автозавантажувати класи лише з класової карти. Неявно вмикається --optimize-autoloader", щоб ви могли використовувати, якщо знаєте, що класи "є там ", що, ймовірно, має статися у вашому середовищі prod, якщо ви не генеруєте класи динамічно.

— Хаві Монтеро

6

Чудова відповідь, я б запропонував додати optimize-autoloaderбезпосередньо в composer.json:{"config": { "optimize-autoloader": true } }

— Іван

79

Власне, я б дуже рекомендував ПРОТИ встановлювати залежності на виробничому сервері.

Моя рекомендація полягає в тому, щоб перевірити код на машині розгортання, встановити залежності за потребою (це включає НЕ встановлення залежностей від розробників, якщо код переходить у виробництво), а потім перемістити всі файли на цільову машину.

Чому?

при спільному розміщенні хостингу ви не зможете потрапити до командного рядка
навіть якщо ви це зробили, PHP може бути обмежений там з точки зору команд, пам'яті чи доступу до мережі
Інструменти CLI сховища (Git, Svn), ймовірно, не будуть встановлені, що не вдасться, якщо ваш файл блокування зафіксував залежність від оформлення певної комісії замість завантаження цього комітету як ZIP (ви використовували --prefer-source або Composer немає іншого способу отримати цю версію)
якщо ваша виробнича машина більше нагадує невеликий тестовий сервер (думаю, мікропримірник Amazon EC2), ймовірно, недостатньо пам'яті, встановленої для виконання composer install
в той час як композитор намагається не порушувати речі, як ви ставитеся до закінчення частково зламаного веб-сайту про виробництво, оскільки деяка випадкова залежність не могла бути завантажена під час фази встановлення композиторів

Довга коротка історія: Використовуйте композитор у середовищі, яке ви можете контролювати. Ваша машина розробки справді відповідає тому, що у вас вже є всі речі, необхідні для роботи Composer.

Який правильний спосіб розгорнути це без встановлення залежності -dev?

Команда, яку потрібно використовувати, - це

composer install --no-dev

Це буде працювати в будь-якому середовищі, будь то сам виробничий сервер, або машина розгортання, або машина розробки, яка повинна зробити останню перевірку, щоб виявити, чи якась вимога розробника неправильно використовується для реального програмного забезпечення.

Команда не буде встановлювати або активно видаляти вимоги розробника, оголошені у файлі composer.lock.

Якщо ви не заперечуєте над розгортанням компонентів програмного забезпечення для розробки на виробничому сервері, запуск composer installбуде виконувати ту саму роботу, але просто збільшить кількість байтів, переміщених навколо, а також створить більшу декларацію автозавантажувача.

— Свен
джерело

14

Цікавий робочий процес, але є велика проблема : сховища ніколи не повинні містити папку / вміст самого постачальника (офіційні заяви на сторінці Composer), тому вони ніколи не будуть безпосередньо спрямовані на виробництво при розгортанні на основі git (що є загальним стандартом afaik, виправте мене, якщо я помиляюся). Таким чином, вищезазначене рішення працює лише з FTP-розгортанням "old school" !? Будь ласка, давайте обговоримо це далі ...

— Sliq

17

Запропонований нами робочий процес не включає надсилання коду через GIT на виробничий сервер. Насправді, я б рекомендував проти, оскільки це змусить вас встановити залежність композитора на виробничому сервері, що може спричинити будь-яку кількість проблем. Якщо ви хочете, щоб ваше розгортання працювало безперебійно, вам потрібно зібрати весь код, необхідний для запуску програми, перш ніж знищити поточну версію та замінити її. Вам не подобається FTP? RSync через SSH, а потім перемикайте версії, перевернувши символьне посилання. Але ви також можете натиснути, оформити замовлення та встановити композитор у програмі, якщо захочете.

— Свен

2

@Panique: Я щойно бачив цю частину вашого коментаря, і я маю відповісти: "підштовхнувся до виробництва в розгортанні на основі git (що є звичайним стандартним afaik, виправте мене, якщо я помиляюся)" - Ні, це не є загальним стандартом. Це лише один із способів зробити це.

— Свен

1

Команда, на якій я перебуваю, з великим успіхом включила це у свій робочий процес. У нас є збірна машина (звичайно, Дженкінс), яка: 1) перевіряється з SC 2) виконує встановлення / оновлення композитора 3) запускає тести одиниць 4) знімає залежність від розробників 5) створює файл phar ( app-1.34.pharтощо). Існує окремий механізм, який отримує сповіщення і вирішує, коли захопити цей файл, куди його перенести і що робити з ним. Деякі команди вирішують розпакувати phar, як тільки він знаходиться на сервері, а деякі команди запускають його як є. Це надало великої впевненості стабільності та відтворюваності наших пристроїв.

— Джош Джонсон

3

Я на 100% згоден з цією відповіддю. Композитор не повинен встановлюватися на сервер розгортання, а також не git. Сервери безперервної розгортання / інтеграції повинні точно керувати отриманням джерела та залежностей: git pull> композитор встановити> розгорнути

— Eric MORAND

4

Тепер require-devувімкнено за замовчуванням, для локальної розробки ви можете обійтися composer installі composer updateбез цього --devваріанту.

Коли ви хочете розгорнути виробництво, вам потрібно буде переконатися, що в ньому composer.lockнемає пакетів, що надійшли require-dev.

Ви можете це зробити за допомогою

composer update --no-dev

Після локального тестування --no-devви зможете розгорнути все на виробництво та встановлення на основі composer.lock. Тут вам --no-devзнову потрібна опція, інакше композитор скаже «Файл блокування не містить інформації, необхідної для розробників» .

composer install --no-dev

Примітка. Будьте уважні до всього, що може потенційно ввести відмінності між розробником та виробництвом! Я, як правило, намагаюся уникати затребуваних розробників, коли це можливо, оскільки включення інструментів для розробників не є великими накладними витратами.

— так1010
джерело

1

Це насправді неправильно в деталях. Немає необхідності перевіряти composer.lockзалежність від розробників. Ви просто запустите composer install --no-dev, і ви отримаєте лише встановлені звичайні залежності - адже Composer також видалить будь-які розробки залежностей на цьому кроці.

— Свен

Якщо мій місцевий composer.lock мав в ньому залежність від розробників (а це потенційно вплинуло на версії пакетів, що не розробляються), я б хотів оновити його, щоб відобразити, яким би воно було у виробництві. Це також змушує вас запускати composer install --no-devвиробництво, як composer installі помилка. Технічно я думаю, ти маєш рацію; цього не потрібно, але мені подобається додатковий рівень безпеки.

— dave1010

Добре, демо-сценарій: Ваш додаток вимагає dev/toolіprod/lib:~1.0 . Найновіший prod / lib - 1,3, але розробник / інструмент також вимагає prod/lib:1.1.*. Результат: Ви встановите версію 1.1.9 (найновіша з гілки 1.1.x) та будете використовувати її під час розробки. Я б сказав, що НЕ БЕЗПЕЧНО просто оновлювати --no-dev, таким чином включайте найновіший prod / lib 1.3 і припускаю, що все працює без тестування. І, можливо, тестування тоді неможливо через брак програми / інструменту. Я припускаю, що оскільки розробник / інструмент не потрібен у виробництві, його не слід виконувати, але програмне забезпечення повинно використовувати prod / lib 1.1.9.

— Свен

Якщо ви використовуєте --no-dev вам потрібно перевірити його локально, як я вже згадував у відповіді. Я все-таки рекомендую взагалі не використовувати --no-dev.

— dave1010

Тому в основному ви пропонуєте це: composer update тоді зробіть деяку розробку, потім зробіть composer update --no-dev, потім зробіть тестування випуску, потім натисніть на виробництво і зробіть composer install --no-dev. Дві проблеми: 1. Я не можу перевірити випуск без залежностей від розробників, і 2. Я не можу встановити, наприклад, Git у виробництві.

— Свен

3

На виробничих серверах перейменувати vendorв vendor-<datetime>, і під час розгортання матиме два постачальник каталоги.

Файл cookie HTTP змушує мою систему обрати нового постачальника autoload.php, і після тестування я роблю повністю атомний / миттєвий перемикач між ними, щоб відключити старий реєстр постачальників для всіх майбутніх запитів, після чого я видаляю попередній dir через кілька днів.

Це дозволяє уникнути будь-яких проблем, спричинених кешами файлової системи, які я використовую в apache / php, а також дозволяє будь-якому активному коду PHP продовжувати використовувати попередній каталог постачальника.

Незважаючи на інші відповіді, що рекомендують проти цього, я особисто працюю composer installна сервері, оскільки це швидше, ніж rsync з моєї області постановки (VM на моєму ноутбуці).

Я використовую --no-dev --no-scripts --optimize-autoloader. Ви повинні прочитати документи для кожного, щоб перевірити, чи це підходить для вашого оточення.

— Абхі Беккерт
джерело

2

Я думаю, що краще автоматизувати процес:

Додайте файл composer.lock у ваше сховище git, переконайтесь, що ви використовуєте composer.phar install --no-dev при випуску, але у вашій програмі dev ви можете без будь-яких проблем використовувати будь-яку команду composer, це не піде на виробництво, виробництво буде базувати свої залежності у файлі блокування.

На сервері ви перевіряєте цю конкретну версію або мітку та запускаєте всі тести перед тим, як замінити додаток, якщо тести проходять, ви продовжите розгортання.

Якщо тест залежатиме від залежностей розробників, оскільки композитор не має залежності від тестової області, не дуже елегантним рішенням можна буде запустити тест із залежностями розробника ( встановити composer.phar ), видалити бібліотеку постачальника, запустити composer.phar install - -но-дев Знову , це використовуватиме кешовані залежності, тим швидше. Але це хак, якщо ви знаєте поняття сфери застосування в інших інструментах побудови

Автоматизуйте це і забудьте про інше, ідіть випити пива :-)

PS .: Як і в коментарі @Sven нижче, непогана ідея не перевіряти файл composer.lock, оскільки це змусить установку композитора працювати як оновлення композитора.

Ви можете зробити цю автоматизацію за допомогою http://deployer.org/, це простий інструмент.

— Джованні Сілва
джерело

2

Якщо не вчиняти та не перевіряти, це composer.lockбуде таким чином composer installдіяти composer update. Тож версії, які ви розгортаєте, не ті, з якими ви розробляли. Це, ймовірно, може створити проблеми (і тим більше, зважаючи на єдину нещодавно вирішену проблему безпеки на "Замінити" у Composer). НІКОЛИ не слід бігати composer updateбез нагляду, не перевіряючи, що це нічого не порушило.

— Свен

1

@Sven це спосіб запропонувати в тому ж коментарі автоматично запустити тести Unit перед розгортанням. Але ви маєте рацію, краще все-таки зберегти файл composer.lock.

— Джованні Сілва

Тепер єдине, що вам доведеться пояснити: як запускати тести на сервері без таких розробок, як PHPUnit?

— Свен

Було б дуже приємно, якби залежності, тести та розгортання були розміщені разом в одному інструменті, наприклад, Java Gradle або SBT або навіть Maven (maven - не так добре). Один інструмент PHP, який змушує композиторського phpunit і розгортання працювати разом. Або навіть плагін Gradle або Scala SBT, щоб зробити це, оскільки вони є агностичними інструментами збирання, плагін може працювати навіть з активами, такими як мінімізація JavaScript та компіляція sass, мінімізація css. Хтось щось знає?

— Джованні Сілва

1

Звичайно, це робиться на сервері для перевірки реального середовища, але не безпосередньо на сайті vhost, ви можете зробити це у відокремленій тимчасовій папці та перемістити результат у vhost, коли це вдасться

— Giovanni Silva