Как организовать разработку с системой контроля версий?

Question

[Vorchun]

Я менеджер. В подчинении есть несколько сотрудников, в частности верстальщики и программисты. Занимаемся поддержкой проектов. Т.е. часто задача — нарисовать, заверстать, прикрутить и перенести. В день несколько таких задач.


Хочется, чтобы появился контроль изменений. Т.е. было понятно что, когда и когда изменили. И, естественно, возможность отката.


В компании стоит сервер разработки. После внесения изменений, они переносятся на хостинг. Т.е. сайт в 2 версиях: локальная и продакшн. Получается сложный путь: настроить у верстка на машине вебсервер, забрать копию к себе, установить как-то в свой веб-сервер, залить изменения обратно. А как он может гонять туда-сюда БД?


Как быть с текстовыми файлами — примерно понятно. А как быть с БД?


Сервер у нас под linux, все рабочие места под win, редакторы от JetBrains


Если непонятно объяснил, задавайте, пожалуйста, уточняющие вопросы.

Answer 1

[Александр]

Локальная БД у разработчика — на нее изменения сам разработчик накатывает руками, а другие разработчики с помощью миграций.
БД на общем дев-сервере (если таковой есть) на который изменения накатываются миграциями
БД на продакт сервере — также накатываются миграции из master ветки.

Вам останется выбрать только удобный вам способ управления миграциями. Во многих фреймворках есть встроенные средства для миграций.

Comments

[Vorchun]

У нас в основном сайты на UMI.CMS С проектами на Symfony вопроса нет — есть средства, разработчик один. А вот под ЮМИ — несколько верстаков и несколько программистов. Один сайт делает несколько сотрудников

Answer 2

[KEKSOV]

1. Для отслеживания изменений в БД несколькими разработчиками воспользуйтесь deltaSQL
2. Для управления проектами и исходниками очень советую купить лицензионную JIRA и Fisheye (цена на оба продукта $10 для 10 разработчиков)
3. Если по каким-то причинам п.2 не может быть реализован, то воспользуйтесь аналогичным сервисом bitbucket.org Он позволяет бесплатно открывать приватные репозитории. Сперва зарегистрируйтесь сами, а потом пришлите инвайты своим сотрудникам — это позволит увеличить число бесплатных пользователей, которые могут работать над вашими проектами.

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

ПС. Не в коем случае не ведите разработку на продакшн серверах! Все то же самое окружение можно настроить и под виндой.

Comments

[batment]

>то воспользуйтесь аналогичным сервисом bitbucket.org
В него кстати встроена JIRA. Она сильно отличается от коммерческой версии?

[KEKSOV]

Я бы сказал, что она сильно упрощена по сравнению с полной версией.

Answer 3

[Vorchun]

Спасибо за ответы. Кое-что взял на вооружение. Сложновато, я все же менеджер )

Правильно ли я понимаю, что если команда работает над одним сайтом (у нас клиенты все с коммерческими CMS), то перед внесением изменений в сайт, разработчик должен забрать с dev сервера копию сайта к себе (установить на свой локальный сервер)?

Если да, то пока проблема в этом. Проекты все на dev сервере, и не хотят ставить локально сервер и забирать проект к себе вместе с БД и контентом. Другие варианты схемы работы могут быть?

Comments

[Vorchun]

на мой вопрос, вроде бы ответ «да» stackoverflow.com/a/425733 Но тут не слово про БД. Когда забирают сайт на локальный сервер на машине разработчика, БД подключается с dev сервера или тоже забирается. Если забирается, то как (чем) потом склеивается две БД разных разработчиков? Мы работаем с PHP и MySQL, преимущественно с UMI.CMS

[Dmitry Shvalyov]

Странно, что эти вопросы не решают сами программисты. При модификации баз данных все равно реализуется какой-то механизм миграции (модификации структуры), на dev сервере тестовые данные и они не переходят на продакшн. Я как разработчик сам для себя изучил git и использую его в своей работе. Попытки внедрить его среди контентщиков пока не имеют успеха из-за высокого порога вхождения. Менеджеров же это совсем не касается.

[Dmitry Shvalyov]

И, кстати, для работы с СКВ понадобиться отдельная рабочая копия сайта каждому разработчику — с общими исходниками несколько разработчиков работать не смогут. И желательно чтобы окружение локального сервера соответствовало окружению продакшн, т.е. поднять персональный денвер под windows каждому разработчику будет не лучшей идеей.

[Vorchun]

dshster, странно конечно! Но я вижу, процесс можно улучшить. Моя задача описать проблему, предложить идею, а разработчики уже или примут к сведению, или найдут решения. Я даю лишь точку отсчета, показываю, что можно сделать иначе. Страх к переменам никто не отменял