GIT и стратегия развертывания проектов Magento2

92

В Magento 1 я использовал инструмент развертывания, который использовал GIT-репозиторий, выполнял такие команды modman deploy-allи varпроверял, доступен ли каталог для записи. Для этого .gitignoreя использовал этот, который работал довольно хорошо.

Но как насчет Magento 2 ?

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

Вопрос останется открытым довольно долго

magento2

— Сандер Мангель
источник

Хороший вопрос @ Сандер Мангель

— Амит Бера

1

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

— Philwinkle

@philwinkle может быть широким, но, видимо, не слишком широким, поскольку уже было дано 3 ответа. Как обсуждено здесь: meta.magento.stackexchange.com/questions/745/… Мета должна использоваться для вопросов о MageSE, а не случайных постов / вопросов. Если вы хотите удалить его, я не могу остановить вас, но, похоже, много Люди интересуются этим вопросом, и, на мой взгляд, он правильный, но не слишком конкретный.

— Сандер Мангель

Две вещи: во-первых, Сандер прав в отношении Meta - его следует использовать только для вопросов о платформе SE, так как она связана с Magento SE (примечание: мы, возможно, недостаточно хорошо определили Meta для усиления этого правила). Во-вторых, вопрос «многих людей интересует» не имеет ничего общего с тем, можно ли ответить на вопрос канонически или нет (и, следовательно, с вопросом о соответствии вопроса формату StackExchange). Это точно расстраивает (я сам столкнулся с этим). Я склонен видеть, где этот поток Q / A идет. Возможно, А можно сформулировать достаточно хорошо, чтобы быть исключительно «правильным» ...

— отметки

@ отметки в этом случае я выбрал неправильную причину или тему для награды, моя мотивация заключалась в том, чтобы вознаградить того, кто нашел время, записать полный ответ за это. Если эта ветка здесь не принадлежит, я скопирую ее и выложу где-нибудь в Интернете, сообщив об авторах, поскольку я чувствую, что она по-прежнему имеет ценность. Пожалуйста, сообщите мне, если перед удалением

— Сандер Мангель

56

Шаги ниже описывают, как настроить среду для разработки пользовательских модулей, а не для производства.

Инициализация проекта

Добавьте учетные данные repo.magento.com и токен доступа github к auth.json в домашнем каталоге композитора
Создайте проект с помощью следующей команды:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition .
Возьми этот .gitignore и вставь в свой проект root. Почти все основные файлы / каталоги уже добавлены в корень .gitignore, но лучше также добавить следующие 2 /updateи /phpserver(просто добавьте эти 2 строки в .gitignore)
Инициализировать новый репозиторий git в корне проекта
Добавьте все неотслеживаемые файлы в git и передайте их
Начните разработку ваших модулей как обычно (поместите их под app/code/VendorName/ModuleName), теперь у вас будет только ваш собственный код в вашем git-репозитории

Magento установка

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

${project_root}/bin/magento setup:install \ --db-host=localhost \ --db-name=magento \ --db-user=root \ --backend-frontname=admin \ --base-url=http://base.url.goes.here/ \ --language=en_US \ --timezone=America/Chicago \ --currency=USD \ --admin-lastname=Admin \ --admin-firstname=Admin \ --admin-email=admin@example.com \ --admin-user=admin \ --admin-password=123123q \ --cleanup-database \ --use-rewrites=1
Включите работу cron индексаторов, например, в Ubuntu:

echo "* * * * * php ${project_root}/bin/magento cron:run &" | crontab -u www-data -
Magento будет работать в defaultрежиме, и весь отсутствующий контент будет автоматически сгенерирован по первому запросу. Так что нет необходимости запускать компилятор или развертывание статического контента
[необязательно] При использовании PHP Storm выполните следующую команду, чтобы включить поддержку XSD:

bin/magento dev:urn-catalog:generate .idea/misc.xml

— Алекс Палиаруш
источник

Привет, Алекс. Шаг 3 инициализации проекта - не могли бы вы немного его расширить? Вы обнаружили, что вам пришлось вручную копировать этот подкаталог в корневой каталог? (Мне интересно, если что-то не работает правильно - я не ожидал этого шага.)

— Алан Кент

@AlanKent в настоящее время вы получаете все файлы, связанные с Magento, загруженные в vendorтом числе magento2-base, что является просто каркасом для нового проекта. Не уверен, почему этот шаг не настроен для автоматического выполнения композитором, попытается выяснить. Что касается .gitignoreкопирования из другого репо, то уже обсуждается, как устранить / упростить этот шаг.

— Алекс Палиаруш

Шаг 3 не требуется. Маршалинг файлов / папок выполняется на шаге 2.

— Мэдди,

Спасибо, Мэдди. @AlanKent, копирование magento2-baseв корень больше не нужно (только что проверено), похоже, недавно исправлено. Убрал этот шаг из ответа.

— Алекс Палиаруш

1) Я помещаю весь свой код в репозиторий, уже установленный, и все, когда я вынимаю из этого репо и просто изменяю настройки для администратора и учетных данных базы данных, все будет работать правильно? 2) так как я забыл исключить папку var / и pub / во время отправки, могу ли я удалить их полностью, чтобы их можно было удалить на удаленном репо, будут ли они восстанавливаться обратно? Благодарю.

— Лачезар Райчев

25

Для инициализации и установки следуйте инструкциям Алекса, ответившим на большинство шагов, только отличия, которые я бы рекомендовал:

Конфигурация Git

Храните только следующие файлы в вашем Git-репозитории:

composer.json
composer.lock
приложение / и т.д. / config.php

Для своего пользовательского кода проекта также используйте отдельные модули, которые вы добавляете через композитора. Управлять этим композитором проще, поскольку вы можете заблокировать конкретную версию / выпуск, который вы хотите развернуть. Это также заставляет вас использовать один и тот же подход для внутренних и внешних модулей.

развертывание

Во время разработки вы обновляете модули в своей среде (dev / test) с помощью команды:

composer update

Это обновит файл composer.lock с версиями, установленными в этой установке.

На стадии подготовки / подготовки / производства вы можете создать / установить ту же установку с помощью команды:

git pull
composer install

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

После установки необходимо выполнить следующие команды:

bin/magento setup:upgrade
bin/magento setup:di:compile (or setup:di:compile-multi-tenant)
bin/magento setup:static-content:deploy

Это обновит базу данных (обновление схемы и данных), сгенерирует конфигурацию DI и развернет все файлы статического представления.

— Владимир Керхофф
источник

Может быть, имеет смысл использовать образцы данных вместо генерации данных? Фиксаторы заполняют только самые важные модули и, по-видимому, полезны только для тестирования производительности.

— Алекс Палиаруш

Спасибо, удалили эту часть, так как она не нужна при использовании сайта в производстве.

— Владимир Керхофф

Это очень близко следует подходу, который я использую. Это также хорошо работает с Magento 1 (с менее сложным процессом сборки). Позвольте composer справиться со своей работой, он действительно хорошо работает для развертываний, и мы не увидели много недостатков, кроме сложностей со стратегией .gitignore, когда вы не следуйте меньшему следу в git.

— Aepod

Эта установка выглядит как «интегратор». Он добавляет репозитории в vendor / magento / *. Никакого кода не будет в app / code / .. и других каталогах. Как бы у меня Magento 2 core dirs как в .zip архиве. Можно ли добавить через composer модуль (другой git repo) и чем автоматически оказаться в app / code / ...?

— неясный

4

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

— Claudiu Creanga

3

Re .gitignore, 2.2 и далее официальный ответ Magento будет "config.php идет в git, env.php - нет".

Мы смотрим на плагины для композиторов, такие как Mediawiki, чтобы приблизить внутреннего разработчика к разработке расширений и сайтам заказчиков. Еще изучаю, еще не окончательно.

Мне очень понравилось использовать тип репозитория Composer «Path» с путем ../othergitrepo/app/code/*/*для выбора модулей, но он использует символические ссылки, которые не очень хорошо работают в средах разработки, использующих Unison или аналогичные.

— Алан Кент
источник

3

мы используем другой подход, который не требует отдельного сервера / процесса сборки , мы локально разрабатываем, как в рабочей среде

Затем мы фиксируем все файлы, необходимые для производства . Затем мы просто развертываем наборы изменений на сервере и запускаем команду обновления.

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

причина в том, что мы хотим иметь 100% контроль над тем, какой код идет в производство. Так как magento2 генерирует тонну кода, мы должны запустить его локально, чтобы иметь возможность понять все эффекты и быть в состоянии отлаживать, как будто в производстве.

Я знаю, что это не то, что многие люди рекомендуют делать, но для нас это работает лучше всего.

шаги настройки внешнего интерфейса

Для того , чтобы эти сценарии для работы установить свой магазин в производственном режиме в вашем env.php и настройки вашей темы в dev/tools/grunt/configs/themes.js. (следующие шаги были помещены в сборник рассказов)

удалять var/cache
удалять var/view_preprocessed
удалить pub/static/*(не удаляйте .htaccess)
удалять var/composer_home
бегать php bin/magento cache:flush
бегать php bin/magento setup:static-content:deploy %your_languages%
удалите все темы / языки, которые вы на самом деле не используете, из pub / static / frontend
удалить бумажные копии меньшего количества файлов из pub/static/frontend
бегать php bin/magento dev:source-theme:deploy --locale="%your_language%" --theme="%your_theme%" css/styles-m css/styles-l css/email css/email-inline
необязательно: мы используем bash-скрипт для изменения абсолютных символических ссылок, созданных на шаге 9, на относительные, что позволяет запускать grunt извне vm
бегать grunt less:your_theme

шаги бэкэнда / ди-установки

удалять var/cache
удалять var/generation
удалять var/composer_home
удалять var/di
бегать php bin/magento cache:flush
бегать php bin/magento setup:di:compile

— greenone83
источник

Спасибо за это @ greenone83, этот подход я в основном принял, хотя я генерирую свой бэкэнд как часть внешнего интерфейса. Я НИКОГДА не пользуюсь настройкой: di: скомпилирую, так как я нахожу это ошибкой! Одна вещь, которую я не понимаю, это то, почему setup: static-content: deploy создает файлы в сгенерированном / code (расположение изменилось с вашего поста)? Я обнаружил, что если я удаляю весь сгенерированный / код, когда мой сайт находится в производственном режиме, эти файлы автоматически создаются, когда я просматриваю сайт.

— PedroKTFC

2

Вы также должны игнорировать эти файлы
/app/etc/config.php
/app/etc/env.php
/.idea/workspace.xml // phpstorm

— mrtuvn
источник

2

Если вы игнорируете config.php, вам нужно будет снова включить новое расширение после отправки в другую среду, поэтому лучше включить его в свой репозиторий.

— Владимир Керхофф