Придумываю воркфлоу с нуля для проекта на 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 в зависимости от технологий вашего проекта.
При этом нужно следовать заложенной идеологии платформы. Не трогать напрямую файлы платформы, только через модификаторы. Временно в фичеветке можно почудить, но фиксировать только через модификаторы.
Позже отпишусь как такой подход работает. И вообще стоит ли )
