Реклама на этом месте
Форум 1С
Форум 1С
Программистам. Бухгалтерам. Администраторам. Пользователям
Задай вопрос - получи решение проблемы. Без троллинга и флуда.
17 Дек 2017, 11:20
МультиВход
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Не получили письмо с кодом активации?
 
collapse

Автор Тема: 150 способов коллективной разработки на 1с  (Прочитано 3546 раз)

0 Пользователей и 1 Гость просматривают эту тему.



То что 1с позволяет вести коллективную разработку приложений ни для кого не секрет. Есть хранилище, многие даже знают как оно работает. Но к разработке с использованием хранилища можно подойти по разному.

Как разрабатывают без использования хранилища.

Берется конфигурация. Копируется на всех разработчиков. Каждый работает со своей базой. Разработчики на берегу договариваются кто какие объекты изменяет. По окончании работ все конфигурации объединяются.
Очевидные минусы такого подхода:

  • Система не контролирует изменяемые разработчиками объекты. То есть, один объект может быть дважды изменен разными разработчиками, что приведет к потерям времени при объединении и возможным ошибкам.
  • Значительную часть времени отнимает процесс объединения конфигураций.
Использование хранилища. Рабочая конфигурация подключена к хранилищу.

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

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

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

Использование хранилища. Рабочая конфигурация не подключена к хранилищу. Обновление боевой производится накатыванием cf файла. Боевая база находится на поддержке конфигурации хранилища.

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

Здесь уже соответственно процесс выкладывания изменений разработчиком отделен от процесса накатывания на боевую базу тем что еще нужно зарелизить cf файл. То есть, тестировщик (один человек, команда, или просто алгоритм) тестируют на стабильность готовую программу и уже по результатам создают cfник или не создают.

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

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


Последний раз редактировалось: MuI_I_Ika; 18 Ноя 2014, 21:57



TreeDogNight : 14 Ноя 2014, 15:33
Используем 3й вариант, но без использования поддержки. Вручную перекидываем cf на сервер заказчику, и делаем Сравнение и объединение
mixqn : 14 Ноя 2014, 16:22
пользуемся вторым
pumbae : 17 Ноя 2014, 14:04
Использую 4 вариант:
у каждого по хранилищу, каждое хранилище синхронизируется с git репозиторием, в git это организованно как отдельные ветки и периодически делается синхронизация с cf файлов итоговых, т.к. это все считается как отдельные ветки в git, одновременно делаю merge между ветками и в конфликтах git смотрю, какие модули можно автоматом объединять, в какие надо будет потом скопировать автосмерженный текст, а какие необходимо формы или роли вручную потом постобрабатывать.
MuI_I_Ika : 17 Ноя 2014, 14:20
Евгений, а вот это я бы назвал пятым вариантом. Учет веток в git позволяет систематизировать эту проектную разработку. Собственно к этому и подводил.

pumbae : 17 Ноя 2014, 14:28
вот это я бы назвал пятым вариантом
Да, согласен, т.к. тут еще добавляется релиз менеджмент, тестирование(корректность авто-merge, без тестирования очень трудно проверить), развертывание.
Теги:
 

Новый стандарт МСФО по учету выручки станет стимулом для разработки новых проектов в сфере строительства, коммуникаций и программного обеспечения

Автор newsРаздел Новости

Ответов: 0
Просмотров: 1067
Последний ответ 02 Июн 2014, 12:40
от news
Ищем интересные идеи/разработки/предложения. Приглашение к совместному бизнесу.

Автор fortech-pro.ruРаздел Поиск единомышленников

Ответов: 0
Просмотров: 875
Последний ответ 18 Мар 2016, 23:52
от fortech-pro.ru
Опытный программист из Украины предлагает услуги разработки на базе 1С

Автор Ivan1CРаздел Резюме

Ответов: 0
Просмотров: 2688
Последний ответ 20 Сен 2013, 18:07
от Ivan1C
Нужен совет на счет разработки новой конфигурации в 1с предприятие 8.3

Автор Space_minusРаздел Конфигурирование, программирование в "1С - Предприятие 8"

Ответов: 0
Просмотров: 454
Последний ответ 26 Мар 2016, 18:05
от Space_minus
Модуль фриланса или заказной разработки 1С доступен у нас на форуме

Автор MuI_I_IkaРаздел Блоги

Ответов: 8
Просмотров: 2285
Последний ответ 19 Ноя 2013, 17:40
от Рощин Антон

* Реклама

* Поиск

* Последние задачи на разработку (фриланс)

* Реклама

* Последние вакансии

* Топ 10 авторов за месяц

Геннадий ОбьГЭС Геннадий ОбьГЭС
145 Сообщений
ilyay ilyay
63 Сообщений
AIFrame
53 Сообщений
alex0402
50 Сообщений
andron81_81
44 Сообщений
oleg-x
42 Сообщений
BuhRust
32 Сообщений
MuI_I_Ika MuI_I_Ika
31 Сообщений
Golickoff Golickoff
28 Сообщений
Dima Dddd Dima Dddd
24 Сообщений

* Кто онлайн

  • Точка Гостей: 253
  • Точка Скрытых: 0
  • Точка Пользователей: 5
  • Точка Сейчас на форуме:

* Облако тэгов

* Форум 1С с мобильного

* Инструменты

* Дополнительно

Поиск

 
SimplePortal 2.3.5 © 2008-2012, SimplePortal