Это может быть один вид обсуждения, а не вопрос.
Я хотел бы знать , какие развертывания политики вы будете следовать с 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, если вы не собираетесь ничего менять в проекте. Вы можете изменить мое мнение?
источник
Ответы:
Я не уверен, правильно ли я вас понял, но именно для этого предназначен производственный режим: производственные системы, в которых вы ничего не меняете (код мудрый). До следующего развертывания.
Я считаю, что развертывание на основе Git, которое вы используете, менее подходит для Magento 2, чем это было для Magento 1, из-за всей предварительной обработки. Сборка и развертывание являются более сложными, и имхо, нет никакого способа обойти автоматизированный процесс сборки
Что я бы порекомендовал:
Для этого отделите сборку от развертывания и выполните следующие действия в процессе сборки:
composer install(vendorвместо этого возможно добавление в репозиторий, но если вы сделали это просто для того, чтобы избежать запуска composer на сервере во время развертывания, сделайте это на этапе сборки и оставьте толькоcomposer.lockв репозитории)Генерация кода (YMMV):
создание архива ( сборки артефакт ) из полного каталога 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в хранилище полезно для отслеживания включенных и отключенных модулей.Это не пошаговая инструкция, но она должна дать вам обзор более надежной альтернативы вашему текущему процессу. Посмотрите на связанные инструменты, чтобы увидеть, как может выглядеть полное решение.
источник
.gitignoreфайл не имеет отношения к реальной проблеме. Вы можете просто использовать по умолчанию.На мой взгляд, подождите Magento 2.2 или попробуйте реализовать аналогичный подход.
Magento 2.2 представляет развертывание конвейера , например, разделяя сервер сборки и рабочий сервер.
Вот официальная документация: http://devdocs.magento.com/guides/v2.2/config-guide/deployment/pipeline/
Кроме того, в настоящее время я использую Ansible для управления автоматическим развертыванием с помощью шаблонов конфигурации и настройки нескольких сред.
источник