Magento2 - локальное / промежуточное / производственное развертывание и gitignore

Это может быть один вид обсуждения, а не вопрос.

Я хотел бы знать , какие развертывания политики вы будете следовать с Magento2 и местными > стадирования > производственных условиях

После некоторых попыток мы решили, что лучшим (или, по крайней мере, самым надежным) подходом будет этот файл gitignore, включая папку vendor в git.

.DS_Store
/.buildpath
/.cache
/.metadata
/.project
/.settings
atlassian*
/nbproject
/sitemap
/sitemap.xml
/.idea
/.gitattributes
/app/config_sandbox
/app/etc/config.php
/app/etc/env.php
/app/code/Magento/TestModule*
/lib/internal/flex/uploader/.actionScriptProperties
/lib/internal/flex/uploader/.flexProperties
/lib/internal/flex/uploader/.project
/lib/internal/flex/uploader/.settings
/lib/internal/flex/varien/.actionScriptProperties
/lib/internal/flex/varien/.flexLibProperties
/lib/internal/flex/varien/.project
/lib/internal/flex/varien/.settings
/node_modules
/.grunt
/pestle.phar
/pub/media/*.*
!/pub/media/.htaccess
/pub/media/catalog/*
!/pub/media/catalog/.htaccess
/pub/media/customer/*
!/pub/media/customer/.htaccess
/pub/media/downloadable/*
!/pub/media/downloadable/.htaccess
/pub/media/import/*
!/pub/media/import/.htaccess
/pub/media/theme/*
/pub/media/theme_customization/*
!/pub/media/theme_customization/.htaccess
/pub/media/wysiwyg/*
!/pub/media/wysiwyg/.htaccess
/pub/media/tmp/*
!/pub/media/tmp/.htaccess
/pub/media/captcha/*
/pub/static/***
!/pub/static/.htaccess

/var/*
!/var/.htaccess

.unison*
/sync.sh

Таким образом, мы запускаем composer только в локальной среде: любое новое расширение или обновление программного обеспечения тестируется в локальной среде, затем проверяется и фиксируется. Возможно, мы бы затем включили файл app / etc / config.php в git, но этот файл перезаписывается при запуске setup:upgrade, верно?

Включение поставщика означает, что размер репозитория будет больше, чем (возможно) рекомендуется, но таким образом при развертывании кода мы просто запускаем последовательность:

bin/magento setup:upgrade
bin/magento setup:di:compile (optional)
bin/magento setup:static-content:deploy

Информация, связанная с данной: http://www.damianculotta.com.ar/magento/gitignore-y-la-estrategia-de-deploys-en-magento2

Посмотрите, почему мы выбираем команду компиляции как опциональную Magento 2 - setup: di: compile ?

ОБНОВИТЬ

Правда в том, что у нас возникают некоторые проблемы при развертывании изменений кода в наших опубликованных проектах Magento 2

Изменения работают в локальной и промежуточной версиях (проверено в обоих режимах: разработчик и производство ... хотя мы концептуально настраиваем эти среды в режиме разработчика), но некоторые из них не работают в производственной среде (в производственном режиме) и т. Д. поэтому я не уверен, что мы придерживаемся правильной стратегии. Я хотел бы увидеть, какова соответствующая последовательность команд, и актуальность порядка в этих командах

На самом деле, с каждым днем ​​я все меньше убеждаюсь в полезности производственного режима Magento 2, если вы не собираетесь ничего менять в проекте. Вы можете изменить мое мнение?

На самом деле, с каждым днем ​​я все меньше убеждаюсь в полезности производственного режима Magento 2, если вы не собираетесь ничего менять в проекте. Вы можете изменить мое мнение?

Я не уверен, правильно ли я вас понял, но именно для этого предназначен производственный режим: производственные системы, в которых вы ничего не меняете (код мудрый). До следующего развертывания.

Я считаю, что развертывание на основе Git, которое вы используете, менее подходит для Magento 2, чем это было для Magento 1, из-за всей предварительной обработки. Сборка и развертывание являются более сложными, и имхо, нет никакого способа обойти автоматизированный процесс сборки

Что я бы порекомендовал:

• Используйте повторяемые развертывания, т. Е. Вы должны быть уверены, что в процессе производства окажется тот же самый код, который находился в стадии подготовки, включая созданные файлы .

• Для этого отделите сборку от развертывания и выполните следующие действия в процессе сборки:

  • composer install( vendorвместо этого возможно добавление в репозиторий, но если вы сделали это просто для того, чтобы избежать запуска composer на сервере во время развертывания, сделайте это на этапе сборки и оставьте только composer.lockв репозитории)

  • Генерация кода (YMMV):

    bin/magento setup:di:compile
    bin/magento setup:static-content:deploy
    

  • создание архива ( сборки артефакт ) из полного каталога Magento, за исключением mediaи var, в том числе , но vendor, pub, var/generatedи var/di. Начиная с Magento-2.2 , var/generatedи var/diперемещаются generated/codeи generated/metadata, что делает его легче отделить их от остальных из varкоторых должны учитываться при развертывании.

• В развертывании скопируйте артефакт сборки на целевой сервер, распакуйте его в новый каталог и:

  • связать постоянные каталоги в него ( media, var/session, var/log...)
  • включить режим обслуживания
  • переключить корень документа (обычно документальная ссылка является символической ссылкой на последний выпуск, измените его на новый выпуск)
  • очистить кэш
  • бегать setup:upgrade
  • отключить режим обслуживания

• Этот процесс развертывания может быть легко реализован с помощью Deployer , который похож на Capistrano, но на PHP. Полное решение для развертывания Magento 2 на основе развертывания можно найти здесь: https://github.com/mwr/magedeploy2 (благодаря netz98!), А вот еще одно, которое мы используем: https://github.com/staempfli / magento2 развертывания-инструмент

• Хранение app/etc/config.phpв хранилище полезно для отслеживания включенных и отключенных модулей.

Это не пошаговая инструкция, но она должна дать вам обзор более надежной альтернативы вашему текущему процессу. Посмотрите на связанные инструменты, чтобы увидеть, как может выглядеть полное решение.

На мой взгляд, подождите Magento 2.2 или попробуйте реализовать аналогичный подход.

Magento 2.2 представляет развертывание конвейера , например, разделяя сервер сборки и рабочий сервер.

Вот официальная документация: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/

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