Какой у вас процесс разработки сайта(opencart) с применением git? Как вы синхронизируете БД в git? Что вы закрываете в .gitignore для opencart?

Question

[Сергей]

Основная задача: наладить разработку 2-3 разработчиками интернет-магазина(opencart). Разработчики работают не под одной крышей.

Вытекающие вопросы:

1) Как процесс создания интернет-магазина проходит у Вас? Какими инструментами для командной работы пользуетесь?

2) Работа с git. Можно ли изменения в основной ветке, каким-то образом, автоматически закидывать на какой-нить хостинг, где эту ветку смогут просматривать разработчики и заказчики? По типу коммита в удаленный репозиторий. Ведь у нас в том же Bitbucket-е хранится рабочая версия сайта. Но посмотреть эти файлы "в работе" мы можем либо локально, либо скидывая по тому же фтп(что не очень удобно). К примеру я слышал, что у пхп-шторм есть возможность делать коммит и сразу отправлять по фтп файл на тестовый домен/хостинг.

3) Как вы синхронизируете БД? Ведь я могу у себя изменить БД, но об моих изменениях не узнают остальные... И каждый раз надо ее экспортировать/импортировать, что тоже накладно.

4) Что вы закрываете в .gitignore для opencart?

Answer 1

[sim3x]

опенкарт не предназначен для нормальной разработки
гит, миграции, тестирование - не про данную поделку

Comments

[Сергей]

Что можете посоветовать в замен?

[sim3x]

zeyser: magento.com

[Сергей]

Спасибо!

Answer 2

[bigtrouble]

Не скажу за опенкарт и гит, но мы у себя используем hg(думаю тоже можно и на гите) и процесс выглядит примерно следующим образом:
На сервере два домена - основной и тест.основной. Все пуши идут на тест.основной, на нём настроен хук, на изменение репо, который выталкивает всё в основной.
На тест.основной ветка всегда тест, на основном default.
Сейчас переползаем на bitbucket для Code Review, там будет хук который дёргает домен, на сервере затем следует pull с битбакета и пуш на основной. Как-то так.

2. Автоматом можно, смотрите в сторону хуков, у вас там же будет репо, но всегда на одной ветке. FTP вообще бы не рекомендовал использовать для синхронизации файлов.

3. БД да, у нас с ней проблема, договариваемся, таскаем бекапы, но по хорошему стоит добавить систему миграций.

4. Не могу ничем помочь)

P.S. Так же настроены хуки, чтобы не коммитить напрямую в тест, не давать сливать из теста в основную ветку или разрабатываемую, только в тест можно вливать. Ещё хук на то чтобы не коммить в дефолт напрямую, только сливать. И ещё чтобы тест нельзя слить с основной веткой

Comments

[Сергей]

bigtrouble Что посоветуете почитать по хукам?

[bigtrouble]

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

[bigtrouble]

zeyser: Вообще если дальше размышлять на тему как всё организовать, то следущим пунктом идёт - CI, т.е. репо вебхуком стучит к нему, он берёт репо, прогоняет тесты, покрытие кода и т.д. и далее CI уже разворачивает проект в продакшене

[Сергей]

CI - Common Interface?

[bigtrouble]

zeyser: Continuous Integration
А по поводу показа заказчику фич, если у вас всё через http работает можете использовать ngrok для проброса локалки во внешний мир

[bigtrouble]

https://www.phptesting.org/ что-то тип этого, тестирование как-то не прижилось у нас, поэтому пока не разбирался с этим всем

[Сергей]

bigtrouble: Спасибо за подробности!

Answer 3

[trueboroda]

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

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

Позже отпишусь как такой подход работает. И вообще стоит ли )