Поиск по сайту OpenCart Club
Показаны результаты для тегов 'version control'.
Найдено: 1 результат
-
Придумываю рабочий процесс для проекта на 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. Но на старте этим лучше голову не забивать. Сам гитхаб рассказывает в статье, что сначала они всё делали сами руками, а потом пришли уже к автоматизации, когда рабочий процесс устоялся. При этом нужно следовать заложенной идеологии платформы. Не трогать напрямую файлы платформы, только через модификаторы. Временно в фичеветке можно поиграть с кодом, но фиксировать только через модификаторы. Такой вот велосипед. Что скажите? А как делаете вы? Повторюсь, именно для проекта интернет-магазина в целом, а не отдельного расширения или темы.