Процесс развертывания Magento 2

В настоящее время мы фиксируем composer.lockхранилище и затем запускаем его composer install --no-devна производственном сервере. Я не думаю, что это лучший способ сделать это, потому что композитору требуется несколько минут, чтобы сгенерировать все файлы, и это рискованно.

Интересно, лучше ли передать в репо все файлы, необходимые для работы в производственном режиме.

Как другие управляют процессом развертывания с magento 2?

Согласитесь на 100% с claudiu-creanga в том, что он не обязывает поставщика, а также избегает установки composer на производстве.

То, как мы справились с этим, - это наличие активной папки и папки-кандидата на выпуск. Именно в папке release-кандидата мы запускаем команды git pull и устанавливаем composer --no-dev. Наш процесс можно описать так:

1. В папке релиз-кандидат:

   • Проверьте на неожиданные изменения
   • Обновить репо
   • Композитор установить

2. Синхронизировать файлы с папкой сайта

3. В папке живого сайта:
   • Развертывание статических файлов
   • Включить режим обслуживания
   • Включить модули
   • Запустите установочные скрипты
   • Компилировать DI
   • Очистить кэш
   • Отключить режим обслуживания
   • Обновить разрешения

Я написал более длинную статью в блоге, в которой приведены фактические команды и причины этого: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-environment/

ОБНОВЛЕНИЕ: Теперь мы копируем действующую базу данных в промежуточную базу данных и используем ее для запуска сценариев установки, развертывания статических файлов и компиляции DI в автономном режиме. Затем он может быть развернут в режиме реального времени, включая pub / static файлы и var. Мы все еще ненадолго отключаем сайт, если выполняются сценарии установки, но в противном случае сайт остается закрытым. Более подробная информация на https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-downtime/

ОБНОВЛЕНИЕ: я передумал насчет фиксации папки продавца. Зафиксировав папку, вы получаете возможность отслеживать историю изменений этих файлов, видеть, случайно ли вы что-то изменили, и, что самое важное, избегать запуска composer. во время развертывания. Последнее важно сейчас, когда мы полагаемся на внешних поставщиков репозиториев. Что если один из них недоступен? Внезапно вы не можете развернуть. Недостатками являются больший репозиторий, риск совершения основных хаков и отвратительный удар разработчиков вроде меня :)

Пока что мы также фиксируем папку vendor, которая, конечно же, добавляет в репозиторий множество файлов. (Обязательно удалите все папки .git в файлах компоновщика поставщика, так как в противном случае содержимое папок не будет зафиксировано - например, firegento). Но символическая ссылка на папку vendor не работает, редактирование пути в файле vendor_path.php также не работает, и у нас пока не было времени искать лучшее решение.

У нас нет сервера сборки, и мы не запускаем composer на сервере, мы запускаем и тестируем все обновления локально и фиксируем их. Это, в свою очередь, запускает наш сценарий развертывания.

Наш сценарий развертывания заменяет файл env.php, выполняет несколько пользовательских действий, а затем также запускает setup:upgradeи setup:static-content:deployперед переключением активной ссылки на новую папку.

Единственная папка, на которую мы ссылаемся, это pub / media.

Наконец, мы выбрали такой сервис, как deploybot( http://deploybot.com/ ). Вы можете использовать capistranoбесплатно. Deploybot создает Docker-контейнер во время установки composer, и, если команда выполнена успешно, он развертывает код, в противном случае он не развернет ничего, поэтому ваша производственная среда будет в безопасности.

Я считаю это лучшим подходом, потому что:

1) парни композиторов не рекомендуют иметь в своем репозитории папку vendor по веским причинам:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Дополнительная информация: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) Работать composer install in productionбез сетей безопасности рискованно , пакеты могут быть неработоспособными (см. Npm), вы можете столкнуться с проблемами с памятью или любой другой ошибкой, которая может возникнуть, пока Composer генерирует файлы, и вам придется иметь дело с нарушенной производственной средой.

Я также смотрю на это, подход, который я использовал до сих пор:

Начальная загрузка сервера:

1. Настройте проект composer --create-project ... --no-devв srcпапку (хотя я все еще вижу, как проходит много dev-Cruft)
2. Настройка приложения, компиляция статических файлов, обновление базы данных и т. Д.
3. Установите все правильные разрешения

Что даст мне запас, работающий магазин из моего каталога src (но мой webroot там не указывает)

Тогда мой процесс развертывания:

1. Создайте новую папку выпуска
2. rsync файлы src в мой релиз (исключая хвалу)
3. развернуть и распаковать мои настройки поверх (несколько файлов тем и модулей)
4. установить любые сторонние модули magento через magento connect
5. указать мой хост webroot на мой новый выпуск (с символической ссылкой)
6. изящно перезагрузить мой веб-сервер

Это позволяет мне поддерживать основной код Magento отдельно от моего, использовать composer, чтобы поддерживать его в актуальном состоянии ... и мне не нужно отправлять 39,102 !!! файлы с каждым развертыванием или запустите команды composer во время развертывания.

... Стремясь услышать о других подходах или о передовом опыте в этом, а также обожать узнавать, какие файлы на самом деле требуются для производства, а какие - для разработки ... так что я могу поддерживать мой webroot в чистоте.

Как только я закончу, у меня будет хорошая игровая книга и несколько команд Fabric для организации конфигурации и развертывания, которыми я с удовольствием поделюсь.

надеюсь, это поможет