Контроль версий для разработки модулей

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

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

В настоящее время я занимаюсь разработкой его внутри своего репозитория сайта, и в скором времени планирую разбить его на отдельный репозиторий. На этом этапе я, вероятно, сделаю следующее:

• Сборка в моей локальной среде в отдельном репозитории модулей с использованием modman
• Скопируйте изменения в репозиторий сайта, когда я буду готов к развертыванию кода

Надеетесь, что есть лучший способ?

У нас есть несколько модулей, где мы это сделали, и то, что мы по сути сделали:

• Настройте Git-репо для модуля.
• Разверните этот модуль в кодовой базе рабочего сайта и передайте все, включая:
  • софт-ссылки созданные модманом
  • каталог .modman, в котором находится клонированный репозиторий модулей
• Используйте modman, чтобы «развернуть» его в других версиях и / или среде разработки для разработки и тестирования.

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

ОБНОВЛЕНИЕ: Когда я первоначально написал это, я не учел в своем ответе, что Git не позволяет (суб) модулям быть зафиксированными в репозитории, и в этом случае «фиксация всего» требует некоторой проработки!

Кстати, это потому, что я делал это чаще, используя modman для развертывания модулей, размещенных в репозиториях Git, в производственную кодовую базу, размещенную в SVN… и у Subversion нет никаких препятствий, мешающих ему передать все дерево Git в VCS.

Так что здесь идет ...

1. Если вы используете SVN для размещения кода рабочего сайта, у вас не должно быть проблем, поскольку Subversion (практически) не имеет понятия о субмодулях. Это не будет возражать.

2. Если вы используете Git для кода производственного сайта, вам придется использовать подмодули, чтобы «зафиксировать все» в хранилище кода сайта. После использования modman для клонирования чего-то подобного:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Вы также захотите добавить его как субмодуль, например так:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Как только вы это сделаете, вы сможете добавить в индекс каталог .modman и файл .gitmodules и зафиксировать его.

   После клонирования репозитория, использующего эти модули, установленные через modman, просто инициализируйте подмодули и обновите:

   git submodule init
   git submodule update

PS Теперь я использую Git на всех новых проектах, так что, надеюсь, такого упущения больше не будет. Извините ребята. ;)

Похоже, что текущее соглашение заключается в поддержке:

• Композитор - http://getcomposer.org/
• Модман - https://github.com/colinmollenhour/modman
• Github репо

Что касается структуры каталогов, то она минимальная, и желательно, чтобы модуль был установлен в пуле кодов сообщества.

Минимально рекомендуемая структура каталогов:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Необязательно / приятно иметь:

• Целевая страница Github с описанием, некоторыми снимками экрана и некоторыми маркированными функциями.
• Ссылка на установленный демонстрационный магазин тоже подойдет
• Скринкаст / двухминутный обзор вашего продукта

Изменить: я мог бы неправильно понял.

Использование комбинаций modman / gitignore может сохранить ваш модуль изолированным от тестовой среды. Используя указанную выше структуру папок, вы можете явно разрешить фиксацию / установку только файлов вашего модуля в репозиторий. В этом случае ответ Дэвида более применим. Поддержка Modman для dev / deploy, похоже, является консенсусом.

Даже не пытаясь сам, я бы порекомендовал использовать композитор для этого.

Управление версиями, включая зависимости

Сохраняя composer.lockфайл в хранилище, вы исправляете версии всех модулей и всегда можете восстановить определенную версию (ветвь, тег или более старую версию), используя вашу VCS ( git checkout, svn ..), а затем composer.phar install.

Недостатки

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

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

Сатис, кажется, может служить этой цели (см. Https://github.com/researchgate/broker ) и мой вопрос /programming//q/16211671/288568

Кален,

Может быть, я не совсем правильно понял ваш рабочий процесс, но это звучало так, как будто вы разрабатываете в magento репо локально, а затем делитесь на modman репо. Почему бы просто не отредактировать ./modman/modulesname/CONTENTS в вашей среде IDE и передать код в репозиторий модулей независимо в том же рабочем процессе, который вы используете для разработки. вы можете использовать modman для развертывания в производство, вы можете взаимодействовать с отдельным репозиторием в папке .modman / modulesname / из каталога cli или путем добавления источника управления версиями в вашу IDE, хотя в действительности вы используете .basedir, чтобы сохранить пути, связанные с репозиторием, из вашего каталога. webroot будет играть лучше.

Существует также очень приятная особенность модмана, которую многие люди не используют. Сценарий bash интерпретирует файл .basedir в хранилище .modman, если файл не существует, modman применяет правила символической ссылки в файле modman на том же уровне, что и папка .modman ... если файл .basedir существует, содержание описывает подпапку, которая является верхним уровнем вашего кода Magento, который находится ниже пути .modman ... другими словами, вы можете запустить (и я это сделаю) все базовые версии Magento в папках, таких как «BaseMagento1.9.1.0». 'BaseMagento1.14.2.0' и modman инициализируют папку, содержащую их. Добавьте файл .basedir в путь .modman, и вы сможете легко изменить его содержимое. Это хорошо работает для тестирования версии.