trueboroda

Огромная просьба, ко всем участникам темы, высказываться по теме. Предлагать здоровую критику, улучшения, корректировки. Излагать своё видение процесса разработки структурно. Пока что благодаря, здоровой критике opencart-cms можно сказать, что подход номер два более верный. Поэтому отмечаю его как решение. В будущем возможно решение будет изменено или дополнено. Всем участникам спасибо! Хотелось бы очень получить рекомендации и от других опытных участников сообщества. Пока эта тема выглядит как тайна за семью печатями. =)

Со всем уважением к Вам. Но мне кажется, мы немного уходим от темы. Но тем не менее позволю себе тоже отступить и дать вам несколько советов. Вижу, ваш опыт работы в команде связан с определённой болью. Вы думаете, что люди вокруг вас должны быть как вы, близкие по духу. Но люди на самом деле, устроены примерно одинаково. Плюс-минус имеют какие-то психологические неверные паттерны поведения и привычки. Я думаю вам стоит обратить взор на себя и на ваше умение ладить с людьми. Библией в этом отношении является книга Дейла Карнеги: "Как заводить друзей и оказывать влияние на людей". Ещё вам может быть полезна книга: Тонкое искусство пофигизма. Тогда я уверен вы сможете найти себе хорошего партнёра или вырастить с пелёнок. Также очевидно, что в ваших командах как разы был слабо выстроенный воркфлоу с гитом. Ваше фичеветку кто-то правит? Это не позволительно без вашего ведома. Кто-то исправил уже залитую фичу в Дев ветке?! А где кодеревью при Pull Request, которое бы застопили вы, ведь ваш код правят. Также немаловажно в команде иметь общий фреймворк ценностей, процессов взаимодействия и менеджмента. По моему опыту отличным в этом отношении средством является Scrum. Но это только фреймворк, команда в целом должна разделять эти идеалы и уметь работать над собой тогда всё получится. Работа на дядю... Так или иначе у вас есть заказчик. Он тоже дядя или тётя ))) Из моего опыта дяди и тёти бывают очень мудрые, и от них есть чему поучиться. Но с ними как с другими людьми надо уметь ладить. Странный вы мне совет даёте, вы уж простите. Опыт разработки у меня 17 лет. И я работал в прекрасных командах и знаю что это такое. Не знаю про какие вы лясы говорите. Надеюсь и у вас будет такой прекрасный опыт.

В чём то с вами согласен. На вашем месте я возможно думал бы также. Обратите внимание на процесс описанный в третьем сообщении. Думаю как раз такой подход вам и близок. Он предполагает использование гит только в определённых случаях. Возможно вы до сих пор в контексте первого изложенного подхода, и поэтому так судите. А он почти полная противоположность второму подходу. Если вам второй ближе, но что то бы вы хотели добавить или улучшить, буду признателен за совет. Не считаю что, гит это только для команд. Гит это ещё и про историю и перемещения по ней, про безопасность в отношении сохранности кода. Кстати гит полезен и для ведения документации проекта, а не только кода. Да соглашусь. Многим достаточно просто делать бэкапы. И кода и БД. Сейчас делаю также. К слову. Создание команды планируется. Проект у нас отнюдь не маленький: интеграция с ERP, обработка прайсов с тысячами позиций, специфичные для продуктов расширения в роадмапе.

Признателен вам за ваше мнение. Мнение интересное и не лишённое правды, но только в другом контексте. Не совсем в отношении этой темы на мой взгляд. Вы приняли понятие контроль версий не в том значении. Я имел в виду контроль версий кода. В мире разработки - это отслеживание изменений сделанных командами разработки. Для этого используют такие инструменты как Git или Hg.

Очень признателен вам за ответ! Вы меня убедили в том, что для проектов на OpenCart более подходит процесс разработки описанный мною в третьем сообщении темы. То есть, Git - Да! для разработки компонентов: расширений, модификаторов, сборки своего форка платформы, создания или развития темы. Но держать весь проект магазина под Git нет необходимости. Магазин это набор цельных кирпичиков, стоящих на принципах модульности OC. И да! Полноценные миграции БД в данном подходе, я не считаю нужным использовать, так как скрипты меняющие базу разбросаны по разным расширениям. Но может понадобится инструмент упрощающий перенос изменений схемы и данных в будущем, да хотя бы даже просто для проверки соответствия. И очень интересно получить, совет от экспертов. Как раз взял на заметку и Flyway и Liquibase. Признателен вам за ответы и советы. Практически во всём с вами согласен.

Вообще главный вопрос. А стоит ли вообще держать весь проект под Git? Или может лучше следовать подходу близкому к изложенному в третьем сообщении? Верно ли, что такой подход к разработке проекта интернет-магазина является наиболее распространённым или общепринятым в мире Open Cart? Очень бы хотел услышать ваше мнение на этот вопрос.

Благодарю вас, за ваше мнение. Во многом с вами согласен. Основная проблематика изложена в заголовке темы в виде общего вопроса. Наверное я зря включил своё видение прямо в описание темы. Лучше было бы комментарием. И да это поток сознания =) Но как я вижу, вы довольно хорошо поняли суть обозначенной темы. Это радует! Спасибо за вашу внимание к теме. По структуре там в стиле вопрос-ответ. Автор изначальных более детальных вопросов темы не я. Но меня они заинтересовали, и я на них как-то попытался ответить со своей колокольни. На мой взгляд они очень хорошо подходят к теме. Теперь эта тема здесь. Надеюсь будет новичкам в помощь. С гитом у меня всё довольно не плохо. Спасибо) Но мы не обо мне. Гит знать должен каждый. Коммитить в мастер возможно только на старте процесса сборки. Тем более если работаешь один. Естественно когда пойдут доработки к Проду, такой подход исключается. Всё вы верно говорите. Про CICD вопросов нет. О том же отвечал, что на старте это ни к чему. И конечно мои идеи выглядят сырыми и не до конца продуманными. Поэтому они и вынесены на форму в качестве базы для обсуждения. Самый интересный момент. Уже спрашивал сегодня на эту тему в комментарии "Проблема переноса изменений БД". Вот вы пишите. Расскажите какие инструменты вы рекомендуете? Только лучше ответом на комментарий "Проблема переноса изменений БД" Благодарю.

Проблема переноса изменений БД В данном подходе отдельно следует выделить проблему апгрейда БД. Для удобства определения разницы между схемами БД сред и переноса изменений между ними желательно использовать дополнительный инструмент. Как инструмент командной строки CLI можно использовать уже ранее упомянутый skeema. Но не для целей автоматизации, а для ручного администрирования, удобнее будет использовать какой-то инструмент с визуальным интерфейсом. Нашёл два на мой взгляд не плохих списка средств для отслеживания изменений БД. Первый и второй. Вопрос. Какие инструменты для переноса изменений в БД используете вы на своих проектах, как для DDL, так и для DML? Навскидку требования такие: Генерация скрипта с Diff DDL Генерация скрипта с Diff DМL между выбранными таблицами. Сохранение скриптов. Возможность отредактировать выбранный скрипт. Возможность применить выбранный скрипт. Желательно Free

Переспал со своими мыслями и понял, что гляжу на проблему совсем не под тем углом. Изложенный мной подход, отслеживание кода монолита, произрастает из опасений, что что-то или кто-то может изменить код и это останется незаметным. Но такая ситуация возможна только если нарушаются основополагающие принципы платформы и её модульности. Исходя из чего, я описал другой подход к разработке, который назвал - общепринятым. Не знаю на сколько это соответствует действительности, и полноту выводов, но вот основные мысли. Общепринятый подход к разработке сайта на OpenCart 3. Ядро (платформа) и расширения неприкасаемы напрямую. Система установки расширений следит за этим строго. Поэтому следует максимально придерживаться этого правила. Для изменения кода используется система модификаторов. То есть конечное решение - это именно правильно собранная архитектура. Это фундамент - OC, и кирпичики - расширения и модификаторы, а также состояние БД (схемы и данных). В каком-то смысле стоит относится к готовым компонентам как скомпилированной версии кода с возможностью перегрузки кода, посредством модификаторов. Так может быть понятнее людям, пришедшим из мира компилируемых языков программирования. Исходя из этого основополагающего принципа вытекают следующие выводы: Отслеживать весь код не имеет смысла, так как он состоит из цельных элементов. Следует выбирать расширения, которые не изменяют файлов, только через модификаторы. Ещё лучше когда расширение ставиться через систему расширений, которая держит это правило под контролем. Контролю версий необходимо подвергать отдельные компоненты: расширения, модификаторы, темы, доработки самой платформы (своя сборка) - если ведётся их разработка. Если требуется доработка какого-то компонента можно использовать Git. Тогда стоит производить свои изменения поверх кода. Например, при выходе новой версии темы удобно сделать ребейс своих изменений и решать конфликты. Либо если изменений немного сделать отдельный модификатор. Для разработки нового компонента использовать контроль версий - Git. При разработке собственных компонентов на среде разработки Dev можно использовать симлинки для подключения темы или расширения. Апгрейд кода среды производится путём обновления компонентов одним из способов: заменой файлов или через переустановку используя менеджер расширений. Обновление платформы отдельная тема. Апгрейд БД производится либо встроенным скриптом расширения, либо вручную. Разработчикам решения для истории и справки следует вести документацию по процессу сборки и настройки приложения. Подойдёт wikki или просто markdown. Если вам есть, чем дополнить этот список или возразить - милости просим! критика приветствуется.

Также добавлю, что в моём рабочем процессе есть один неудобный момент связанный с модификаторами хранящимися в БД. Можно конечно выдирать SQL данных таблицы и контролировать. Но это та ещё жуткая матрёщка. На мой взгляд было бы очень хорошо, если бы сам код модификаторов хранился в файлах, а не в БД. А в БД бы хранилась только настройки модификаторов. Нет ли какого-то расширения модульной системы, которое модифицирует логику так, что модификатор кладётся в файлы, а в таблице oc_modification хранятся только данные настроек модификаторов?

Придумываю рабочий процесс для проекта на OC3. Это мой первый проект на OC. Какое-то время вёл разработку(точнее сборку проекта) по-старинке, без версионирования изменений. Просто делая бэкапы и ведя историю в записках. Но понял что, чем дальше так продолжать больше проект будет превращаться в дремучий лес. А в будущем предполагаются серьёзные доработки своей командой. Сложилось некое своё видение и идеи как организовать воркфлоу с применением Git в том числе и для БД. Искал на просторах интернета существующий опыт. Но ничего интересного кроме вот этого вопроса на хабре не нашёл. Там на основе поставленных вопросов я изложил своё видение, как контролировать историю развития проекта интернет-магазина, именно сайта, а не отдельного расширения. Велосипед изобретать не хочется, и поэтому вопрошаю к богатому мудрому сообществу разработчиков поделиться своим опытом. Как вы решаете данные вопросы, чтобы вести разработку магазина учитывая современные подходы? Цели: Контроль версий кода и схемы БД. Релизы. Возможность совместной работы над проектом небольшой командой. PR и Кодеревью. Потенциально CI/CD. Повторю здесь основные изначальные вопросы с хабра (немного перефразируя) и моё видение рабочего процесса. 1. Какие инструменты для контроля изменений и какой воркфлоу используете? 2. Как контролировать и переносить изменения БД? 3. Какой .gitinore вы используете для проектов на OC? 4. Возможно ли настроить автоматизацию доставки (CI/CD)? Как я это вижу? 1. Git и GitHub, skeema. В качестве подхода. Можно использовать стандартный Git Flow, а можно попробовать TBD. А на стадии сборки можно коммитить и прямо в мастер - Central Workflow. Гит конечно можно использовать. Но возникает вопрос - как отслеживать изменения от модулей в распределённой файловой структуре OC? А ещё код модификаторов который фиксируется в БД....Для себя решил так. Так как код OpenCart и его модульная система предполагает распределение расширения(ocmod) по иерархии каталогов, а также запись модификаторов, как в файловую структуру так и в БД, стоит рассматривать проект на OC как монолит кода. То есть, отслеживать каждое расширение отдельно, не имеет смысла, если вы не делаете расширение, а делаете магазин. Каждое добавляемое расширение делает инкремент к ценности и отслеживается как изменения всего проекта. Это даёт возможность также отследить, какие именно изменения привносит тот или иной модуль, когда это будет нужно. Также в купе с кодом стоит отслеживать и изменения схемы данных и самих данных, например oc_modification - изврат, но так всё будет под контролем. Об этом дальше в пункте 2.2. Использовать альтернативный версионным миграциям подход - следить за состоянием схемы данных, и возможно ключевых данных: базовые справочники, настройки, теже модификаторы в БД. Сам Гитхаб использует такой подход. Подробнее здесь.3. На гитхабе есть стандартный .gitignore для проектов на OC, когда заводите новый репозиторий. Но по сути за основу можно взять гитигнор из вашей сборки, например вот от клубной сборки. И исключить ещё папку с картинками каталога продуктов. А Остальное должно быть под контролем. Дальше нужно развивать ваш gitignore в зависимости от технологий вашего проекта. 4. Про автоматизацию доставки изменений (CI/CD). Опыт самого гитхаба, изложенный в статье по ссылке выше, доказывает, что всё возможно. Например с применением тех же GitHub Actions. Но на старте этим лучше голову не забивать. Сам гитхаб рассказывает в статье, что сначала они всё делали сами руками, а потом пришли уже к автоматизации, когда рабочий процесс устоялся. При этом нужно следовать заложенной идеологии платформы. Не трогать напрямую файлы платформы, только через модификаторы. Временно в фичеветке можно поиграть с кодом, но фиксировать только через модификаторы. Такой вот велосипед. Что скажите? А как делаете вы? Повторюсь, именно для проекта интернет-магазина в целом, а не отдельного расширения или темы.

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

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

А точно это нужно? Ведь их есть отличных открытых аж две штуки. Первый https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=22318 И второй OCMOD editor Brazil Бери да ставь. Мне больше первый нравится. А кому-то может второй.

Благодарю за ответ. Играюсь дальше с вашим замечательным Диспетчером. Модуль просто чудо! Многое понятно интуитивно. Есть несколько вопросов. Так уж вышло что наш поставщик включил Производителя в param. Вижу вот такое предупреждение в настройке автосоздания атрибутов. 1) Как создать производителей если они в теге param? 2) Можно ли всё таки автоматически создать атрибуты в нашем случае с этим поставщиком с Брендом в param? Не хотелось бы ручками сотни атрибутов создавать и потом маппить...