Collaborative work in project

Обсуждения
#1

Hello all!
Could you please share your practice of collaborative work in project with Cuba. There are more than one developer in team.
I am interested in mergers, update project changes, work with data, storage structure changes and others. What instruments and approaches have you been using? How can we use git: what files are common and what requirements by it are determined by Cuba. What about CI?

Всем привет!
Поделитесь, пожалуйста, опытом организации совместной работы над проектом командой из нескольких разработчиков. Какие инструменты, методы, подходы вы использовали. Какие аспекты деятельности у вас сейчас автоматизированы, а какие делаете в ручную? Используете ли git: какие файлы выгружаете, а какие не должны мержиться, чтобы удовлетворить требованиям платформы (чтобы проект собирался и запускался)? Настроены ли процессы CI?

1 симпатия
#2

Доброго времени суток!

У нас 2-4 участника на 1 проект, на базе Cuba-platform, работающих с Cuba-Studio.
Ранее из RAD-систем работали с MS LightSwitch и, на старте тоже пережали за “правильную технологию работы над совместным проектом”.
На практике с Cuba-platform оказалось все проще.
У нас каждый более-менее активный участник проекта имеет собственную установку Cuba-Studio и собственный локальный экземпляр СУБД.
В качестве системы контроля версий используем MS Team Fundation Service с хранилищем GIT для проектов Cuba-platform.
По сути, единственное ограничение, которого мы стараемся придерживаться - “на уровне модели данных не вносить одновременно изменений в одну и ту же сущность”.
Стандартно - одна защищенная ветка master для проекта в TFS, у каждого участника своя ветка в TFS, со слиянием в ветку msater в среднем 1-2 раза в неделю.
На сегодня, самый длительный период работы с командным проектом - полгода.
Ни разу не было каких либо серьезных проблем со сборкой проекта после мерджа (в отличии от LightSwitch при более строгих правилах работы команды).
Примерно в 80% случаев это автоматический мердж в master на стороне TFS. В остальных случаях ручное слияние с простым решением конфликтов изменений, в случае, если более 1 участника внесли измерения в одну и ту же сущность/экран.
При наличие каких либо проблем в работоспособности приложения после такого слияния и сборки всегда спасал Clean в CUBA-Studio и повторная переборка решения.

7 симпатий
#3

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