Magento 1: улучшение моего рабочего процесса разработки модулей (Modman, composer, git)


14

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

В общем, я работаю с 6 различными сайтами, все работают под управлением Magento CE 1.9.2+

На этих сайтах я использую набор расширений, которые были разработаны мной и командой, с которой я работаю (здесь мы говорим о 50+ расширениях), и код для этих расширений хранится в Bitbucket. Так что я не единственный, кто управляет этими расширениями, над ними работают 3 человека.

В настоящее время, когда я хочу добавить функцию / исправить ошибку для одного из этих расширений, вот мой рабочий процесс:

  • Установите последнюю версию расширения на одном из сайтов через Modman
  • Исправить ошибку / добавить функцию / тест
  • Вручную скопируйте изменения в локальную папку, содержащую все мои расширения
  • Зафиксируйте и отправьте через GIT из этой папки расширения в Bitbucket (1 репозиторий Bitbucket на модуль)
  • Тогда новая версия модуля может быть установлена ​​через Modman

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

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

Итак, как я могу улучшить свой рабочий процесс, чтобы избавиться от этого шага копирования / вставки вручную? Я открыт для предложений здесь.


вы пробовали Submodulesособенность git?
Гопал Патель

Почему вы используете печатную версию? С символическими ссылками у вас просто должен быть git-клон в папке modman. Тогда просто отредактируйте на месте и просто нажмите.
Кристоф в Фуман

@KristofatFooman Я должен был это уточнить. Один из разработчиков работает под управлением Windows, поэтому у нас возникли проблемы с символическими ссылками ^^
Рафаэль из Digital


1
@RaphaelatDigitalPianism для проблемы окон, попробуйте посмотреть на github.com/sitewards/modman-php
Дэвид Мэннерс

Ответы:


8

Я очень часто использую следующий подход, который довольно независим от фреймворка.

  1. Проверьте модуль, который вы хотите редактировать /path/to/my/module
  2. Создайте ветку для вашей работы (ответвления от соответствующей метки и т. Д.).
  3. Зафиксируйте работу в этой ветке (не нажимайте).
  4. В вашем проекте определите локальный репозиторий для вашей локальной копии модуля. Это сделано для того, чтобы ваш проект мог извлекать не выдвинутые изменения из вашей LFS.

    {
        "repositories": [
        {
            "type": "path",
            "url": "/path/to/my/module"
        }
    ],
  5. Затем вы можете составить заявку вашей конкретной ветви разработки (так долго, скажем, ваши проекты minimum-stabilityпозволяют).

    composer require namespace/module dev-branch-name-here
  6. Вы допускаете в /path/to/my/module, composer update namespace/moduleв проекте, увидеть его установку и тестирование.

  7. Когда вы закончите сквош свои коммиты и нажмите вверх.

Я считаю, что этот подход хорошо работает для модулей M1, использующих https://github.com/Cotya/magento-composer-installer , поскольку установка по символическим ссылкам может иногда вызывать боль и сбивать вас с толку при добавлении новых каталогов или путей, которые ранее не были символическими ссылками по модману.

Ссылки, которые могут заинтересовать

Отладка

  1. Используйте, composer require namespace/module dev-branch-name-here -vvvчтобы увидеть ветви, которые вы можете использовать локально.

  2. Дважды проверьте, что minimum-stabilityбыло установлено devв проекте, в который вы устанавливаете модуль.

  3. Your requirements could not be resolved to an installable set

Нашел, прочитав комментарий Патрика Швисова здесь .

Если к другим пакетам предъявляются требования к пакету, который вы изменяете, ваша ветвь разработки может не соответствовать этим требованиям (в результате «Ваши требования не могут быть разрешены для устанавливаемого набора пакетов»). Чтобы исправить это, вы можете сделать встроенный псевдоним, чтобы все другие пакеты видели его как определенную версию.

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

"namespace/module": "dev-branch-name-here as 1.2.3"

Еще один интересный подход здесь. Спасибо за ваш вклад
Рафаэль в Digital

1
Это хороший. Я обычно использую pathрепозитории типов для модулей проекта, которые я не буду использовать повторно, а затем git или packagist для модулей, которые я буду использовать повторно.
Дэвид Мэннерс

1
@DavidManners Я использую этот поток выше в сочетании с удовлетворительным. Модули постоянно находятся в удовлетворительном состоянии, но я не хочу выдвигать что-либо в основную линию, пока я не протестирую и не буду работать локально. Так что используйте вышеописанный рабочий процесс, а затем нажмите и пометьте, и ждите, пока «удовлетворитель» подхватит его.
Люк Роджерс

@LukeRodgers, с этим рабочим процессом вы вообще не используете modman, и все ваши файлы модулей помещаются в файлы magento? (у вас нет папки .modman для ваших расширений). Я правильно понял?
MployBy

Привет @MployBy, я не использую modman напрямую. Тем не менее, я не уверен, что Cotya / magento-composer-installer использует его под капотом, прошло много времени с тех пор, как я установил новый модуль magento1.
Люк Роджерс

6

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

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

Я использую composer с установщиком AOE composer, чтобы клонировать репозитории расширений непосредственно в, .modmanно установка модулей из Git с modman тоже работает, я полагаю. В любом случае вы можете работать непосредственно в модуле Git репозитория.


Да, как я уже сказал в комментариях, причина в том, что один из разработчиков использует Windows и IIRC, у нас были некоторые проблемы с ним при использовании символических ссылок
Рафаэль в Digital

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

4

Поэтому моя идея для вас - начать работать с композитором даже для Magento1. Если у вас был свой собственный packagist , с которым не так сложно управлять сейчас, когда есть aws и google cloud, или вы можете использовать общедоступный packagist. У вас будет «легкий» доступ к новым версиям в ваших магазинах Magento1.

Это означает, что когда выйдет более новая версия, вы сможете, composer updateи это автоматизирует процесс копирования для вас.

Посмотрите https://github.com/Cotya/magento-composer-installer для Magento1 через композитор.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.