Какова предпочтительная структура проекта Magento 2 под VCS?

15

Когда я начинаю новый проект M2, первое, что я хотел бы сделать, это установить ядро ​​через composer:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

Теперь я могу написать свой пользовательский модуль (и) и тему (и) в app/code. Затем я добавил бы мою composer.*и всю app/codeпапку в мою VCS. Пока все хорошо.

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

  1. Если я сделаю свой собственный Gruntfile.js, magento/magento2-baseпакет будет перезаписан при запуске composer installпосле клонирования репозитория.

  2. Если я зафиксирую свой gulpfile.js, я не смогу определить свои зависимости в a package.json, потому что он также будет перезаписан magento/magento2-base.

  3. Если я решу использовать установку Grunt в Magento и захочу изменить ее, отредактировав файлы в /dev/tools/grunt(например themes.js), я не смогу, потому что мои изменения будут перезаписаны magento/magento2-base.

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

  • Я мог запустить git checkout -сразу после установки, чтобы сбросить свои собственные файлы
  • /buildНапример, я могу хранить файлы сборки в отдельной папке.
  • Я мог бы использовать другой инструмент для сборки, такой как Phing, Ant или Rake (мои разработчики внешнего интерфейса не были бы так счастливы)
  • Я мог бы заменить magento/magento2-baseпользовательским пакетом, который имеет пользовательское сопоставление для основных файлов (не очень оптимальный, но эй, это вариант)

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

У кого-нибудь есть такая же проблема? Как ты это решил? Как вы структурируете свой проект под VCS?

ОБНОВИТЬ

Дополнительный пункт, связанный с настройкой проекта. В своих экспериментах я заметил, что установщик Magento composer имеет флаг для переопределения файла:

"extra": {
    "magento-force": "override"
}

Он внутренне рассматривается как логическое значение, если я не ошибаюсь, поэтому я попытался установить его, falseчтобы пропустить переопределение. Когда я запускаю, composer installмоя установка завершается неудачно из-за того, что файл (ы) уже присутствуют. По сути, если я не позволю Magento переопределить мои файлы, я не смогу установить его.

Какова цель этого флага тогда? Это только для проверки? Честно говоря, для меня нет особого смысла, но, возможно, кто-то может пролить свет на эту тему.

magento2 magento-2.1 magento-2.0 setup git fmrng
источник
Мне любопытно посмотреть, что другие публикуют в качестве ответа. В идеале, я думаю, что мы хотели бы не использовать Magento Core в нашем основном репо и ограничивать его только тем шаблоном, который мы создаем, и любыми пользовательскими плагинами, которые мы добавляем или исправляем. Затем во время сборки мы ссылаемся на ядро ​​+ репозиторий нашего проекта и создаем артефакт приложения из репозиториев. Это метод, который я недавно использовал для M1, и мне интересно, если официальная рекомендация от Magento сделать что-то подобное с M2 теперь, когда Composer полностью поддерживается.
Брайан 'BJ' Хоффпауир младший
В новых версиях M2, то Gruntfile.js, gulpfile.jsи package.jsonпроблема решена. Вопрос рассматривается в этом вопросе по - прежнему относится к более новой версии Magento 2 , когда вам нужно изменить themes.js, index.phpили .htaccess, например.
июня,

Ответы:

4

В краткосрочной перспективе мы ищем отдельные файлы, которые нуждаются в настройке. Например, если людям нужно изменить index.php, подумайте, как отделить стандартный файл, поставляемый Magento, от необходимости локальной настройки. Достигнув этого, можно получить «один настоящий .gitignore для всех проектов». То есть, легко зафиксировать весь каталог проекта в Git с помощью .gitignore всего, что «выбор компоновщика» выберет для вас (и все, что «обновление композитора» заменит при установке патча или обновления).

В долгосрочной перспективе цель состоит в том, чтобы максимально сократить .gitignore. Например, добавьте больше в модули в каталоге vendor.

потом

  1. Для всего, что вы не хотите делить между проектами, оставьте это в app / code и передайте в основной репозиторий проекта.
  2. Все локально разработанное, что вы хотите поделиться с другими проектами проще, поместите в отдельный репозиторий GIT и установите через composer, чтобы он оказался в «vendor». (Это может быть локальное хранилище композитора или просто установка прямо из GIT.)

Таким образом, вы все еще можете git фиксировать все дерево проекта сверху вниз, захватывая файлы composer.json и composer.lock (фиксация только app / code - нет). .Gitignore исключит каталог vendor и другие ненужные файлы.

Это дает вам лучшее из обоих миров, упомянутых в другом обсуждении. В настоящее время проблема заключается в длине и сложности файла .gitignore, и установка патча в настоящее время уничтожает некоторые локальные настройки (например, в index.php). Краткосрочный обходной путь - удалите index.php из .gitignore, и при установке исправления проверьте, какие изменения вы потеряли (git diff), и повторно примените их вручную.

Алан Кент
источник
Хорошо, так что вы измените некоторые вещи там в ближайшее время, приятно! Интересно, может ли этот "magento-force": "override"флаг быть полезным как-нибудь? На данный момент это не совсем то, что я ожидал. В случае, если вы отредактировали / расширили свои index.phpили любые другие «основные» файлы, вы можете просто сказать Magento не перезаписывать ваши изменения. Есть ли смысл?
fmrng
3

Существует простое решение для вашей проблемы переопределения: не меняйте основные файлы;) Magento основан на расширении кода, а не на его изменении.

Во-первых, вы не должны помещать всю папку приложения / кода в один репозиторий vcs. Каждый компонент Magento (модуль, тема и т. Д.) Должен быть сам репозиторий.

Если вы хотите изменить / расширить внешний интерфейс, вы должны создать новую тему и рассматривать эту тему как свой основной проект, а не весь экземпляр Magento2.

Чтобы установить свою тему в свой проект, вы можете легко загрузить ее через композитор прямо из вашего хранилища vcs.

Дэвид Верхолен
источник
Ну, app/codeпапка специально там для настройки Magento. Мое понимание текущего M2 - то, что app/codeзаменяет то, что app/code/localбыло в M1, и модули сообщества могут быть установлены через composer vendor. У нас есть несколько проектов с БОЛЬШИМ количеством модулей, а также несколько тем. То, что вы предлагаете, было бы невозможно.
fmrng
Эй, мы управляем проектами с> 100 компонентами таким образом. Ключ заключается в том, чтобы модули были небольшими и управляли зависимостями композитора между модулями. Вы можете клонировать репозиторий проекта magento для своих собственных нужд и добавить все свои компоненты в свой проект
David Verholen
Если вы довольны текущей настройкой, это нормально. Честно говоря, я нахожу это довольно громоздким. Это означает, что у вас есть более 100 git-репозиториев, и каждый раз, когда вы что-то меняете, вы должны открывать конкретный проект, фиксировать свои изменения, запускать composer update. Где вы делаете composer.lockто? Если у вас есть 10+ разработчиков, работающих над одним и тем же проектом, он может оказаться очень грязным. Конечно, у нас есть много общих модулей (и даже тем), которые мы устанавливаем через composer, но для ясности код для конкретного проекта должен быть версионирован в том же репо.
fmrng
Я не говорю, что вы делаете это неправильно, я думаю, что это немного слишком сложно на мой вкус. Из интереса, как вы проверяете свою историю репо с такой настройкой? Как вы можете использовать такие функции, как git blameили git logкогда код разбросан по нескольким компонентам? Вы запускаете интеграционные тесты, чтобы увидеть, что все работает нормально?
fmrng
мы провели это обсуждение внутри себя в прошлом году, и развертывание стало довольно простым, поскольку мы решили сделать его 1repo = 1module. Дело в том, что вы не сделаете обновление композитора за одно небольшое изменение. Разработчики работают в среде разработчиков и напрямую меняют файлы. Когда они закончат, они могут пометить его как альфа, бета или релиз-кандидат. Таким образом, несколько разработчиков могут работать над многими проектами одновременно, и в следующий раз вы создадите обновление для композитора, которое внесет все изменения. Существуют отличные инструменты для организации ваших пакетов vcs и composer. Сотни репозиториев не должны быть проблемой
David Verholen
2

Хорошо, похоже, я нашел лучшее решение для того, чего я пытался достичь. В этом разделе composer.jsonможно указать, какие файлы следует игнорировать установщиком Magento Composer. Если я не хочу, чтобы мой Gruntfile.jsбыл переопределен, я могу просто указать его в следующей конфигурации:

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

Теперь я могу расширить стандартную установку в соответствии со своими потребностями.

fmrng
источник
Это решение не кажется «безопасным при обновлении». Если Magento внесет изменения в эти файлы, которые вы игнорируете, вы не узнаете или забудете об этих файлах. Вы используете свою собственную версию, которая никогда не будет включать эти новые изменения. Пожалуйста, проверьте мой ответ на мое предложение.
7очг
2

К сожалению, принятый ответ, хотя изначально и предназначен для достижения желаемой цели, работает только для исключения файлов и каталогов, помещенных в корень, потому что, если мы хотим исключить файл, помещенный в подкаталог (например, dev/tools/grunt/configs/themes.js , требуется, если мы добавим новая тема и хотите использовать задачи Magento Grunt), поместив ее в конфигурацию «magento-deploy-ignore», он блокирует развертывание всех родительских каталогов (то есть dev и всех его подкаталогов).

Это происходит потому, что метод, который обрабатывает magento-deploy-ignore ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored), использует strposдля сопоставления пути назначения со списком исключенных, поэтому каждый родительский путь всегда будет возвращать true.

Дженнаро Виетри
источник
Я знаю, я мог видеть это в моих тестах, но, поскольку мы используем другой рабочий процесс сборки, он отлично работает для нас. Не могли бы вы найти лучший вариант?
fmrng
Мы начали проверять файлы на этапе сборки нашего конвейера, затем перестали использовать все встроенные задачи Grunt, поэтому это не проблема.
Дженнаро Виетри
Кстати, мы начали оценку fork magento-composer-installer для улучшения поведения «magento-deploy-ignore», если проблема возникнет снова, мы могли бы пойти по этому пути
Дженнаро Виетри
0

Использование патчей

Я использую создание и применение патчей. Когда нам нужно изменить dev/tools/grunt/configs/themes.js, index.phpили .htaccessприменить изменения во временную копию файла и создать патч из него (создать build/реж первый):

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

Затем мы можем сделать так, чтобы этот патч применялся автоматически при запуске composer installили updateдобавляя команды te в scriptsраздел вашего composer.jsonфайла:

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

(Также вы можете поместить вышеуказанную patch ...команду в скрипт bash, скажем,build/themes_patch.sh и вызвать этот скрипт из Composer, чтобы он мог использоваться повторно или выполнялся вручную)

Обновление безопасно! : D

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

7ochem
источник