Управління версіями для розробки модуля

Мені цікаво, чи є якісь умовні умови щодо управління версіями для розробки модуля, який ви використовуєте як в одному екземплярі Magento, так і хочете випустити як модуль спільноти.

Спочатку те, що я намагався зробити, - це використовувати модем для управління модулем поза моїм основним сховищем Magento. Але це виявилося проблематичним на кількох рівнях. Наявність єдиного сховища, яке ви можете легко встановити в різних середовищах або повернути назад у виробництво, є надзвичайно корисним, і я б навіть сказав, що це стало необхідною частиною мого робочого процесу.

Я зараз займаюся розробкою його всередині мого сховища веб-сайтів, і незабаром планую розбити його на окремий сховище. У цей момент я, ймовірно, буду:

• Побудувати в моєму локальному середовищі в окремому сховищі модулів, використовуючи modman
• Скопіюйте зміни у сховище сайту, коли я буду готовий до розгортання коду

Сподіваючись, що є кращий спосіб?

У нас є кілька модулів, де ми це зробили, і що ми по суті зробили:

• Налаштуйте модуль Git repo для модуля.
• Розгорніть цей модуль у кодовій базі виробничого сайту та виконайте все, включаючи:
  • софт-посилання, створені модменом
  • каталог .modman, в якому знаходиться сховище клонованого модуля
• Використовуйте модман для "розгортання" його в інших версіях та / або середовищі розробників для розробників та тестування.

Таким чином ви отримуєте гнучкість, необхідну для розробки модулів, версій коду на одному сайті, і якщо ви внесете зміни в модуль в кодовій базі одного сайту, ви можете скористатись ними прямо в сховищі модулів, оскільки РЕПО є в каталозі .modman.

ОНОВЛЕННЯ: Коли я спочатку писав це, я не взяв до уваги у своїй відповіді, що Git не дозволяє (під) модулі залучатись до сховища, і в такому випадку "фіксація всього" потребує певної розробки!

Між іншим, це тому, що я це робив частіше, використовуючи модем для розгортання модулів, розміщених у Git repos, у виробничу кодову базу даних SVN ... і в Subversion немає жодних скрупульозних перешкод, щоб вона не зафіксувала все дерево Git до VCS.

Тож ось іде…

1. Якщо ви використовуєте SVN для розміщення коду виробничого сайту, у вас не повинно виникнути проблем, оскільки Subversion практично не має поняття підмодулів. Це не буде проти.

2. Якщо ви використовуєте Git для коду виробничого сайту, вам доведеться використовувати підмодулі, щоб "зробити все" для сховища коду сайту. Після використання модмена для клонування чогось подібного:

   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 repo

Що стосується структури каталогів, вона є мінімальним і бажано, щоб модуль встановлений у кодовому пулі спільноти.

Орієнтовна мінімальна запропонована структура каталогів:

.
└── 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 з описом, деякими знімками екрана та деякими мітками.
• Зв'язок із встановленим демонстраційним магазином теж буде непоганим
• Екранний / двохвилинний огляд вашого продукту

Редагувати: я, можливо, зрозумів неправильно.

Використання комбінації модман / gitignore може утримати модуль в оточенні від тестового середовища. Використовуючи вищевказану структуру папок, ви можете явно дозволити фіксацію / встановлення до репо-файлу лише файлів вашого модуля. У цьому випадку відповідь Девіда більше застосовна. Модерна підтримка розробки / розгортання, здається, є консенсусом.

Навіть ще не спробувавши його, я б рекомендував використовувати для цього композитор .

Версія, включаючи залежності

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

Недоліки

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

Тому нам знадобиться якийсь кеш-пам'ять або проксі, який зберігає ці модулі, щоб ми завжди могли розгорнути.

Satis, здається, може досягти цієї мети (див. Https://github.com/researchgate/broker ), а моє запитання /programming//q/16211671/288568

Кален,

Можливо, я не зовсім зрозумів ваш робочий процес правильно, але це звучало так, ніби ви розвиваєтеся в magento repo локально, потім розділяєтесь на repo modman. Чому б просто не відредагувати ./modman/modulesname/CONTENTS у вашому IDE і не надіслати код незалежно від модуля репо в тому ж робочому потоці, який ви використовуєте для розробки. ви можете використовувати модман для розгортання у виробництві, ви можете взаємодіяти з окремими репо-файлами в .modman / modulename / папці з cli або додаючи джерело версії до IDE, хоча реально використовуючи .basedir, щоб уникнути пов'язаних шляхів вашого сховища з вашими webroot буде грати краще.

Також є дійсно приємна особливість модмена, якою багато людей, здається, не користуються. Сценарій bash інтерпретує файл .basedir у сховищі .modman, якщо у файлі відсутній модем, застосовує правила симпосилання у файлі modman на тому ж рівні, що і папку .modman ... якщо файл .basedir існує, Вміст описує підпапку, яка є найвищим рівнем коду Magento, один вниз від шляху .modman ... іншими словами, ви можете запустити (і я це роблю) всі базові версії Magento в папках типу "BaseMagento1.9.1.0" 'BaseMagento1.14.2.0' та модем входять у папку, що містить їх. Додайте .basedir файл у шлях .modman, і ви можете легко змінювати вміст. Це добре працює для тестування версій.