Какой у вас воркфлоу разработки интернет-магазина на OpenCart 3 с применением контроля версий как для кода так и для БД?

[trueboroda]

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

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

Такой вот велосипед. Что скажите? А как делаете вы?  Повторюсь, именно для проекта интернет-магазина в целом, а не отдельного расширения или темы.

Изменено 20.08.2024 в 15:46 пользователем trueboroda

[trueboroda]

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

 

[trueboroda]

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

Не знаю на сколько это соответствует действительности, и полноту выводов, но вот основные мысли. 

 

Общепринятый подход к разработке сайта на OpenCart 3. 

Ядро (платформа) и расширения неприкасаемы напрямую. Система установки расширений следит за этим строго. Поэтому следует максимально придерживаться этого правила. Для изменения кода используется система модификаторов. То есть конечное решение - это именно правильно собранная архитектура. Это фундамент - OC, и кирпичики - расширения и модификаторы, а также состояние БД (схемы и данных). В каком-то смысле стоит относится к готовым компонентам как скомпилированной версии кода с возможностью перегрузки кода, посредством модификаторов. Так может быть понятнее людям, пришедшим из мира компилируемых языков программирования.

Спойлер

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

Исходя из этого основополагающего принципа вытекают следующие выводы:

1. Отслеживать весь код не имеет смысла, так как он состоит из цельных элементов.

2. Следует выбирать расширения, которые не изменяют файлов, только через модификаторы. Ещё лучше когда расширение ставиться через систему расширений, которая держит это правило под контролем.

3. Контролю версий необходимо подвергать отдельные компоненты: расширения, модификаторы, темы, доработки самой платформы (своя сборка) - если ведётся их разработка.

4. Если требуется доработка какого-то компонента можно использовать Git. Тогда стоит производить свои изменения поверх кода. Например, при выходе новой версии темы удобно сделать ребейс своих изменений и решать конфликты. Либо если изменений немного сделать отдельный модификатор.

5. Для разработки нового компонента использовать контроль версий - Git.

6. При разработке собственных компонентов на среде разработки Dev можно использовать симлинки для подключения темы или расширения.

7. Апгрейд кода среды производится путём обновления компонентов одним из способов: заменой файлов или через переустановку используя менеджер расширений. Обновление платформы отдельная тема.

8. Апгрейд БД производится либо встроенным скриптом расширения, либо вручную.

9. Разработчикам решения для истории и справки следует вести документацию по процессу сборки и настройки приложения. Подойдёт wikki или просто markdown.

Если вам есть, чем дополнить этот список или возразить - милости просим! критика приветствуется. 

 

Изменено 21.08.2024 в 12:24 пользователем trueboroda

[trueboroda]

Проблема переноса изменений БД

В данном подходе отдельно следует выделить проблему апгрейда БД. Для удобства определения разницы между схемами БД сред и переноса изменений между ними желательно использовать дополнительный инструмент. Как инструмент командной строки CLI можно использовать уже ранее упомянутый skeema. Но не для целей автоматизации, а для ручного администрирования, удобнее будет использовать какой-то инструмент с визуальным интерфейсом.

 

Нашёл два на мой взгляд не плохих списка средств для отслеживания изменений БД. Первый и второй. 

 

Вопрос. 

Какие инструменты для переноса изменений в БД используете вы на своих проектах, как для DDL, так и для DML?  

 

Навскидку требования такие: 

• Генерация скрипта с Diff DDL
• Генерация скрипта с Diff DМL между выбранными таблицами.
• Сохранение скриптов. 
• Возможность отредактировать выбранный скрипт. 
• Возможность применить выбранный скрипт.
• Желательно Free 

[dreanei23]

спрашивается, причем здесь опенкарт

[opencart-cms]

Ваш текст явно показывает, что вы только начинаете разбираться с процессом разработки на OpenCart, и это нормально. Но нужно сразу отметить несколько ключевых проблем.

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

Во-вторых, подход к использованию Git у вас какой-то размазанный. Коммитить прямо в мастер — это не вариант для серьёзного проекта, особенно если в будущем планируете работать в команде. Git Flow или хотя бы простой Feature Branch Workflow — минимально необходимая схема для хоть какого-то порядка.

По поводу работы с БД и предложенного вами skeema. Идея отслеживать состояние схемы данных понятна, но её реализация вызывает сомнения. Если вы уже столкнулись с проблемами миграций, возможно, стоит рассмотреть более проверенные инструменты, которые действительно работают, а не изобретать велосипед.

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

И по поводу CI/CD. Да, GitHub Actions — это круто, но на данный момент ваши задачи, похоже, не требуют такой сложности. Разберитесь сначала с базовыми вещами, такими как миграции БД и нормальная работа с Git, а потом уже думайте об автоматизации.

Про модификаторы, хранящиеся в БД. Да, это неудобно, и вы правы, что это «жуткая матрёшка». Но это особенность OpenCart, и пока что лучше просто смириться с этим или искать сторонние решения, которые упрощают этот процесс. Ваше предложение — что-то делать вручную и контролировать это — не выдерживает критики.

В общем, пока ваши идеи выглядят сырыми и не до конца продуманными. Прежде чем предлагать что-то команде или сообществу, приведите свои мысли в порядок и определитесь с основными приоритетами.

[Bn174uk]

В 21.08.2024 в 15:43, trueboroda сказал:

Проблема переноса изменений БД

Написать свой функционал миграций

[trueboroda]

В 21.08.2024 в 15:58, opencart-cms сказал:

Ваш текст явно показывает, что вы только начинаете разбираться с процессом разработки на OpenCart, и это нормально. Но нужно сразу отметить несколько ключевых проблем.

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

Во-вторых, подход к использованию Git у вас какой-то размазанный. Коммитить прямо в мастер — это не вариант для серьёзного проекта, особенно если в будущем планируете работать в команде. Git Flow или хотя бы простой Feature Branch Workflow — минимально необходимая схема для хоть какого-то порядка.

По поводу работы с БД и предложенного вами skeema. Идея отслеживать состояние схемы данных понятна, но её реализация вызывает сомнения. Если вы уже столкнулись с проблемами миграций, возможно, стоит рассмотреть более проверенные инструменты, которые действительно работают, а не изобретать велосипед.

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

И по поводу CI/CD. Да, GitHub Actions — это круто, но на данный момент ваши задачи, похоже, не требуют такой сложности. Разберитесь сначала с базовыми вещами, такими как миграции БД и нормальная работа с Git, а потом уже думайте об автоматизации.

Про модификаторы, хранящиеся в БД. Да, это неудобно, и вы правы, что это «жуткая матрёшка». Но это особенность OpenCart, и пока что лучше просто смириться с этим или искать сторонние решения, которые упрощают этот процесс. Ваше предложение — что-то делать вручную и контролировать это — не выдерживает критики.

В общем, пока ваши идеи выглядят сырыми и не до конца продуманными. Прежде чем предлагать что-то команде или сообществу, приведите свои мысли в порядок и определитесь с основными приоритетами.

Благодарю вас, за ваше мнение. Во многом с вами согласен. Основная проблематика изложена в заголовке темы в виде общего вопроса.

Наверное я зря включил своё видение прямо в описание темы. Лучше было бы комментарием. И да это поток сознания =)  Но как я вижу, вы довольно хорошо поняли суть обозначенной темы. Это радует! Спасибо за вашу внимание к теме. 

По структуре там в стиле вопрос-ответ. Автор изначальных более детальных вопросов темы не я. Но меня они заинтересовали, и я на них как-то попытался ответить со своей колокольни. На мой взгляд они очень хорошо подходят к теме. Теперь эта тема здесь. Надеюсь будет новичкам в помощь. 

С гитом у меня всё довольно не плохо. Спасибо) Но мы не обо мне. Гит знать должен каждый. Коммитить в мастер возможно только на старте процесса сборки. Тем более если работаешь один. Естественно когда пойдут доработки к Проду, такой подход исключается. Всё вы верно говорите. 

Про CICD вопросов нет. О том же отвечал, что на старте это ни к чему. 

 

И конечно мои идеи выглядят сырыми и не до конца продуманными. Поэтому они и вынесены на форму в качестве базы для обсуждения. 

 

Самый интересный момент. Уже спрашивал сегодня на эту тему в комментарии "Проблема переноса изменений БД". Вот вы пишите.

Цитата

Если вы уже столкнулись с проблемами миграций, возможно, стоит рассмотреть более проверенные инструменты, которые действительно работают, а не изобретать велосипе

Расскажите какие инструменты вы рекомендуете? Только лучше ответом на комментарий "Проблема переноса изменений БД"

 

Благодарю. 

 

[trueboroda]

В 21.08.2024 в 15:58, opencart-cms сказал:

Ваш текст явно показывает, что вы только начинаете разбираться с процессом разработки на OpenCart, и это нормально. Но нужно сразу отметить несколько ключевых проблем.

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

Во-вторых, подход к использованию Git у вас какой-то размазанный. Коммитить прямо в мастер — это не вариант для серьёзного проекта, особенно если в будущем планируете работать в команде. Git Flow или хотя бы простой Feature Branch Workflow — минимально необходимая схема для хоть какого-то порядка.

По поводу работы с БД и предложенного вами skeema. Идея отслеживать состояние схемы данных понятна, но её реализация вызывает сомнения. Если вы уже столкнулись с проблемами миграций, возможно, стоит рассмотреть более проверенные инструменты, которые действительно работают, а не изобретать велосипед.

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

И по поводу CI/CD. Да, GitHub Actions — это круто, но на данный момент ваши задачи, похоже, не требуют такой сложности. Разберитесь сначала с базовыми вещами, такими как миграции БД и нормальная работа с Git, а потом уже думайте об автоматизации.

Про модификаторы, хранящиеся в БД. Да, это неудобно, и вы правы, что это «жуткая матрёшка». Но это особенность OpenCart, и пока что лучше просто смириться с этим или искать сторонние решения, которые упрощают этот процесс. Ваше предложение — что-то делать вручную и контролировать это — не выдерживает критики.

В общем, пока ваши идеи выглядят сырыми и не до конца продуманными. Прежде чем предлагать что-то команде или сообществу, приведите свои мысли в порядок и определитесь с основными приоритетами.

 

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

Верно ли, что такой подход к разработке проекта интернет-магазина является наиболее распространённым или общепринятым в мире Open Cart?

Очень бы хотел услышать ваше мнение на этот вопрос. 

Изменено 21.08.2024 в 14:08 пользователем trueboroda

[opencart-cms]

Честно говоря, я вообще сомневаюсь, для чего всё это в OpenCart. Вся эта история с Git, миграциями, CI/CD — это, конечно, круто, но OpenCart — это не тот движок, где такие сложности прям жизненно необходимы. Если вы на нём делаете простой интернет-магазин, то, по большому счёту, весь этот пафос с версиями и сложными воркфлоу может оказаться излишним.

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

Так что да, весь этот ваш "велосипед" смотрится излишним усложнением. В OpenCart гораздо важнее правильно организовать сам процесс разработки, а не навешивать кучу инструментов и методов, которые больше подходят для крупных корпоративных проектов. Это не значит, что все эти инструменты плохи, но, возможно, их применение в данном случае просто неоправданно. 

Отдельно про миграции БД. Есть проверенные инструменты вроде Flyway или Liquibase, которые отлично справляются с задачей версионирования базы данных. Если вам нужно что-то более специализированное для MySQL/MariaDB, то посмотрите на DBmaestro. Эти инструменты не только позволяют отслеживать изменения схемы БД, но и упрощают перенос данных между разными средами.

Вот только прикол в том, что, оно вам, скорей всего, это все, не надо)

В общем:
Git, CI/CD, миграции — всё это классные штуки, но они должны решать конкретные задачи, а не просто быть частью проекта для галочки. OpenCart — это не та платформа, где вам нужно задействовать весь этот арсенал, если нет реальной необходимости.

Везде должна быть рациональность!

[Venter]

считаю что данная тема не ко всем проектам подходит, а к опенкарт так вообще....

у опенкарт есть реальная проблема, а проблема эта - многие модули могут не подойти к новой версии опенкарта, это к примеру. Допустим у человека есть магазин на какой нибудь версии типа 3.0.7, стоят модули, магазин пофиксин разработчиком (устранены те или иные неполадки/проблемы), всё работает, в штате разработчика нет, заказы идут, и вот теперь вопрос - а зачем ему, хозяину сайта обновляться и иметь контроль на версиями?

в чем суть обновления? 

стремиться за развитием php или опенкарт?

то есть при изменении версии хозяину сайта нужно найти разработчика, если такового нет, заплатить ему за обновление версии опенкарта и бд, протестировать магазин на наличие ошибок, так? Так! Заплатить деньги еще нужно за работу прогера.

а суть? магазин как работал на старой версии, так и допустим после обновления и тестов, работает в том режиме.

смысл как то теряется в контроле версиями, когда магазин работает как часы допустим на той же пхп 7.4, и на ней он еще как минимум проработает лет 5 точно, а потом уже можно обновляться, и то при условии что если есть обновление модулей.

Мое мнение таково, что вообще не стоит себе забивать этой темой голову, ЕСЛИ ты не работаешь над таким проектом где есть контроль версий

[trueboroda]

В 21.08.2024 в 19:50, opencart-cms сказал:

Честно говоря, я вообще сомневаюсь, для чего всё это в OpenCart. Вся эта история с Git, миграциями, CI/CD — это, конечно, круто, но OpenCart — это не тот движок, где такие сложности прям жизненно необходимы. Если вы на нём делаете простой интернет-магазин, то, по большому счёту, весь этот пафос с версиями и сложными воркфлоу может оказаться излишним.

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

Так что да, весь этот ваш "велосипед" смотрится излишним усложнением. В OpenCart гораздо важнее правильно организовать сам процесс разработки, а не навешивать кучу инструментов и методов, которые больше подходят для крупных корпоративных проектов. Это не значит, что все эти инструменты плохи, но, возможно, их применение в данном случае просто неоправданно. 

Отдельно про миграции БД. Есть проверенные инструменты вроде Flyway или Liquibase, которые отлично справляются с задачей версионирования базы данных. Если вам нужно что-то более специализированное для MySQL/MariaDB, то посмотрите на DBmaestro. Эти инструменты не только позволяют отслеживать изменения схемы БД, но и упрощают перенос данных между разными средами.

Вот только прикол в том, что, оно вам, скорей всего, это все, не надо)

В общем:
Git, CI/CD, миграции — всё это классные штуки, но они должны решать конкретные задачи, а не просто быть частью проекта для галочки. OpenCart — это не та платформа, где вам нужно задействовать весь этот арсенал, если нет реальной необходимости.

Везде должна быть рациональность!

Очень признателен вам за ответ! Вы меня убедили в том, что для проектов на OpenCart более подходит процесс разработки описанный мною в третьем сообщении темы.  

То есть, Git - Да! для разработки компонентов: расширений, модификаторов, сборки своего форка платформы, создания или развития темы. 

Но держать весь проект магазина под Git нет необходимости. Магазин это набор цельных кирпичиков, стоящих на принципах модульности OC.

И да! Полноценные миграции БД в данном подходе, я не считаю нужным использовать, так как скрипты меняющие базу разбросаны по разным расширениям. Но может понадобится инструмент упрощающий перенос изменений схемы и данных в будущем, да хотя бы даже просто для проверки соответствия. И очень интересно получить, совет от экспертов. Как раз взял на заметку и Flyway и Liquibase.

Признателен вам за ответы и советы. Практически во всём с вами согласен. 

 

Изменено 22.08.2024 в 07:46 пользователем trueboroda

[trueboroda]

В 21.08.2024 в 20:15, Venter сказал:

считаю что данная тема не ко всем проектам подходит, а к опенкарт так вообще....

у опенкарт есть реальная проблема, а проблема эта - многие модули могут не подойти к новой версии опенкарта, это к примеру. Допустим у человека есть магазин на какой нибудь версии типа 3.0.7, стоят модули, магазин пофиксин разработчиком (устранены те или иные неполадки/проблемы), всё работает, в штате разработчика нет, заказы идут, и вот теперь вопрос - а зачем ему, хозяину сайта обновляться и иметь контроль на версиями?

в чем суть обновления? 

стремиться за развитием php или опенкарт?

то есть при изменении версии хозяину сайта нужно найти разработчика, если такового нет, заплатить ему за обновление версии опенкарта и бд, протестировать магазин на наличие ошибок, так? Так! Заплатить деньги еще нужно за работу прогера.

а суть? магазин как работал на старой версии, так и допустим после обновления и тестов, работает в том режиме.

смысл как то теряется в контроле версиями, когда магазин работает как часы допустим на той же пхп 7.4, и на ней он еще как минимум проработает лет 5 точно, а потом уже можно обновляться, и то при условии что если есть обновление модулей.

Мое мнение таково, что вообще не стоит себе забивать этой темой голову, ЕСЛИ ты не работаешь над таким проектом где есть контроль версий

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

[Venter]

В 22.08.2024 в 12:43, trueboroda сказал:

Я имел в виду контроль версий кода

я вам и писал про это, я имел  виду и код и всё остальное

 

В 22.08.2024 в 12:38, trueboroda сказал:

То есть, Git - Да

а зачем с Git работать, допустим если нет команды?

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

для многих достаточно периодически делать бекапы да и всё на этом, так что Git скорее весит под вопросом.

Не нужно вам этой темой забивать голову, только время тратить 

[trueboroda]

В 23.08.2024 в 11:24, Venter сказал:

я вам и писал про это, я имел  виду и код и всё остальное

 

а зачем с Git работать, допустим если нет команды?

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

для многих достаточно периодически делать бекапы да и всё на этом, так что Git скорее весит под вопросом.

Не нужно вам этой темой забивать голову, только время тратить 

В чём то с вами согласен. На вашем месте я возможно думал бы также. Обратите внимание на процесс описанный в третьем сообщении. Думаю как раз такой подход вам и близок. Он предполагает использование гит только в определённых случаях.

Возможно вы до сих пор в контексте первого изложенного подхода, и поэтому так судите. А он почти полная противоположность второму подходу. 

Если вам второй ближе, но что то бы вы хотели добавить или улучшить, буду признателен за совет.

 

Не считаю что, гит это только для команд. Гит это ещё и про историю и перемещения по ней, про безопасность в отношении сохранности кода. Кстати гит полезен и для ведения документации проекта, а не только кода.

Да соглашусь. Многим достаточно просто делать бэкапы. И кода и БД. Сейчас делаю также.

 

К слову. Создание команды планируется. Проект у нас отнюдь не маленький: интеграция с ERP, обработка прайсов с тысячами позиций, специфичные для продуктов расширения в роадмапе.

 

Изменено 23.08.2024 в 12:28 пользователем trueboroda

[Venter]

В 23.08.2024 в 17:25, trueboroda сказал:

Не считаю что, гит это только для команд. Гит это ещё и про историю и перемещения по ней, про безопасность в отношении сохранности кода. Кстати гит полезен и для ведения документации проекта, а не только кода.

Да соглашусь. Многим достаточно просто делать бэкапы. И кода и БД. Сейчас делаю также.

 

К слову. Создание команды планируется. Проект у нас отнюдь не маленький: интеграция с ERP, обработка прайсов с тысячами позиций, специфичные для продуктов расширения в роадмапе.

Не знаю как у вас, но минимум за 10 лет я пока вижу совершенно другую ситуацию в плане разработке. Чаще всего команды работают на дядю, а это увы не по мне, я работал с Гит и мне не очень это нравится, особенно когда когда в приложении пишешь какой то сервис, используешь библиотеки от проекта, а какой то прогер в команде берет и переписывает допустим часть функций которые используешь в сервисе, причем после правок не ставит сразу в курс, пока не посмотришь кометы. В итоге из за таких чудил приходится писать свои библиотеки независимо от самого проекта, дабы из за чужих правок не пришлось переписывать свой код. В общем меня не устраивает работать в команде, по любому это работа в основном на дядю, да и видимо у меня неудачный опыт был и не один причем. 

А так вообще сейчас конечно видно что много людей зовут в сферу IT, но в основном это фирмы. Вот если б найти прогера похожего по духу работы с тобой - вот это считаю круто, и можно тогда что то вместе делать.

Я допустим сейчас 2 проекта поддерживаю, второй проект содержит в себе несколько сайтов на половину связанные с ИИ, и всё это я пишу сам, у меня нет помошника, потому что найти не могу близкого по духу, а на тестирование совместной работы, подойдет человек или нет времени нет.

короче, длинная эта тема для разговора и дискуссии, а времени мало. 

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

[trueboroda]

В 23.08.2024 в 15:44, Venter сказал:

Не знаю как у вас, но минимум за 10 лет я пока вижу совершенно другую ситуацию в плане разработке. Чаще всего команды работают на дядю, а это увы не по мне, я работал с Гит и мне не очень это нравится, особенно когда когда в приложении пишешь какой то сервис, используешь библиотеки от проекта, а какой то прогер в команде берет и переписывает допустим часть функций которые используешь в сервисе, причем после правок не ставит сразу в курс, пока не посмотришь кометы. В итоге из за таких чудил приходится писать свои библиотеки независимо от самого проекта, дабы из за чужих правок не пришлось переписывать свой код. В общем меня не устраивает работать в команде, по любому это работа в основном на дядю, да и видимо у меня неудачный опыт был и не один причем. 

А так вообще сейчас конечно видно что много людей зовут в сферу IT, но в основном это фирмы. Вот если б найти прогера похожего по духу работы с тобой - вот это считаю круто, и можно тогда что то вместе делать.

Я допустим сейчас 2 проекта поддерживаю, второй проект содержит в себе несколько сайтов на половину связанные с ИИ, и всё это я пишу сам, у меня нет помошника, потому что найти не могу близкого по духу, а на тестирование совместной работы, подойдет человек или нет времени нет.

короче, длинная эта тема для разговора и дискуссии, а времени мало. 

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

Со всем уважением к Вам. Но мне кажется, мы немного уходим от темы. Но тем не менее позволю себе тоже отступить и дать вам несколько советов.  Вижу, ваш опыт работы в команде связан с определённой болью. Вы думаете, что люди вокруг вас должны быть как вы, близкие по духу. Но люди на самом деле, устроены примерно одинаково. Плюс-минус имеют какие-то психологические неверные паттерны поведения и привычки. Я думаю вам стоит обратить взор на себя и на ваше умение ладить с людьми. Библией в этом отношении является книга Дейла Карнеги: "Как заводить друзей и оказывать влияние на людей". Ещё вам может быть полезна книга: Тонкое искусство пофигизма. Тогда я уверен вы сможете найти себе хорошего партнёра или вырастить с пелёнок.

Также очевидно, что в ваших командах как разы был слабо выстроенный воркфлоу с гитом. Ваше фичеветку кто-то правит? Это не позволительно без вашего ведома. Кто-то исправил уже залитую фичу в Дев ветке?! А где кодеревью при Pull Request, которое бы застопили вы, ведь ваш код правят. 

 

Также немаловажно в команде иметь общий фреймворк ценностей, процессов взаимодействия и менеджмента. По моему опыту отличным в этом отношении средством является Scrum. Но это только фреймворк, команда в целом должна разделять эти идеалы и уметь работать над собой тогда всё получится. 

Работа на дядю... Так или иначе у вас есть заказчик. Он тоже дядя или тётя ))) Из моего опыта дяди и тёти бывают очень мудрые, и от них есть чему поучиться. Но с ними как с другими людьми надо уметь ладить. 

 

Странный вы мне совет даёте, вы уж простите. Опыт разработки у меня 17 лет. И я работал в прекрасных командах и знаю что это такое. Не знаю про какие вы лясы говорите. Надеюсь и у вас будет такой прекрасный опыт.  

[trueboroda]

Огромная просьба, ко всем участникам темы, высказываться по теме. Предлагать здоровую критику, улучшения, корректировки. Излагать своё видение процесса разработки структурно. 

 

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

 

Хотелось бы очень получить рекомендации и от других опытных участников сообщества. Пока эта тема выглядит как тайна за семью печатями. =)

[Venter]

В 25.08.2024 в 17:51, trueboroda сказал:

Странный вы мне совет даёте, вы уж простите. Опыт разработки у меня 17 лет

ну раз такой большой опыт, то к чему все эти переписки про контроль версий и тд? Вы что себя хотите выставить знатаком? Если такой большой опыт, отличная работа с командами к чему вся эта писанина?

сначала вы задаете вопросы про контроль версии, про гит и тд, потом пишите что у вас всё нормально и прекрасно работаете и всё знаете и что вам не нужно давать советов потому что у вас крутой опыт, короче всё это выглядит смешно......

Удачи вам

[Venter]

В 25.08.2024 в 17:51, trueboroda сказал:

Работа на дядю... Так или иначе у вас есть заказчик. Он тоже дядя или тётя )))

по крайне мере у меня нет постоянного графика работы, мне не нужно ходить к дяди на работу с понедельника по пятницу и работать с 9-18, понятно о чем я писал? если нет, ваши проблемы

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

В общем УДАЧИ, пишите дальше..... но не надо цитировать меня