Групповая разработка конфигураций в крупном холдинге

0. stas_ganiev 1199 10.07.17 12:09 Сейчас в теме
О чем мы сегодня поговорим?
• О становлении и развитии групповой разработки конфигураций 1С в крупном холдинге с использованием хранилища конфигураций.
• Обсудим практически все аспекты использования хранилища в командной разработке.
• Я расскажу про те методы и идеи, которые мы пробовали использовать, какие используем до сих пор, от каких отказались и почему.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Сурикат 313 15.08.17 14:53 Сейчас в теме
А у нас следующая схема:

1. Разработчик выполняет разработку в собственной базе (с хранилищем или без на его усмотрение)
2. Когда разработка завершена, то доработки переносятся в тестовое хранилище
3. Тестируем, исправляем
4. Переносим в хранилище рабочей базы

Так сделали для того, чтобы убрать необходимость синхронизации окончания разработки к определенным срокам. Да и каждый разработчик работает над независимым ТЗ.
2. Irwin 351 15.08.17 15:19 Сейчас в теме
Все в том или ином виде приходят к технологии разветвленной разработки конфигураций: https://its.1c.ru/db/v8std#content:2149184358:hdoc
tenikov; Stepa86; +2 Ответить
3. PerlAmutor 107 15.08.17 15:59 Сейчас в теме
А у нас 1 хранилище и мы занимаемся всем сразу, от обучения пользователей и заканчивая администрированием сервера. Программисты принимают телефонные звонки, ходят на совещания, подключают сканеры штрих-кодов к рабочим местам (ставят драйвера в систему, лазят под стол), настраивают права в системе. Работают сверхурочно без оплаты. По выходным. И из дома и отпуска.
Их ненавидят все пользователи за то, что база тормозит, из неё постоянно выгоняют пользователей, она часто глючит.
Работают вопреки, из-за принципа и желания наконец сломать прогнившую систему.
Winstoncuk; arakelyan; CodeNull; budden2010; Deslime; LeXXuS_ju; Zhilyakovdr; comol; Brawler; Hartge; srvrv; Solovyeff; dbimah; Waanneek; Sirin; Sla; +16 Ответить
7. hillsnake 16.08.17 13:40 Сейчас в теме
(3) Run forrest Run.

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

ничему не научишься и чудовищно отстанешь от своих коллег.
CodeNull; Brawler; CyberCerber; kredko; Irwin; +5 Ответить
4. solary 169 16.08.17 09:59 Сейчас в теме
Разрабатываете ли внешние обработки/отчеты? Как следите, чтобы разработчики одновременно не работали над одной обработкой? Используете SVN или еще что-нибудь?
Интересуюсь, потому что сейчас столкнулись с этой проблемой и пока только ищем удобное решение, чтобы можно было как минимум заблокировать обработку для изменений другими.
5. Fejerverk 16.08.17 10:05 Сейчас в теме
(4) У нас решили это немного "топорным" способом - внешние обработки выкладываются в конфигурацию и захватываются. Если захвачено - значит в работе у того кто взял, а он может уже обновлять как внешнюю не отпуская в конфигурации хоть 10 раз.
9. stas_ganiev 16.08.17 13:55 Сейчас в теме
(4)На момент доклада мучились как попало, но на сегодняшний день перешли на Git, в репозитории у нас версионируются все внешние файлы: правила обмена, внешние отчеты и обработки, расширения, автотесты и т.д.
CyberCerber; MGraf; +2 Ответить
11. solary 169 17.08.17 08:32 Сейчас в теме
(9)Разве в Git можно захватить и заблокировать для других обработку? Нам важно, чтобы другой разработчик не взялся изменять обработку, пока этим занимается первый.
12. Infactum 290 17.08.17 10:23 Сейчас в теме
(11) Странный подход.
При групповой разработке как раз нормальная ситуация, что несколько человек работают с одним "объектом", но над разными задачами. Потом в процессе слияния разрешаются конфликты, если они возникнут.
Просто нужно понимать, что организационная часть тоже не последнее место занимает, и не надо поручать одному разработчику, допустим, тотальный рефакторинг обработки, а другому при этом косвенно связанную с этой обработкой задачу.
stas_ganiev; +1 Ответить
13. stas_ganiev 17.08.17 10:43 Сейчас в теме
(11)
(12) Только дополню Егора. При работе с Гитом договариваемся, что все изменения каждый программист коммитит в отдельной фиче, и ни в коем случае не в develop! Потом при принятии пул-реквестов мастер по код-ревью сверяет изменения. Поддерживаю Егора - нормальная ситуация. Хотя, лично мне не понятно, что это может быть за супер-обработка, на которую наваливается толпа кодеров ))) Встройте ее в конфу, раз так критично.
14. solary 169 17.08.17 14:24 Сейчас в теме
(13) Обычно случается, что первый вносит новый функционал в обработку, а в это время находится какой-нибудь баг и второй разработчик правит его. После этого первый разработчик помещает обработку на сервер и затирает код второго. Согласен, что необходимо сравнивать обработки, тогда этого не случится.
6. ManyakRus 401 16.08.17 12:22 Сейчас в теме
1) непонятно сколько у вас программистов работают над одной конфигурацией,
если до 5 то не надо огород городить :) обычное одно хранилище подходит
2) Если много конфигураций - ещё лучше, на каждую назначить своего ответственного программиста - тогда тоже 1 хранилище надо
3) Все эти супер схемы с тремя хранилищами нужны только из-за безответственности когда никто ни за что не отвечает, делают 1 мелкое задание - сделал и забыл, а должно быть у каждого своя зона ответственности по базам и др.
CyberCerber; purgin; Yakud3a; zqzq; Anton64; +5 Ответить
10. stas_ganiev 16.08.17 14:08 Сейчас в теме
(6)
(7)
(8)
У нас над каждой конфигурацией работает от 2 до 10 программистов в ответственной группе. Но частенько туда вносят доработки коллеги из других групп.Лично у меня сейчас под мою ответственность три конфигурации, и на каждой своя схема: 1. Описанная в статье с тремя хранилищами; 2. Та, о которой говорит Илья (8); 3) И типовая на 8.3 исключительно на расширениях с использованием Git. Сравниваю, что называется, на собственной шкуре :)). Согласен, что первая получилась громоздкая, другие две показывают себя с лучшей стороны: геморроя меньше, контроль тот же (где-то даже лучше). Плюс начали использовать автотесты - те ваще жизнь упрощают ))) А дальше поживём - увидим...
8. swimdog 725 16.08.17 13:54 Сейчас в теме
Сколько программистов? У нас работало до 10 с 1 хранилищем и полноценным тестированием. У каждого программиста своя база, в которой выполняется разработка и в ней же осуществляется тестирование. После тестирования изменения выкладываются в хранилище. Там их проверяется ответственный на общие ошибки. И оттуда уже попадают в рабочую базу.
Возможно, это не сработает, если есть автоматическое тестирование в отдельной базе.
15. andrusevich 01.10.17 00:30 Сейчас в теме
На своей шкуре проверено полюбе без теста никуда, в предложеной схеме идет полюбе база тестов. И по принципу у нас обновления в четверг что бы в пятницу можно біыо біы исправить и гулять віходные (7 баз с одинаковой нетиповки самая большая 86гб каскоко помню занимаемся FMGC болуу 3к документов в сутки).
Оставьте свое сообщение
Вопросы с вознаграждением